SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



    > 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):
    
    bang. :)
    
    > 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.
    
    good so far. 
    
    > 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).
    
    not really, there's slow-start-like cwnd behavior on
    receipt of duplicate acknowledgements used to keep
    additional data entering the network to maintain ack
    pacing.
    
    > 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".
    
    As soon as fast retransmit is cleared, cwnd returns to
    ssthresh (1/2 of the last cwnd) and is incremented by
    segment_size / cwnd for each new acknowledgement.  This
    ultimately increases the congestion window by one segment
    per round trip time, as needed for additive increase.
    There's likely to be some fudge resulting from delayed
    acknowledgements in there too.
    
    > 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.
    
    It's not clear to me how much buffering one would have in
    a 10Gb/s link that's 100ms long.  If there's 125 megabytes
    of buffering in the right place in the network,  and the
    sender and receiver agree on monstuously large buffers,
    then you're right, you might not notice the backoff in the 
    sending cwnd.
    
    > --Skibo  (skibo@juniper.net)
    
    -neil
    


Home

Last updated: Tue Sep 04 01:06:13 2001
6315 messages in chronological order