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

[Bob Briscoe <[e-mail]>]

Koen,

I agree with 'misuse',

PI2 wasn't forgotten; it's more a question of whether it should be 
included in a list of AQM methods that predated this draft. I didn't 
think it should....
...When looked at one way, it should, and I imagine you're wanting to 
give PI2 the same status as the other AQMs. But the position of PI2 
relative to DualPI2 is probably a source of confusion for most people, 
so I think it's best to rely on the explanation later in this draft, 
otherwise, introducing PI2 here before the explanation will  cause most 
readers to get confused, or at minimum, to do a double-take.


Bob

On 08/01/2023 14:35, Koen De Schepper (Nokia) wrote:
>
> Hi Bob, Karen,
>
> I just did a read throughout the whole document again and I saw only 
> following nits which could be added/changed:
>
> Didn’t we forgot to mention PI2 in this list?
>
>    More recent state-of-the-art AQM methods, such as Flow Queue CoDel 
> [RFC8290],
>
>    Proportional Integral controller Enhanced (PIE) [RFC8033], 
> Proportional Integral Improved with a square [PI2] or Adaptive RED 
> [ARED01], ...
>
> Mis-use -> misuse? Intentionally or was it a hyphen leftover from a 
> line-wrap?
>
>    Approaches to assure the integrity of signals using the new
>
>    identifier are introduced in Appendix C.1.  See the security
>
>    considerations in the L4S architecture [RFC9330] for further
>
>    discussion of mis-use of the identifier, as well as extensive
>
>    discussion of policing rate and latency in regard to L4S.
>
> I’ll let you sort out the acronym expansion (as I don’t have a strong 
> preference). So independent of the acceptance of the above nits and 
> acronym settlement, I can already approve this document.
>
> Thanks,
>
> Koen.
>
> *From:* Bob Briscoe <[e-mail]>
> *Sent:* Saturday, January 7, 2023 6:25 PM
> *To:* Martin Duke <[e-mail]>; Karen Moore <[e-mail]>
> *Cc:* Gorry Fairhurst <[e-mail]>; Koen De Schepper (Nokia) 
> <[e-mail]>; RFC Editor 
> <[e-mail]>; [e-mail]; 
> [e-mail]; Wesley Eddy <[e-mail]>; 
> [e-mail]
> *Subject:* Re: [AD] [C350] AUTH48: RFC-to-be 9331 
> <draft-ietf-tsvwg-ecn-l4s-id-29> for your review
>
> 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,
>                                     andECT(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,
>                                 andECT(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 Briscoe http://bobbriscoe.net/  <http://bobbriscoe.net/>
>
>
>
>                 -- 
>
>                 ________________________________________________________________
>
>                 Bob Briscoe http://bobbriscoe.net/  <http://bobbriscoe.net/>
>
>
>
>     -- 
>
>     ________________________________________________________________
>
>     Bob Briscoe http://bobbriscoe.net/  <http://bobbriscoe.net/>
>
>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

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