[e2e] High Packet Loss and TCP

[Spencer Dawkins]

Dear Ross,

The two problematic environments I've worked in are:

- TCP over high-bandwidth satellite links, where unrecovered
single-packet losses cut the congestion window in half
(multiplicative decrease) and may take a large number of 400-ms
RTTs to return to normal operation (additive increase), and 

- TCP over cellular links, where the bandwidth rates are lower,
but the RTTs are higher (up to 1.2 seconds, that I've seen), and
losses due to transmission errors may be more frequent.

SACK helps recover without an RTO, but still cuts the congestion
window in half, so SACK is a good thing, but not a great thing,
from an RFC 3155 perspective.

Hope this helps!

Spencer

--- Craig Partridge <craig at aland.bbn.com> wrote:
> 
> In message <4.3.2.20030501153756.02d4fbe0 at zircon.juniper.net>,
> Ross Callon writ
> es:
> 
> >My understanding is that there is some level of packet loss 
> >which causes TCP to back off to the point of stopping. My 
> >impression is that this is a sufficiently high loss rate that
> it 
> >shouldn't happen in a network which is behaving properly, 
> >and if it happens this should be considered a network failure
> 
> >rather than a TCP problem. (I am pretty sure that I saw this 
> >sort of behavior a few years ago when trying to access large 
> >files over a very bad link). 
> 
> Hi Ross:
> 
> Well, in the extreme, TCP just fails.  And that's a fairly
> simple
> computation, namely, does:
> 
>     the maximum number of retransmissions * the loss rate *
> total segments
>       to be sent in the connection
> 
> give you a number that starts getting close to 1.0?  If so,
> you've got
> non-working TCP.
> 
> If you want to do a little better, you can evaluate the
> forward and
> reverse loss rates (the equation above assumes all acks get
> through, which
> usually isn't true if the loss rate in the forward direction
> is high).
> 
> If you want to make your head hurt, you can try to puzzle out
> just how
> poorly TCP works with lower loss rates -- that's a function of
> retransmission
> policies, cumulative acks, and such like.  Most studies I've
> seen suggest
> that single digit loss rates are enough to seriously slow
> things down
> (though exact behavior varies widely according to things like
> use of SACK).
> 
> Craig
>