Subject: [Tsvwg] Taking NewReno to Proposed Standard

From: Sally Floyd <[email-masked]>
Date: Thu, 19 Jun 2003 16:35:23 -0700

We have submitted draft-ietf-tsvwg-newreno-00.txt to the
internet-drafts repository.

A local copy is at:
http://www.icir.org/floyd/papers/draft-ietf-tsvwg-newreno-00.txt

This is a revised version of draft-floyd-newreno-00.txt, and
differs from it as follows:

   Changes from draft-floyd-newreno-00.txt:

   * In Section 8 on "Implementation issues for the data sender",
   mentioned alternate methods for limiting bursts when exiting Fast
   Recovery.

   * Changed draft from draft-floyd-newreno to draft-ietf-tsvwg-newreno

Section 8, which contains the only change other than the title,
is appended below.  The change to Section 8 is basically the addition
of the last two sentences.

We are asking that this be considered for advancement to Proposed
Standard.

Many thanks,
Sally and Tom

8. Implementation issues for the data sender.

   In Section 3, Step 5 above, it is noted that implementations should
   take measures to avoid a possible burst of data when leaving Fast
   Recovery, in case the amount of new data that the sender is eligible
   to send due to the new value of the congestion window is large.  This
   can arise during NewReno when ACKs are lost or treated as pure window
   updates, thereby causing the sender to underestimate the number of
   new segments that can be sent during the recovery procedure.
   Specifically, bursts can occur when the FlightSize is much less than
   the new congestion window when exiting from Fast Recovery.  One
   simple mechanism to avoid a burst of data when leaving Fast Recovery
   is to limit the number of data packets that can be sent in response
   to a single acknowledgment.  (This is known as "maxburst_" in the ns
   simulator.)  Other possible mechanisms for avoiding bursts include
   rate-based pacing, or setting the slow-start threshold to the
   resultant congestion window and then resetting the congestion window
   to FlightSize.  A recommendation on the general mechanism to avoid
   excessively bursty sending patterns is outside the scope of this
   document.

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg