Re: [tsvwg] Review comments on a careful read of the L4S ID (nits)

[Bob Briscoe <[e-mail]>]

Gorry, all,

I've recorded here how I dealt with nits, unless I just did as asked.
See [BB]

On 06/05/2021 07:52, Gorry Fairhurst wrote:
>
> *These points below are Nits, but if you don’t think so, we can 
> discuss more?*
>
> **
>
> =================================================================
>
> **
>
> *A. Applications?*
>
> This text:
>
> “it SHOULD survive end-to-end between source and destination applications”
>
> ⁃Unclear what applications mean here?
>

[BB] end-points

> =================================================================
>
> *B. List style uses semicolon at end of item?*
>
> “oit SHOULD be visible at the IP layer”
>
> ⁃add semicolon to match style of list.
>
> =================================================================
>
> *C. Seems very similar, does it need to be repeated?*
>
> This para in section 5.2, seems very similar to the para in section 5.1.
>
> “Note that, contrary to RFC 3168, a Dual Queue Coupled AQM
>
> implementing the L4S and Classic treatments does not mark an ECT(1)
>
> packet under the same conditions that it would have dropped a Not-ECT
>
> packet, as allowed by [RFC8311], which updates RFC 3168.However, if
>
> it marks ECT(0) packets, it does so under the same conditions that it
>
> would have dropped a Not-ECT packet.”
>
> ⁃Seems very similar, does it need to be repeated? Can this text be 
> reduced/removed?
>

In S.5.1, I've referred forward to 5.2 for the relative strengths:

    This
    Classic AQM treatment need not mark ECT(0) packets, but if it does,
    see Section 5.2 for the strengths of the markings relative to drop.



> =================================================================
>
> *D. Seems very similar, does it need to be repeated?*
>
> In sect 5.2, can we remove:
>
> “Also, L4S CE marking needs to be interpreted as an unsmoothed signal,
>
> in contrast to the Classic approach in which AQMs filter out
>
> variations before signalling congestion.“
>
> ⁃Could this simply refer to section 4.4?
>

[BB] Deliberate. S.4 is for transports. S.5 is for network AQMs.
A CC developer might solely focus on reading S.4, and an AQM developer 
only S.5

> =================================================================
>
> *E. I don’t understand this:*
>
> “_(or perhaps they comply with L4S behaviour and can respond to ECN_
>
> _feedback, but perhaps cannot set the ECN field for some reason)_”
>
> ⁃What is the extra point here in brackets? and how can the flow be 
> compliant but not set ECT(1) and so doesn’t respond… This all seems 
> like a difficult point to pursue - or maybe it simply does not need to 
> be said at all. Can we delete this parenthesis?
>

[BB] I've changed it to:
     "address ranges of specific applications or hosts configured to be, 
or known to be, safe, e.g. hard-coded IoT devices sending low intensity 
traffic;"

FYI, the original text was thinking of some consumer device where you 
can modify the congestion control, but packet sending is done with 
unmodifiable hardware. However, that's not a good example of low latency 
but non-L4S, so I've used IoT instead.

> =================================================================
>
> *F. NiT: lightweight*
>
> “certain protocols that are usually _lightweight_
>
> “
>
> ⁃I think we have elsewhere called these “Low Data-Volume 
> Applications”. The term lightweight is used in other places in the 
> IETF for other meanings.
>
> =================================================================
>
> *G. What does this sentence mean, and why say it?*
>
> **
>
> *“*Of course, a packet that carried both the ECT(1) codepoint and a non-
>
> ECN identifier associated with the L queue would be classified into
>
> the L queue.”
>
> ⁃This confuses me - is it saying that NQB would be classified to the L 
> queue, even if ECT(1)-marked, which isn’t something you talk about. or 
> is it implying more. If this is what you intend, I think it would be 
> much clearer to say nothing, or explain more.
>

[BB] First, a picky point: NQB does not go into the same queue as L4S 
unless the operator arranges it (which is the case in DOCSIS, but other 
operators can do what they want). Assuming it does then, yes, a packet 
with both markings would be classified into the L queue. I think this is 
so obvious it's taken you unawares. So I've changed it round as follows:

    A packet that carries one of these non-ECN identifiers to classify it
    into the L queue would not be subject to the L4S ECN marking
    treatment, unless it also carried an ECT(1) or CE codepoint.  The
    specification of an L4S AQM MUST define the behaviour for packets
    with unexpected combinations of codepoints, e.g. a non-ECN-based
    classifier for the L queue, but ECT(0) in the ECN field (for examples
    see section 2.5.1.1 of [I-D.ietf-tsvwg-aqm-dualq-coupled]).


> ⁃The following paras are also maybe to exhaustive, maybe it is rather 
> worth writing this simply.
>

[BB] I can't think how to say these things more simply. Pls suggest text 
if you have ideas.


> =================================================================
>
> *H. List style uses semicolon at end of item?*
>
> In sect 6.2, and6.3. Theitems in the bullet list do not end in 
> semi-colons; but do elsewhere.
>
> =================================================================
>
> *I. List style uses semicolon at end of item?*
>
> Editorial Annex 1:
>
> “ But they cannot
>
> easily satisfy this loss recovery requirement._However, it is_
>
> _believed they do not need to. _It is believed that such
>
> implementations solely exist in controlled environments,…“
>
> ⁃GF: is the sentence with “however...” strictly required here? I fear 
> it could be mistakenly read, and without it, the next sentence is 
> clear about what is intended.
>

[BB] I've run the two together:

"However, it is believed they do not need to, because such 
implementations are believed to solely exist in controlled environments, 
where the network technology keeps reordering extremely low anyway."

> =================================================================
>
> *J. Please don’t assume what TCPM will publish.*
>
> “This means these packets
>
> are not protected from congestion loss by ECN, which considerably
>
> harms performance, particularly for short flows.
>
> [I-D.ietf-tcpm-generalized-ecn] _counters each argument in RFC 3168 in_
>
> _turn, showing it was over-cautious.Instead it _proposes experimental
>
> use of ECN on all types of TCP packet as long as AccECN feedback
>
> [I-D.ietf-tcpm-accurate-ecn] is available (which itself satisfies the
>
> accurate feedback requirement in Section 4.2 for using a scalable
>
> congestion control).”
>
> ⁃I don’t like this interpretation of what TCPM will finally conclude 
> is useful. It’s OK to say this proposes something, if you want to say 
> it concludes something then we need to block publication on the prior 
> publication of the other ID. Can you please please remove “counters 
> each argument in RFC 3168 in turn, showing it was 
> over-cautious.Instead it “
>
> =================================================================
>
> *K. Typo?*
>
> “to 4 4 Mb/s”
>
> ⁃is this correct?
>
[BB] Good catch - meant to be just 4 Mb/s

As always many many thanks for catching all these.

Cheers



Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/