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

TCP: Brief Comment on cwnd Inflation during Fast Recovery.

Expand Messages
  • Amr A. Awadallah
    All, For those of you who expressed interest in our comments on the effects of cwnd inflation. We added more comments/results on this subject at this URL (
    Message 1 of 1 , Jun 3, 1997
    • 0 Attachment

      For those of you who expressed interest in our comments on the effects
      of cwnd inflation. We added more comments/results on this subject at this
      URL ( http://www-leland.stanford.edu/~aaa/tcp ). We included the patch
      (diff file) for the current FreeBSD tcp_input.c. We would appreciate it if
      interested developers provide feedback to us about this change (in terms
      of observed throughput). The change is only a couple of lines of code and
      apparently leads to higher throughput TCP sources.

      We also provide arguments for and against the modification. The main
      argument for the modification is that with the current cwnd inflation,
      more packets are being sent into the network during the fast recovery
      period at the rate at which duplicate-ACKs are coming back. Which is
      counter intuitive to the fact that entering fast recovery means that the
      TCP source just lost a packet (indicated by the duplicate ACKs), hence the
      source should throttle back its sending rate. By continuing to send at the
      rate at which duplicate ACKs are coming back, the source may force the
      network to drop another one of its packets (e.g. due to RED gateways
      [Floyd and Jacobsen, IEEE Transactions on Networking, August 1993], or
      simple buffer overflow). This may lead to invoking another fast recovery
      cycle, or worse invoking slow-start (this can be clearly seen in the cwnd
      vs time plots on the web page). The modification we did provides the
      network a breathing period of less than 1 RTT which allows the network to
      catch up its breath by dequeuing congested buffers. This avoids another
      packet loss, thus leading to a smoother cwnd vs time behavior. It still
      allows for packets to be sent during the fast recovery period but at a
      much lower rate.

      The main argument against the modification is that by using normal
      congestion avoidance cwnd-increase during the fast recovery period (rather
      than cwnd inflation), the source will not be able to keep the pipe full
      (thus violating VJ recommendations). Hence this leads to a burst of
      back-to-back packets at the end of the fast recovery period. We note
      though that schemes like FACK [Mathis and Mahdavi SIGCOMM '96] allows for
      the regulation of such a burst (by pacing the burst). SACK [Floyd and Fall
      CCR paper] also tackles this problem. We also note that this burst of
      back-to-back packets is known to exist in current TCP implementations (at
      least we observed it rather frequently in FreeBSD 2.1.6, as shown on the
      web). The burst simply occurs due to cwnd sliding a considerable distance
      when the non-duplicate ACK arrives, hence opening up lots of space for new
      packets to be sent. The modification leads to a more aggressive TCP source
      since it starts with a larger window size at the end of the fast-recovery
      period. It has also been pointed to us that most TCP researchers think
      the principles behind the current fast recovery algorithm works well.

      One last comment, we stumbled on the cwnd inflation spikes during our
      research on TCP (which is on a totally different aspect). The spikes
      appeared strange to us at first because in most papers on TCP congestion
      avoidance (at least those that we read), one would rarely see a cwnd vs
      time plot showing the cwnd inflation spikes. This was the main reason why
      we were originally misled to believe that this was a bug in TCP, until
      others corrected us by pointing out that this is truly how fast recovery
      was designed to work (that is the spikes are a feature of TCP ! ).

      Thanks for your interest and feedback,


      Amr A. Awadallah (aaa@...)
      Chetan Rai (crai@...)


      PS: Sorry if you receive this e-mail more than once, this means you are
      subscribed to too many mailing lists :)
    Your message has been successfully submitted and would be delivered to recipients shortly.