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

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 19 May 2003 08:20:08 -0700

> Mark Allman wrote:
>
>   * Do we need some sort of general burst limiting mechanism?
> 
>     Beats me.

I have observed cases leaving Reno-ish fast recovery where the resulting 
FlightSize << ssthresh, so there are large bursts upon leaving Fast 
Recovery.  Two causes that I have observed are:
i) dupacks lost.
ii) slow receiver that fails to send pure window updates, thereby causing 
dupacks (with slightly different windows) to be interpreted by the sender 
as window updates, and not triggering a transmission off the top of the 
window. 

>     And, since there are two controls there are interactions between
>     them that must be taken into account -- in specs and code.  And,

I'd rather have that interaction than undesired coupling due to 
overloaded variables.

>     there are things that are currently speced that will break.
>     That is, TCP can be running in a state where there is less than
>     cwnd on the network because it is limited by maxburst instead of
>     cwnd and the specs/code do not envision the case and therefore
>     cannot be exepected to do something intelligent.  
> 
>     An example of where this breaks things: The limited transmit
>     spec says that on dup acks TCP can inject at most cwnd+(2*MSS)
>     of new data into the network.  The hope was that this means that
>     we can send data on the first two dup acks.  If maxburst has
>     limited the amount of outstanding data to something less than
>     cwnd then limited transmit now allows the sending of more than
>     two new segments on dup ACKs.  That might be OK.  But, I think
>     that is clearly at odds with the spirit of RFC 3042.  I think
>     there are likely quite a number of examples of unintended
>     interactions/consequences.

If maxburst always applies, and is set to a not-too-small value, 
I don't see the problem.  I agree that if maxburst only applies to 
leaving fast recovery, that having FlightSize << cwnd can cause 
problems later on.  But I also have the same concerns as Sally about
cutting down cwnd as a means to limit bursts.

So the main issue seems to me to be, if maxburst is considered a good
thing to recommend, shouldn't it be more broadly applicable than
the case of leaving fast recovery, and therefore discussed in a 
document like RFC 2581?

>   * One more observation: If maxburst is 4, we use scheme (1), we
>     use delayed ACKs, cwnd = outstanding_data = 10 segments and we
>     get an ACK that covers 10 previously unACKed segments (because
>     of dropped ACKs) the events will look like this:
> 
> 	get ACK for 10 segments; send 4 segments
> 	    (outstanding = 4; cwnd = 10)
> 	get ACK for 2 segments; send 4 segments
> 	    (outstanding = 6; cwnd = 10)
> 	get ACK for 2 segments; send 4 segments
> 	    (outstanding = 8; cwnd = 10)
> 	get ACK for 2 segments; send 4 segments
> 	    (outstanding = 10; cwnd = 10)
> 	get ACK for 2 segments; send 2 segments
> 	    (outstanding = 10; cwnd = 10)
> 
>     I.e., it's slow start.
> 
I disagree-- it is smoothed transmission of "credits" you have already 
built up in the network.

I thought that the observation about micro and macro control summed 
it up nicely.

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

---

From: Mark Allman <[email-masked]>
Date: Mon, 19 May 2003 11:33:18 -0400

> >     And, since there are two controls there are interactions
> >     between them that must be taken into account -- in specs and
> >     code.  And,
> 

I guess we just have different ways to look at things... I don't see
this as overloading cwnd -- which it seems to me is used to control
the amount of data sent into the network.

> If maxburst always applies, and is set to a not-too-small value,=20
> I don't see the problem.  I agree that if maxburst only applies to=20
> leaving fast recovery, that having FlightSize << cwnd can cause=20

What if we allow slow start after doing the cut?

> So the main issue seems to me to be, if maxburst is considered a
> good thing to recommend, shouldn't it be more broadly applicable
> than the case of leaving fast recovery, and therefore discussed in
> a=20 document like RFC 2581?

I agree.

I think this is beyond the revision of 2582.

> >     use delayed ACKs, cwnd =3D outstanding_data =3D 10 segments and we
> >=20
> > 	    (outstanding =3D 4; cwnd =3D 10)
> > 	    (outstanding =3D 6; cwnd =3D 10)
> > 	    (outstanding =3D 8; cwnd =3D 10)
> > 	    (outstanding =3D 10; cwnd =3D 10)
> > 	    (outstanding =3D 10; cwnd =3D 10)
> >
> >     I.e., it's slow start.
> 
> I disagree-- it is smoothed transmission of "credits" you have
> already built up in the network.

Yeah, I can understand that.  My point was that this smooth
transmission of credits follows the exact (in my example) pattern of
slow start.  (And, in a more general context the sending pattern of
maxburst is probably better stated as "approximating slow start".)

allman

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