[freenet-dev] [freenet-cvs] r11679 - in trunk/apps/load-balancing-sims/phase7/sim: . clients messages

[Michael Rogers]

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 : http://emu.freenetproject.org/pipermail/devl/attachments/20070205/0a3f4573/attachment.pdf