[e2e] 10% packet loss stops TCP flow

[Christian Huitema]

> There is another very simple way to look at it. The most
> "optimistic" model of TCP, that only looks at congestion
> avoidance (AIMD) and ignores slow start, timeouts etc., predicts
> the following relationship between the average window size (w)
> and loss probability (p):
> 
> 	(w^2)*p = 2
> 
> Note that this is _independent_ of link bandwidth and RTT. So
> with a loss probability of 10%, the average window size is going
> to be of the order 4. If you factor in other protocol details,
> the number will be even smaller. With a window size of 4 or
> below, fast recovery will not work and any loss will lead to a
> timeout (for the average connection). Hence loss rates of the
> order 10% simply will not work, irrespective of RTT/link bandwidth.

The formula (w^2)*p = 2 assumes a connection in "congestion avoidance"
mode, which is not actually the case if the loss rate is high. If the
loss rate is high, the connection will be very often in "slow start"
mode, where the approximation is "w*p = 2". If the loss rate is still
higher, we move to "w=1", and the adaptation comes from increasing the
RTT.  

The classic rule of thumb is that a link exhibiting more than 1% packet
loss is considered broken.

By the way, Noel's challenge points to an interesting point. Long
transfers are more likely to break than short transfers. If we want to
actually transfer large files over poor quality networks, we cannot rely
on TCP alone, but we have to split them in small chunks. Much like what
BitTorrent does...

-- Christian Huitema