2 apr 2006 kl. 06.41 skrev Alex Pankratov:
[EMAIL PROTECTED] 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 thesame time. I back off if the round trip time starts spiking.I want to second RTT-based congestion avoidance approach. Given that itis *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.
/Lars-Åke
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
