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. 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. 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, 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 packet unnecessarily, a 40-byte ack seems well worthwhile. Cheers, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: reordering.pdf Type: application/pdf Size: 107648 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20070205/0a3f4573/attachment.pdf>
