Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <draft-ietf-tsvwg-ecn-l4s-id-29> for your review

[Bob Briscoe <[e-mail]>]

Martin (and Karen,)

On 06/01/2023 18:47, Martin Duke wrote:
> Bob,
>
> In case this was lost in the holiday shuffle, the ball is in your court.

[BB3] Thanks. I had read all the emails, but it wasn't clear to me that 
I had been given the edit token on ecn-l4s-id.
I will set to re-expanding some abbreviations in the XML now. This is 
the approach I shall take:

For the example list of transport protocols in the intro, I will go back 
to the RFC Editor's first approach of expanding the "non-core" protocol 
names, instead of including citations for DCCP and SCTP (which are cited 
later when each protocol is actually discussed).


      1. Intro.


CURRENT:
    The transport wire protocol, e.g., TCP,
    QUIC, SCTP [RFC4960 
<https://www.rfc-editor.org/authors/rfc9331.html#RFC4960>], DCCP 
[RFC4340 <https://www.rfc-editor.org/authors/rfc9331.html#RFC4340>], or 
RTP/RTCP, is orthogonal (and
    therefore not suitable for distinguishing L4S from Classic packets).

PROPOSED:
    The transport wire protocol, e.g., TCP,
    QUIC, the Stream Control Transmission Protocol (SCTP), the Datagram
    Congestion Control Protocol (DCCP), and RTP/RTCP, is orthogonal (and
    therefore not suitable for distinguishing L4S from Classic packets).


        1.1. Latency, Loss, and Scaling Problems


For the list of AQMs, I'll take a similar approach to that you've just 
approved for the DualQ draft, except RED has already been expanded at 
this point. Specifically:

CURRENT:
    However, Random Early Detection (RED) and other algorithms from the 
1990s were sensitive...
...
    More recent state-of-the-art AQM methods, such as FQ-CoDel [RFC8290 
<https://www.rfc-editor.org/authors/rfc9331.html#RFC8290>],
    PIE [RFC8033 
<https://www.rfc-editor.org/authors/rfc9331.html#RFC8033>], or Adaptive 
RED [ARED01 <https://www.rfc-editor.org/authors/rfc9331.html#ARED01>],...
...
    This was useful because per-flow queuing (FQ) ....

PROPOSED:
    However, Random Early Detection (RED) and other algorithms from the 
1990s were sensitive...
...
    More recent state-of-the-art AQM methods, such as Flow Queue CoDel 
[RFC8290 <https://www.rfc-editor.org/authors/rfc9331.html#RFC8290>],
    Proportional Integral controller Enhanced (PIE) [RFC8033 
<https://www.rfc-editor.org/authors/rfc9331.html#RFC8033>], or Adaptive 
RED [ARED01 <https://www.rfc-editor.org/authors/rfc9331.html#ARED01>], ...
...
    This was useful because per-flow queuing (FQ) ...


      Deeper into the Document


I'll add back expansions of EH, ESP, TRILL etc.


Bob

>
> On Wed, Dec 28, 2022 at 10:24 AM Martin Duke <[e-mail]> 
> wrote:
>
>     I'm sympathetic to the desire to keep sentences brisk, but I find
>     the idea that these acronyms are stashed in the references list to
>     be reader-hostile. Would it be too much to ask for a short
>     glossary just after the introduction to spell these out?
>
>     On Thu, Dec 22, 2022 at 4:27 PM Bob Briscoe <[e-mail]>
>     wrote:
>
>         Gorry,
>
>         On 22/12/2022 09:20, Gorry Fairhurst wrote:
>>         On 21/12/2022 21:46, Bob Briscoe wrote:
>>>         Martin,
>>>
>>>         On 20/12/2022 19:24, Martin Duke wrote:
>>>>
>>>>
>>>>         On Sat, Dec 17, 2022 at 7:16 AM Bob Briscoe
>>>>         <[e-mail]> wrote:
>>>>
>>>>             Martin,
>>>>
>>>>             On 16/12/2022 23:22, Martin Duke wrote:
>>>>>             There is a lot of email about this; pardon me if it's
>>>>>             been thoroughly discussed:
>>>>>
>>>>>             (1) I don't understand why we edited out introducing
>>>>>             acronyms on first use:
>>>>>             DCTCP, FQ-Codel, PIE, TRILL, EH, ESP
>>>>
>>>>             [BB] We persuaded the RFC Editor to expand or not on a
>>>>             case-by-case basis rather than following an
>>>>             "expand-on-first-use" rule too rigidly.
>>>>             Before the RFC Editor process, we had judged that these
>>>>             particular ones were:
>>>>             * better known by their abbreviation than their expansion
>>>>             * easily look-up-able for anyone interested in the
>>>>             expansion, via the title of the reference cited beside them
>>>>             * and they were within a sentence that was already
>>>>             long, so an (unnecessary) expansion would make it
>>>>             overly long and complicated.
>>>>
>>>>             In the case of DCTCP, it's expansion adds important
>>>>             context, but the first use is in an already complex
>>>>             sentence. So, at the first use it says "the DCTCP/DualQ
>>>>             solution described below", and it is expanded in the
>>>>             next para.
>>>>
>>>>             Also, FQ is expanded elsewhere 'cos it's meaning is
>>>>             important, but CoDel is only expanded in the cited
>>>>             title of its reference.
>>>>
>>>>
>>>>         OK, you've clearly thought through the sequencing here. I'm
>>>>         not going to insist on first-use, but I do think these
>>>>         acronym expansions should be somewhere in the document,
>>>>         either in a glossary or in subsequent use, as you've done
>>>>         with DCTCP.
>>>
>>>         [BB2] Does "somewhere in the document" include in the title
>>>         of a reference cited where the abbreviation is first used
>>>         (e.g. DCCP [RFC4340])?
>>>         I've tried to only do this where the expansion isn't central
>>>         to understanding the document, and expanding it on first use
>>>         subtracts from the sense of the sentence.
>>>
>>>
>>>         Bob
>>
>>         Before a draft leaves the TSVWG, we would normally check that
>>         all acronyms are expanded on their first use within the body
>>         of the text (the abstract is treated separately and needs to
>>         have its own definitions). I still think this is an
>>         important, rather than requiring readers to consult another
>>         document to understand if they have correctly interpreted an
>>         acronym.
>>
>
>         [BB] We're not saying anyone has to consult another document -
>         just consult the title of the reference cited in /this/
>         document. And this is only for any abbreviation that:
>         1. is known by it's abbreviation (by those familiar with it)
>         2. would make a sentence in the intro hard to follow if all
>         abbreviations were expanded
>         3. is only mentioned in passing so it isn't necessary for
>         understanding the document.
>
>>         On this document, I leave it to Martin to decide whether
>>         there is reason to do otherwise.
>>
>
>         [BB] Yup.
>         Thanks
>
>
>         Bob
>
>>         Gorry
>>
>>         (TSVWG Co-Chair)
>>
>>>
>>>
>>>>>             (2) This edit in Sec 5.1 seems non-cosmetic.
>>>>>             In case unforeseen problems arise with the L4S experiment, it MUST be
>>>>>                 possible to configure an L4S implementation to disable the L4S
>>>>>                 treatment.  Once disabled,all packets of all ECN codepoints will receive Classic
>>>>>             treatment, and  ECT(1) packets MUST be treated as if they
>>>>>                 were Not-ECT.
>>>>>             I agree that the original text was ambiguously worded,
>>>>>             but the common-sense reading of the original (given
>>>>>             that this is a section about network nodes) is that
>>>>>             ECT(1) would
>>>>>             go in the ECT(0) queue and be marked CE in accordance
>>>>>             with the RFC 3168 rules. The new text is different. I
>>>>>             can see advantages to the new rule but I wonder if we have
>>>>>             consensus for this change?
>>>>
>>>>             [BB] Yes, but common sense might be in short supply.
>>>>             "Classic treatment" could be incorrectly taken to mean
>>>>             "Classic ECN treatment".
>>>>             This sentence went through an intermediate version,
>>>>             which you might prefer because it stays closer to the
>>>>             original:
>>>>
>>>>             In case unforeseen problems arise with the L4S experiment, it MUST be
>>>>                 possible to configure an L4S implementation to disable the L4S
>>>>                 treatment.  Once disabled,all packets of all ECN codepoints will receive Classic
>>>>             treatment, and  ECT(1) packets MUST be treated as if they
>>>>                 were Not-ECT*, then all packets of all ECN codepoints will**  
>>>>             receive treatment compatible with Classic congestion
>>>>             control*.
>>>>
>>>>
>>>>             But, in the most recent edits, I asked the RFC Editor
>>>>             to take out the final clause completely at the
>>>>             suggestion of my co-authors.
>>>>             We can leave it in if you'd rather.
>>>>
>>>>
>>>>         I think I ave misinterpreted the diff. This is fine as-is.
>>>
>>>         -- 
>>>         ________________________________________________________________
>>>         Bob Briscoehttp://bobbriscoe.net/
>>
>>
>
>         -- 
>         ________________________________________________________________
>         Bob Briscoehttp://bobbriscoe.net/
>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/