[p2p-hackers] Hard question....

Lars-Åke Larzon lln at it.uu.se
Sun Apr 2 09:03:07 UTC 2006

2 apr 2006 kl. 06.41 skrev Alex Pankratov:

> gbildson at limepeer.com wrote:
>> I've missed part of this conversation but here is my two cents on  
>> this specific
>> question -  just keep increasing the amount of data that you are  
>> sending in
>> bursts and the speed of those bursts until you achieve a certain  
>> target error
>> rate.  i.e. 2% or whatever.  After bumping up against failures,  
>> you should be
>> able to get a sense of an optimal rate.  Be sensitive to TCP  
>> congestion at the
>> same time.  I back off if the round trip time starts spiking.
> I want to second RTT-based congestion avoidance approach. Given  
> that it
> is *the* idea behind TCP/Vegas, it is nothing new, but the nice thing
> about it is that it works very well for consumer Internet connections.

RTT spikes can occur for many reasons other than congestion,  
especially if you have links that insists on in-order frame delivery  
in your path. So, being too sensitive to RTT spikes can actually give  
you quite poor performance.

It is also quite common that RTT variations occur on much shorter  
timescales than you are able to detect them on. So, when you detect  
the spike, it may be long gone and your reaction might be more or  
less meaningless.

Regarding TCP/Vegas, it requires a quite precise clock to operate  
properly if I remember it correctly. There are many newer, simpler  
schemes that also look at RTT variations without the need for such  
precision. TCP Westwood is one of them, but there are others as well.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4030 bytes
Desc: not available
Url : http://zgp.org/pipermail/p2p-hackers/attachments/20060402/162b27d0/smime.bin

More information about the P2p-hackers mailing list