"Does TCP Need an Overhaul?" (internetevolution, via slashdot)

Iljitsch van Beijnum iljitsch at muada.com
Mon Apr 7 12:17:31 UTC 2008


On 5 apr 2008, at 12:34, Kevin Day wrote:

> As long as you didn't drop more packets than SACK could handle  
> (generally 2 packets in-flight) dropping packets is pretty  
> ineffective at causing TCP to slow down.

It shouldn't be. TCP hovers around the maximum bandwidth that a path  
will allow (if the underlying buffers are large enough). It increases  
its congestion window in congestion avoidance until a packet is  
dropped, then the congestion window shrinks but it also starts growing  
again.

If you read "The macroscopic behavior of the TCP Congestion Avoidance  
algorithm" by Mathis et al you'll see that TCP performance conforms to:

bandwdith = MSS / RTT * C / sqrt(p)

Where MSS is the maximum segment size, RTT the round trip time, C a  
constant close to 1 and p the packet loss probability.

Since the overshooting of the congestion window causes congestion =  
packet loss, you end up at some equilibrium of bandwidth and packet  
loss. Or, for a given link: number of flows, bandwidth and packet loss.

I'm sure this behavior isn't any different in the presence of SACK.

However, the caveat is that the congestion window never shrinks  
between two maximum segment sizes. If packet loss is such that you  
reach that size, then more packet loss will not slow down sessions.  
Note that for short RTTs you can still move a fair amount of data in  
this state, but any lost packet means a retransmission timeout, which  
stalls the session.

> You've also got fast retransmit, New Reno, BIC/CUBIC, as well as  
> host parameter caching to limit the affect of packet loss on  
> recovery time.

The really interesting one is TCP Vegas, which doesn't need packet  
loss to slow down. But Vegas is a bit less aggressive than Reno (which  
is what's widely deployed) or New Reno (which is also deployed but not  
so widely). This is a disincentive for users to deploy it, but it  
would be good for service providers. Additional benefit is that you  
don't need to keep huge numbers of buffers in your routers and  
switches because Vegas flows tend to not overshoot the maximum  
available bandwidth of the path.



More information about the NANOG mailing list