[p2p-hackers] Hard question....

Alex Pankratov ap at hamachi.cc
Sun Apr 2 04:41:35 UTC 2006

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.

The reason being is that their bandwidth is typically capped by queuing
traffic shapers (as opposed by an actual hardware limits). So once some
the shaper starts queuing packets, it can be detected by a sender by
looking at RTT going up.

It can also be detected by the recipient and thus allow for a faster
(pre-)congestion detection. This however requires both sides to first
synchronize their clocks, and it's really worth doing only if the link
has very large latency.


More information about the P2p-hackers mailing list