From: Iljitsch van Beijnum (no email)
Date: Mon Apr 07 2008 - 08:17:31 EDT
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.
|
|
|