Loading ...
Sorry, an error occurred while loading the content.

1296Re: NewReno and the 2001 Revision

Expand Messages
  • Tom Henderson
    Sep 15, 1998
    • 0 Attachment
      I've recently been looking at this issue quite closely. This bug fix is
      very helpful in at least the following situation: large file transfers over
      GEO (600ms RTT) paths for which the initial value of ssthresh is not cached
      but is instead some large value. Without the fix, the slow start overshoot
      typically leads to multiple packet losses, which then leads to rebuilding
      snd_cwnd linearly from a small value. As an example of the type of
      performance difference I've seen, a 10 MB file transfer over our GEO network
      testbed consistently takes a 30% hit in throughput when SACK with Reno
      congestion avoidance is used instead of SACK with ``NewReno.'' In general,
      for long transfers over a satellite path, it is very costly to unnecessarily
      reduce the congestion window while in linear growth phase.

      I agree with the opinion that this is a bug fix and should not be considered
      experimental. It covers a case for which the previous version of RFC 2001
      was ambiguous (what to do if the ACK is a partial ACK). However, I also
      believe that if the spec is to include this, it should fully specify the
      correct behavior upon receiving a partial new ACK. In our SACK + NewReno
      implementation, we also do the following:
      - upon receiving a partial ACK, partially deflate the current snd_cwnd
      by (the amount of new data acked minus one segment), resend the next
      highest segment that has not yet been ACKed, and call tcp_output() to see if
      a new segment can be sent. The reason to do window inflation in Reno TCP is
      to have the correct amount of outstanding data in the network when the
      recovery ends. If one does not deflate the window for partial ACKs, this
      amount will be incorrect (overestimated).
      - upon leaving fast recovery, set snd_cwnd to min(snd_ssthresh,
      current amount of outstanding data). Window inflation may not successfully
      generate enough new transmissions for a number of reasons (e.g., sender is
      receiver window limited, dup acks are lost), leading to a burst of packets
      when the recovery phase ends. Kevin Fall and Sally Floyd have previously
      proposed a "maxburst" parameter that limits the number of segments that can be
      sent in response to an ACK when leaving fast recovery phase. However, we
      found that a slow receiver can generate a lot of pure window updates right
      after recovery ends, the effect of which can circumvent this maxburst
      protection. Setting snd_cwnd to be no more than the current amount of
      outstanding data is effective in preventing this problem.
      - avoid "false fast retransmissions" after a timeout as decribed by
      Hoe in the 1996 Sigcomm paper.

      --Tom Henderson

      For those interested, more details on our TCP implementation and experimental
      results can be found in the following paper:
    • Show all 8 messages in this topic