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

From: Kacheong Poon <[email-masked]>
Date: Tue, 20 May 2003 22:37:35 -0500 (CDT)

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

>----
>You made my point.  If we are to use a simple maxburst limit then
>the limited transmit rfc has a "hole" and we do need new text.  It
>might not be complicated, but it will become busted and in need of a
>fix.  And, LT was only an example.  My bet is that we have to revist
>a bunch of things for similar reasons.  And, as we evolve things
>we're going to have to remain cognizant that now we have two things
>controlling the amount of data being sent into the network (possibly
>requiring two different decision paths, etc.).

Since you said that "I made your point," I guess you agreed that
there is a hole in RFC 3042 (-:  As I mentioned in my previous mail,
maxburst is an "artificial app pause."  Any app which has a pause
in sending will behave similarly.  Your example arguing that
maxburst is bad for Limited Transmit applies equally to an app
which has a pause in sending.  So I guess most people will agree
that the problem you referred to with maxburst is actually an
issue in RFC 3042, not with maxburst.

>Hm, if one were to implement rfc3042 and we reach consensus that
>said implementation did the wrong thing it would be more than an
>implementation error -- it would be a spec error.

Yes, it is a spec error in RFC 3042.  We still have time to fix it,
right?

>The problem is that discussing things only in terms of cwnd misses
>the whole point.  Of course, it might be natural to think "ah, I
>don't want to sacrifice cwnd".  But, by limiting the bursts in
>response to each ACK we are basically doing exactly the same thing
>--- that is, we are limiting the amount of data that can be put on
>the wire.
>
>I agree that scheme (2) is somewhat naive -- as folk have been
>saying. 
>
>But, with scheme (3) (which is a slight riff on scheme (2)) I bet we
>see basically the same sort of behavior as scheme (1) and with the
>bonus that (a) we only use one control and so interactions are nil
>and (b) cwnd tracks the amount of outstanding data, which is in
>better alignment with the expectations of our code and specs.

Scheme (3) is actually worse than (2) IMHO.  Besides overloading
the meaning of cwnd, it also overloads the meaning of ssthresh.
The variable ssthresh is used to track (or approximate) the number
of segments the network path to a destination can take before
congestion may happen.  Scheme (3) removes this meaning altogether.
This changes the whole mechanism of TCP probing the network to
test for congestion point.  And we are talking about unknown
interactions in this email thread!

In general, I strongly disagree with semantics overloading.  And
if we are solely concerned about the unknown interactions
introduced by maxburst, let me give a data point.  Solaris' TCP
has had maxburst since 1998.  AFAIK, there is no complaint about
it.  If we believe in running code, I think maxburst is OK.  OTOH,
we already know that scheme (2) is not good.  And the proposed
scheme (3) will change TCP congestion control behavior.  So which
one will more likely have unknown interactions?

>----

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

---

From: Mark Allman <[email-masked]>
Date: Wed, 21 May 2003 00:11:53 -0400

> there is a hole in RFC 3042 (-:  

Not necessarily.... there would be a hole with maxburst.

> As I mentioned in my previous mail, maxburst is an "artificial app
> pause."  Any app which has a pause in sending will behave
> similarly.

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.

> congestion may happen.  Scheme (3) removes this meaning
> altogether.  This changes the whole mechanism of TCP probing the
> network to test for congestion point.  And we are talking about
> unknown interactions in this email thread!

First, I do not agree with your notions of either cwnd or ssthresh.
I believe that cwnd is the amount of outstanding data a TCP can have
in the network at any given instant (and, any number of things can
be used as inputs -- estimated path capacity, burst capacity, etc.).
And, ssthresh is just the pivot point for slow start (exponential
growth vs. linear growth).  E.g., we use ssthresh for history in
CWV.  That is all I am suggesting here, as well.  Given those
notions I do not see why cwnd cannot be used to help mitigate
bursts.  And, I do not agree that we are "overloading" the meaning
of these variables.

But, even if we use your notion of ssthresh as the amount of traffic
the network can take before congestion happens I still think using
ssthresh in the manner I sketched is consistent.  I.e., if we build
cwnd to some value X without congestion and then set ssthresh to
that value then that would seem to fall within your definition.

> And if we are solely concerned about the unknown interactions
> it.  If we believe in running code, I think maxburst is OK.  

Data point taken.  But, 

"No complaint" is not so convincing to me... has anyone studied it?

And, all TCP's bend things around their own special way (e.g.,
solaris uses maxburst even though it is not standard; although, it
is also not non-standard given that it is more conservative than the
spec calls for).  So, it might be that solaris TCP also contains
not-quite-standard ways of doing other things that get around the
interactions.  Maybe not.  But, maybe.  I'd want to see a pretty
in-depth study so I could understand what solaris is doing.  (That
is, I'd like to underestand the running code, not just be happy that
we have it.)

> OTOH, we already know that scheme (2) is not good.  And the
> proposed scheme (3) will change TCP congestion control behavior.
> So which one will more likely have unknown interactions?

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?

allman

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