On Mon, Feb 05, 2007 at 01:36:36PM +0000, Michael Rogers wrote: > Matthew Toseland wrote: > >What's going on with the sendAck(int) -> send(int)? > > I'm experimenting with removing the coalescing delay for acks, which > means there will only ever be one ack per packet, so send(-1) is > equivalent to the old send(), and send(x) is equivalent to the old > sendAck(x). > > The reason for the experiment is the attached paper, which shows that > packet reordering is not as unusual as I'd previously thought. That has > implications for the fast and slow retransmission mechanisms - basically > we need to measure the RTT variance as well as the mean, and take the > variance into account when calculating the timeouts (as TCP does). > Unfortunately if acks can be delayed by up to 100ms for coalescing, the > variance of the RTT will be high and consequently it will take a long > time to detect and retransmit lost packets.
Not if we include timestamps. Sending acks immediately is very wasteful with the level of overhead we have. > > For example, Alice sends packets 1, 2, 3 and 4 to Bob. She gets acks for > 2, 3 and 4. This could mean that (a) packet 1 has been lost, or (b) the > packets were reordered, packet 1 arrived after the others, and the ack > is being held by Bob for coalescing. She has to wait an extra 100ms to > find out which. She has to wait anyway, because the ack may be delayed. > > Removing ack coalescing will probably lead to more small packets being > sent. However, I'm not sure that's a major problem because our packet > overhead isn't much greater than TCP's. A TCP ack with no piggybacked > data uses 20 bytes. With the new packet format, a Freenet ack with no > piggybacked data uses 8 bytes for the UDP header, 20 bytes for the HMAC, 32 bytes for the HMAC. SHA-1 is broken. > and 4 bytes each for the packet number, payload number, and ack - a > total of 40 bytes. If we can avoid retransmitting a 1000-byte data 52 bytes. > packet unnecessarily, a 40-byte ack seems well worthwhile. It's very bad if we are encapsulating it (for e.g. stego), or doing CBR. It also may provide an easy means to identify Freenet traffic, unless we randomly pad it (as we do), which will increase the overhead even more. > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20070207/cdf84717/attachment.pgp>
