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

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

>>    * Added a section on Implementation issues for the data sender,
>>    mentioning maxburst_.
>
>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.

Actually, they serve rather different purposes.

Congestion Window Validation (RFC 2861) is about how the sender
reduces the congestion window after an idle or application-limited
period, when the sender was not using the full value of the old
congestion window.  This is orthogonal to NewReno.

Maxburst_ is mentioned in the new NewReno draft for dealing
with the burstiness that can result when the sender exits
Fast Recovery.  And the NewReno draft specifies a method for
setting cwnd that should avoid this burstiness in the first place,
in step (5) of Section 3.

- Sally
http://www.icir.org/floyd/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

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

> Actually, they serve rather different purposes.

Yes, I understand that...

> in step (5) of Section 3.

I don't think CWV is completely orthogonal to NewReno's burst
limitation, but I could have been more clear in my original mail. My
reference to CWV was specific to a particular portion of RFC 2861 (Section
3.2, "If no more data is available to send"). The non-maxburst algorithm
that you pointed out in the NewReno draft's Section 3 - step 5 is the kind
of burst limitation algorithm I had in mind when writing my original
mail... I must admit that I somehow missed that part when reading the
draft. Also I notice now that CWV isn't as similar as I had remembered.
Sorry, my mistake.

Anyway, is there a reason to leave the two burst limitation methods in the
draft? One method is to cap the cwnd after Fast Recover only by setting
cwnd = min (ssthresh, FlightSize + SMSS). The other method is to apply a
limit (maxburst) on "the number of data packets that can be sent in
response to a single acknowledgement".  Why not combine the two (as done
in the SCTP implementer's guide) into a simple algorithm as follows?

if((flightsize + Max.Burst*SMSS) < cwnd)
         cwnd = flightsize + Max.Burst*SMSS

~armando

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