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,

I've re-expanded the remaining abbreviations in the att'd XML, as I said 
I would in my email below:
     rfc9331j.xml
Also, I've att'd the diff from Karen's latest edit (which I've denoted 
as "rfc9331i"):
     rfc9331j-from-i.diff.html


Bob

On 07/01/2023 16:35, Bob Briscoe wrote:
> 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/

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