RE: TCP (and SCTP) sucks on high speed networks

[Lloyd Wood <l.wood@eim.surrey.ac.uk>]

On Fri, 1 Dec 2000, Dawkins, Spencer wrote:

> RFC 2581 calls for an increase in the congestion window for each
> RTT's worth of acks, not for each ack, during congestion
> avoidance.

The exact opposite, surely?

Below, 'This adjustment is executed on every incoming non-duplicate
ACK. ' is a Dead Giveaway. The adjustments per ack approximate to an
adjustment per RTT...

unless you're not counting fractions, and 'an increase' in your
message == 'add one'.

L.

> The text I'm looking at is:
>
> 
>    During congestion avoidance, cwnd is incremented by 1 full-sized
>    segment per round-trip time (RTT).  Congestion avoidance continues
>    until congestion is detected.  One formula commonly used to update
>    cwnd during congestion avoidance is given in equation 2:
> 
>       cwnd += SMSS*SMSS/cwnd                     (2)
> 
>    This adjustment is executed on every incoming non-duplicate ACK.
>    Equation (2) provides an acceptable approximation to the underlying
>    principle of increasing cwnd by 1 full-sized segment per RTT.  (Note
>    that for a connection in which the receiver acknowledges every data
>    segment, (2) proves slightly more aggressive than 1 segment per RTT,
>    and for a receiver acknowledging every-other packet, (2) is less
>    aggressive.)
> 
> Page 4, bottom of the page.
> 
> Spencer, who tripped over this recently, until Mark Allman corrected me
> 
> > -----Original Message-----
> > From:	Thomas Skibo [SMTP:skibo@juniper.net]
> > Sent:	Friday, December 01, 2000 1:02 PM
> > To:	Matt Wakeley
> > Cc:	end2end-interest@ISI.EDU; ips@ece.cmu.edu
> > Subject:	Re: TCP (and SCTP) sucks on high speed networks
> > 
> > 
> > 
> > 
> > Matt Wakeley wrote:
> > > 
> > > Consider a 10Gbs link to a destination half way around the world.  A packet
> > > drop due to link errors (not congestion or infrastructure products) can be
> > > expected about every 20 seconds.  However, with a RTT of 100ms (not even
> > > across the continent), if a TCP connection is operating at 10Gbs, the packet
> > > drop (due to link error) will drop the rate to 5Gbs.  It will take 4 *MINUTES*
> > > for TCP to ramp back up to 10Gbps.
> > > 
> > 
> > 
> > Four minutes!?  Okay, I'm ready to be shot down but this is
> > how I figure it (based upon TCP implementations with which
> > I'm familiar):
> > 
> > If a single drop occurs within a round trip, TCP fast retransmit
> > will quickly retransmit the missing segment and cut the congestion
> > window in half.  So, assuming cwnd goes from exactly the bandwidth
> > delay product to half the bandwidth delay product, the congestion
> > window is now 62 MB.
> > 
> > To grow cwnd back to 125 MB, it first takes a round-trip time for new
> > ACKs to come from the receiver that actually ACK new data (as
> > opposed to the duplicate ACKs you'll get for a round-trip time).
> > 
> > Once new ACKs start coming back, you'll increase the congestion
> > window by a segment size for each ACK.  Because each ACK acknowledges
> > roughly two segments (in the implementations I'm familiar with),
> > it'll take about twice as long to grow cwnd by 62 MB  as it
> > takes to transmit 62 MB.  That's another 100 ms.  200 ms total
> > to get back to "full speed".
> > 
> > Another thing, I think the congestion window is likely to grow
> > beyond the bandwidth delay product if you're only getting a
> > single drop every 20 seconds (and assuming you've set your send
> > buffers to 250 MB).  So, you may never even notice that it got
> > cut in half every 20 seconds.
> > 
> > --Skibo  (skibo@juniper.net)
> 

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>