[p2p-hackers] Hard question....
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
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...
Size: 4030 bytes
Desc: not available
Url : http://zgp.org/pipermail/p2p-hackers/attachments/20060402/162b27d0/smime.bin
More information about the P2p-hackers