Subject: Re: [tcpm] thoughts on newcwv-05

From: [email-masked]
Date: Sat, 1 Mar 2014 19:56:41 -0000

See below for a first-answer,

Gorry

>
>> : Actually this is more difficult that it seems, the terminology in
>> : RFC 2861 referred to something different, and for quite some time
>> : the WG have used the new terminology.
>> : We can and will note this in the intro.
>
> It seems this is more than a quick note.  If 'rate limited' is different
> From what RFC 2681 addresses then does that document still hold when a
> sender is idle or application limited?  Or, do you somehow subsume those
> periods, too?  I am not taking a position on any of this.  I am just
> asking that the document be clear and precise on what problem it is
> going after and where it sits relative to other documents in the space.
>
I was thinking that we actually had to add some text, on this specific
point I was thinking along the lines of the text below - does this help
explain why the old terminology is different?:

<?xml version="1.0"?>
<ns:clipboard
xmlns:ns="http://www.xmlmind.com/xmleditor/namespace/clipboard">
<t>
RFC2681 proposed two set of responses, one after an
"application-limited" and one after an "idle period". Although this
distinction was argued, in practice differentiating the two behaviours
was problematic in actual networks. This resulted in
a performance for a busty application that depended both upon the RTO and
the pattern of application traffic relative to the RTO interval.
This lead to unpredictable performance for application designers who
are unaware of the network path RTT.

We argue that RFC2861's attempt to identify 2 application
behaviours is problematic and inappropriate, and this document therefore
explicitly avoids trying to differentiate these two behaviours.
Instead new-CWV uses single method for all rate-limited traffic that
seeks to provide predictable performance by preserving the cwnd.
</t>
</ns:clipboard>

>> : We will look at the possibility of reorganising the order of sections.
>
> (Or collapsing them might work, too.)
>
>>   + I think this:
>>
>>       Reception of congestion feedback while in the non-validated phase
>>       is interpreted as an indication that it was inappropriate for the
>>       sender to use the preserved cwnd.  The sender is therefore
>>       required to quickly reduce the rate to avoid further congestion.
>>       Since the cwnd does not have a validated value, a new cwnd value
>>       must be selected based on the utilised rate.
>>
>>     is exactly what RFC 5681 says.  I.e., it is why we changed things to
>>     be based on FlightSize.  I.e., it doesn't matter what is poked into
>>     "cwnd" at a given time, FlightSize is the load being imposed on the
>>     network and so that is the basis for the reaction to congestion.
>>
>>     So, my reading of things is that RFC 5681 **already does** what you
>>     say you want in the above blurb.
>>
>> : Except that Eqtn 4 in RFC 5681 does not consider the amount of losses
>> : during a congestion episode.
>> : If it was not validated, we argue that FS may be much
>> : larger than actual capacity and hence the "-R" reduction is important.
>
> OK, but you do not argue for the -R.  And, if -R is important here is it
> not important everywhere?  You should explain your choices here.
>
We will add text on the -R choice.

>> : Now, your argument isn't quite true. Two things to recall:
>> : First, in the NVP pipeACK is by definition less than (cwnd/2).
>
> OK, fair enough point ... this point was (is) lost on me.  Perhaps the
> document, perhaps my sloppy reading.
>
>> : Fair enough, at this time we didn't see any specific changes to the
>> : algorithm, but a need for clearer rationale and a set of corrections.
>> : We plan to include these in the next revision.
>
> Just to be clear it seems to me this document needs "clearer rationale"
> in a bunch of places (some of which may well overlap) ...
>
> (1) The document should include a discussion of why the current
>     standards (here I am thinking of RFCs 5681 & 2681) are not well
>     suited to modern application behavior.
>
Sure, we'll look to this.

> (2) Since you're proposing something more aggressive I'd think a
>     discussion of not only why an application would want to be more
>     aggressive, but also why it is reasonable to loosen the congestion
>     controller to accommodate such applications.  (E.g., we would agree
>     that an application that wants CBR = 1Gbps with no reduction ever is
>     unreasonable.

:-) I think we can agree that I would argue against that in any draft!

>     So, applications don't always get what they want.
>     What you are trying to do---it seems to me---is give the
>     applications something that helps them out, but that is also
>     reasonable congestion control-wise.)
>
We are indeed trying to give applications something that helps them out,
but is also  reasonable for congestion control. We will look again
how to make the text clearer about this.

> (3) If you're going to strive to meet requirements then we should know
>     what those requirements actually are.  (I am not sure you really
>     need to do either.  But, if you're going to do one, do both.)
>
> (4) The above is big picture stuff.  But, you should justify the
>     mechanism, as well.  Don't just use magic constants without
>     justification (or via fuzzy and ambiguous reasoning).  Don't just
>     add aspects of the response (like the "- R" notion) by claiming they
>     are crucial without explaining.  Etc.  The specifics of the
>     mechanism should be rooted in the overall goals and TCP's standard
>     behavior, it seems to me.  And, you should be able to spell that
>     out.
>
> allman
>
We'll post a new draft when we can finish the text,

Gorry

---

From: Mark Allman <[email-masked]>
Date: Tue, 04 Mar 2014 12:29:28 -0500

> explain why the old terminology is different?:

This text is a start.  Perhaps you need an example to show something
obviously bogus with CWV.

allman