Re: [tcpm] thoughts on newcwv-05

[Mark Allman <[e-mail]>]

> : 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.

> : 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.

> : 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.

(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.  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.)

(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