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

[Michael Rogers]

Matthew Toseland wrote:
> I don't understand. We can indicate how long a packet had to wait for
> coalescing, and therefore record a value based on the network delay,
> with a bit of the CPU delay thrown in, no?

Right, we can get an accurate measure of the RTT by using timestamps, 
but we still have to delay retransmissions by an extra 100ms in case the 
ack is being held for coalescing (we won't know until it arrives). The 
extra lag makes congestion control harder - you can't really do things 
like fast retransmission if the acks for packets that were sent almost 
simultaneously can be separated by 100ms.

Maybe I'm getting too caught up in the TCP way of doing things, but when 
I look at the amount of work that's gone into the design of TCP and the 
number of subtle problems they've found, I start to doubt that we can do 
better from scratch...

> 52 = 5% * 1000. The probability of a packet being dropped is less than
> 5% on most useful links.

Sorry, I don't see how the loss rate of the link is relevant - I'm 
talking about the overhead of sending an ack straight away (52 bytes) 
versus the overhead of retransmitting a packet unnecessarily (1000 
bytes). Unnecessary retransmissions happen when the RTT variance is 
high, which it is at the moment because acks are held for anywhere 
between 0 and 100ms. Currently we retransmit a packet if it hasn't been 
acked for 4 * RTT + MAX_DELAY, but we don't know what fraction of acks 
arrive after 4 * RTT + MAX_DELAY. If it's more than 5% then it would be 
cheaper to send the acks straight away.

Cheers,
Michael