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

[Matthew Toseland]

On Thu, Feb 08, 2007 at 10:44:41PM +0000, Michael Rogers wrote:
> 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.

Fast retransmission = If I get acks for 2,3,4 but not 1, then I resend
1, after X RTTs have elapsed?
> 
> 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.

Why would it be more than 4*RTT+MAX_DELAY?
> 
> Cheers,
> Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070209/d31f62e3/attachment.pgp