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

[Karen Moore <[e-mail]>]

Hi Bob, Koen, and Martin (AD)*,

Thank you for your replies.  Our files have been updated to reflect Bob’s changes, and we have removed the hyphen from one 1 instance of “mis-use” per Koen’s suggestion.  We have not made any further changes in regard to “P12”; if you would like to, please let us know. We also noted Koen’s approval of the document on the AUTH48 status page.

*Martin, please review the expansions that were added in Sections 1, 1.1, 1.3, 6.1, and 6.2 and let us know if you approve or if any further edits are needed.  You can view the changes here: https://www.rfc-editor.org/authors/rfc9331-lastdiff.html.

--------
FILES
(Please refresh)

The updated XML file is here:
https://www.rfc-editor.org/authors/rfc9331.xml

The updated output files are here:
https://www.rfc-editor.org/authors/rfc9331.txt
https://www.rfc-editor.org/authors/rfc9331.pdf
https://www.rfc-editor.org/authors/rfc9331.html

These diff files show all changes made during AUTH48:
https://www.rfc-editor.org/authors/rfc9331-auth48diff.html
https://www.rfc-editor.org/authors/rfc9331-rfcdiff.html (side by side)

These diff files show only changes made during the last editing round:
https://www.rfc-editor.org/authors/rfc9331-lastdiff.html
https://www.rfc-editor.org/authors/rfc9331-lastrfcdiff.html (side by side)

This diff file shows all changes made to date:
https://www.rfc-editor.org/authors/rfc9331-diff.html

Please contact us with any further updates or with your approval of the document in its current form.  We will await approval from Martin prior to moving forward in the publication process.

For the AUTH48 status of this document, please see:
https://www.rfc-editor.org/auth48/rfc9331

Best regards,

RFC Editor/kc


> On Jan 9, 2023, at 6:51 AM, Bob Briscoe <[e-mail]> wrote:
> 
> 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], DCCP [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], 
>>    PIE [RFC8033], or Adaptive RED [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], 
>>    Proportional Integral controller Enhanced (PIE) [RFC8033], or Adaptive RED [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 Briscoe                               http://bobbriscoe.net/
>>  
>> 
>> 
>> 
>> -- 
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/
>> 
>> 
>> -- 
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/
>> 
>> 
>> -- 
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               
> http://bobbriscoe.net/