gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] packet size and noise


From: Glenn McGrath
Subject: Re: [GNUnet-developers] packet size and noise
Date: Sun, 16 Jun 2002 12:46:47 +1000

On Sat, 15 Jun 2002 20:32:38 -0500
"Christian Grothoff" <address@hidden> wrote:

> On Saturday 15 June 2002 08:15 pm, you wrote:

> > Is there anything special about 1472, if this size is fairly unique to
> > gnunet packets it would be an easy way to detect gnunet on a network.
> 
> 1472 + UDP header = 1500 octests = Ethernet-frame size = optimal
> transfer size (and thus also always used by TCP!). But note that the
> 'existance' of GNUnet traffic is trivial to detect (port 2086) at the
> moment; while we have plans to tunnel GNUnet-traffic in http and other
> protocols (and eventually hide steganographically), this is far down the
> road. The goal of the uniform size is to make it impossible to say 'this
> is content', or 'this can not be content' for anyone but the 2 nodes
> involved (read: traffic analysis gets very hard).
> 

> You definitely do not want to go over 1472 octets since the packet will
> then be fragmented on most networks.

Sounds like 1472 is a good size then, blend in with all the other packets.

The overheads of a 1472 byte gnunet packet will be (20(ip) + 4(udp) +
36(gnunet) / 1472) == 4%, i guess thats not a lot, i was thinking bigger
packets would be better as it would reduce this overhead and if its not
fragmented by the server then its someone elses bandwidth. Would large UDP
packets be less reliable during network congestion ? 

Another quick question...
The GNUnet protocol sepcifies the sender IP/Port, by sender do you mean
the source of the udp packet, or do you mean a 3rd IP/port to be used for
forwarding. 
Initially when i saw the port in there i was thinking it could be used to
allow clients to negotiate port numbers, looks like thats not the case.


Glenn



reply via email to

[Prev in Thread] Current Thread [Next in Thread]