[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 following paper, which shows that 
packet reordering is not as unusual as I'd previously thought:

http://dx.doi.org/10.1109/90.811445

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

P.S. Sorry for attaching a PDF to the previous version of this message
  - please delete it from the moderation queue.