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

From: Kacheong Poon <[email-masked]>
Date: Thu, 22 May 2003 01:19:36 -0500 (CDT)

Included message from Mark Allman <[email-masked]>:

>Indeed that could very well lead to a "hole" in LT.
>
>(Which would be exacerbated by maxburst -- or, by anything that
>dropped the outstanding data to less than the cwnd.)
>
>My over-arching point is not about LT, though -- but, that we'd
>carefully have to consider all sorts of things to find new problems
>caused that a maxburst would cause.

Let me quote what I wrote in a previous email and ask
what people on this list think.

----
Consider this case, an app using TCP has a brief moment
(much shorter than one RTT) of pause such that the number of
outstanding segments in the network is less than the current cwnd.
Should TCP reduce the cwnd because of this?  I guess most, if not
all, people agree that cwnd should probably be reduced if the pause
is longer than one RTT, as described in RFC 2861.  This is the idea
behind "Use-it or Lose-it."  But for a period less than one RTT, I
suspect that most people will say no.
----

Do most people agree with the last statement?  I guess this
summarizes what I've been trying to say about maxburst.  I
don't know if people on this list really want to change how
TCP works with temporary app pause.

But it is very clear that RFC 3042 has a problem in how
the algorithm is specified.

[ ... ]

>Finally, contrary to what you note above, I think the interactions
>of scheme (3) are quite well known since they are just the same old
>TCP interactions.  There are no new dynamics here, just a cwnd
>reduction followed by a slow start.  Nothing unusal about that.
>What implications do you see?

I believe the particular TCP mechanism Mark referred above happens
when there is a drop, which indicates that there is congestion
(assuming drop implies congestion).  In the context we are
discussing here, the experiemental CWV does not apply (refer to
the above quote).  So if you are saying that this does not change
TCP's behavior regarding temporary app pause in a way that people
are not used to...

I suggest Mark to write up a paper describing his idea with data
supporting what he tries to say.  I'm afraid we are just expressing
opinions here without fruitful results, except that RFC 3042 needs
some changes....

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

---

From: Pasi Sarolahti <[email-masked]>
Date: 22 May 2003 12:14:43 +0300

Hi all,

On Thu, 2003-05-22 at 09:19, ext Kacheong Poon wrote:

> Do most people agree with the last statement?

[Since you asked... Even though I doubt I can bring much new to this
thread]

I think some kind of burst avoidance is needed as a general safety
mechanism, not only considering NewReno. I like Mark's suggestion (3),
because it seems to behave similarly than alternative (1) with separate
control variable, and can do this with existing TCP variables (well, at
least as long as maxburst <= 3). So, I think momentarily reducing cwnd
is ok, if the pitfalls described earlier related to reordering, etc. can
be avoided.

There seems to be different opinions in what kind of role cwnd should
have. I'd like to keep it simple: while cwnd > flightsize send data;
otherwise don't send data. Additional variables to that add complexity.
However, I do see that if cwnd is strictly thought of as an higher level
parameter ("my fair share of the network capacity"), reducing it as you
describe above does not sound a good idea, even if it is known to be
increased back in slow start within a short while.

[Although there is an opposite case not directly related to this
discussion: RFC 2581 and RFC 2582 momentarily increase cwnd during fast
recovery to allow forward transmissions, even though the actual
congestion window should really be something less at that moment]

But in the end, I think it is mostly an implementation issue to choose
the most suitable variant of the actual burst avoidance algorithm. As
long as the TCP congestion control RFC requires burst avoidance and
describes what is meant by burst avoidance either by using (1) or (3),
it should be ok, right?

- Pasi

---

From: Mark Allman <[email-masked]>
Date: Thu, 22 May 2003 12:31:03 -0400

> TCP works with temporary app pause.

And, my point is that it doesn't matter if you use scheme (3) or
scheme (1).  The on-the-wire behavior is quite similar.  I.e., even
if you leave cwnd high you won't use it because of maxburst.  So,
what is the problem in dropping it if you can't use it to begin
with?

(The only substanitive on-the-wire difference in scheme (1) and (3)
that I have seen is the one raised by Tom: that the cwnd after a
loss could be different under these two schemes.)

The difference in (1) and (3) comes in the actual specification and
implementation.  I think it is much cleaner to use scheme (3).  And,
I do not think we're going to agree on this point.

> the algorithm is specified.

Actually, I have had a nagging feeling about this... and, my brain
has just clicked.  I don't think there is a problem with 3042.  If
there is an app pause that causes cwnd > outstanding_data (and,
therefore, for the test in 3042 to look bogus) then LT will not kick
in anyway because TCP is app limited and there is no new data to
send.  

But, if outstanding_data < cwnd because of maxburst, this is not the
case -- rendering the LT spec to be bogus.  But, that is sort of my
point -- it would be bogus because of the maxburst retrofit.

> supporting what he tries to say.  I'm afraid we are just
> expressing opinions here without fruitful results, except that RFC
> 3042 needs some changes....

The we should also seem some study of maxburst, no?

allman

--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Thu, 22 May 2003 17:28:20 -0400 (EDT)

> Do most people agree with the last statement?

I think it doesn't matter how a burst is caused (e.g, application pauses,
reordering, lost acks, fast recovery exited, etc)... a burst is a burst.

I agree with Pasi in that if maxburst = 3, then method (1) and (3)
perform equally. In that case, I prefer method (3)... which is really what
we meant to specify when specifying method (2) in the SCTP implementer's
guide.

Method (3) becomes more conservative in comparison to method (1) as
maxburst increases beyond 3. Like Mark, I prefer to not introduce another
variable for limiting the sending rate, but if the acceptable maxburst is
significantly larger than 3, then method (3) will hurt performance in
large bandwidth-delay environments.

So the questions become:

1. What is an acceptable maxburst?

2. If maxburst > 3, then can we devise a variation on method (3) that
performs as well as method (1)?

~armando

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