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

["Dawkins, Spencer" <Spencer.DAWKINS@fnc.fujitsu.com>]

Thomas,

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 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)