Subject: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard

From: Sally Floyd <[email-masked]>
Date: Tue, 13 May 2003 10:19:03 -0700

Tom Henderson and I have modified RFC 2582, the NewReno RFC,
as the first step towards taking it from Experimental to 
Proposed Standard.  This is not yet an official work item of tsvwg,
but we did discuss it briefly at the tsvwg meeting in San Francisco.

The new draft is at:
http://www.ietf.org/internet-drafts/draft-floyd-newreno-00.txt

The slides from the presentation-that-was-skipped-due-to-time in
San Francisco are at:
http://www.icir.org/floyd/talks.html

There are no changes to the underlying NewReno algorithm.
The main change in the draft is that RFC 2582 desribed several
variants regarding avoiding unnecessary Fast Retransmits, and
*recommended* the Careful variant, while the new draft 
only specifies the Careful variant.

Any feedback would be appreciated.

- Sally and Tom

Here are the changes in the draft:

   NOTE TO THE RFC EDITOR:  PLEASE REMOVE THIS SECTION UPON PUBLICATION.
   Changes from RFC 2582:

   * Rephrasing and rearrangements of the text.

   * RFC 2582 described the Careful and Less Careful variants of
   NewReno, along with a default version that was neither Careful nor
   Less Careful, and recommended the Careful variant.  This document
   only specifies the Careful version.

   * RFC 2582 used two separate variables, "send_high" and "recover",
   and this document has merged them into a single variable "recover".

   * Added sections on "Comparisons between Reno and NewReno TCP", and
   on "Changes relative to RFC 2582".  The section on "Comparisons
   between Reno and NewReno TCP" includes a discussion of the one area
   where NewReno is known to perform worse than Reno or SACK, and that
   is in the response to reordering.

   * Moved all of the discussions of the Impatient and Slow-but-Steady
   variants to one place, and specified the Impatient variant (as in the
   default version in RFC 2582).

   * Added a section on Implementation issues for the data sender,
   mentioning maxburst_.

   * Added a paragraph about differences between RFC 2582 and [FF96].

   END OF NOTE TO RFC EDITOR

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

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Tue, 13 May 2003 13:52:09 -0400 (EDT)

> but we did discuss it briefly at the tsvwg meeting in San Francisco.

<SNIP>

> Here are the changes in the draft:

<SNIP>

>    * Added a section on Implementation issues for the data sender,

I am not sure if it is appropriate, but I think it would be useful to
suggest using the Congestion Window Validation (RFC 2861) technique
instead of the simple maxburst_ limit.

~armando

0--                                                  --0
| Armando L. Caro Jr.      |  Protocol Engineering Lab |
| www.cis.udel.edu/~acaro  |    University of Delaware |
0--                                                  --0