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

[Bob Briscoe <[e-mail]>]

Karen,

9331's now fine. Thank you.


Bob

On 13/01/2023 18:08, Karen Moore wrote:
> Hi Bob,
>
> Per your request, we have updated our files to reflect the changes 
> below; please review.  You do not need to provide approval again.
>
>
>> [BB4] yes please. In fact, in 9331, pls use the additional words 
>> below, which are similar to 9330:
>>
>> CURRENT:
>>    Prague [PRAGUE-CC 
>> <https://www.rfc-editor.org/authors/rfc9331.html#I-D.briscoe-iccrg-prague-congestion-control>] [PragueLinux 
>> <https://www.rfc-editor.org/authors/rfc9331.html#PragueLinux>], 
>> BBRv2 [BBRv2 
>> <https://www.rfc-editor.org/authors/rfc9331.html#BBRv2>] [BBR-CC 
>> <https://www.rfc-editor.org/authors/rfc9331.html#I-D.cardwell-iccrg-bbr-congestion-control>], 
>> and...
>> PROPOSED:
>>    Prague *for TCP and QUIC* [PRAGUE-CC 
>> <https://www.rfc-editor.org/authors/rfc9331.html#I-D.briscoe-iccrg-prague-congestion-control>] [PragueLinux 
>> <https://www.rfc-editor.org/authors/rfc9331.html#PragueLinux>], *the 
>> L4S ECN
>>    part of Bottleneck Bandwidth and Round-trip propagation time
>>    (*BBRv2*)* [BBRv2 
>> <https://www.rfc-editor.org/authors/rfc9331.html#BBRv2>] [BBR-CC 
>> <https://www.rfc-editor.org/authors/rfc9331.html#I-D.cardwell-iccrg-bbr-congestion-control>], 
>> and...
>
>
> 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 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
>
> Best regards,
>
> RFC Editor/kc
>
>> On Jan 11, 2023, at 2:04 PM, Karen Moore <[e-mail]> wrote:
>>
>> Hi Martin and authors*,
>>
>> Thank you for your reply; we have noted your approval on the AUTH48 
>> status page for this document. We now have all necessary approvals 
>> and will move this document forward in the publication process (along 
>> with the C350 companion documents).
>>
>> *Authors - please note that the bug affecting the RFC reference 
>> entries has been fixed (i.e., “and RFC Publisher” is no longer 
>> present in the entries). Also, for the RFC-to-be 9330 entry in the 
>> Informative References section, we removed “Braun” from "Marcelo 
>> Bagnulo Braun" to match how his name appears in the document (so it 
>> is now reflected as "Bagnulo, M." instead of "Bagnulo Braun, M.”). 
>> And we updated the title of RFC-to-be 9332 to match the edited document.
>>
>> Note: all hidden comments in this document (and the companion docs) 
>> will be deleted before publication.
>>
>> 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 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
>>
>> For the AUTH48 status of this document, please see:
>> https://www.rfc-editor.org/auth48/rfc9331
>>
>> It has been a pleasure working with this group; thank you for your time!
>>
>> Best regards,
>>
>> RFC Editor/kc
>>
>>> On Jan 11, 2023, at 9:53 AM, Martin Duke <[e-mail]> 
>>> wrote:
>>>
>>> Approved.
>>>
>>> On Mon, Jan 9, 2023 at 12:08 PM Karen Moore <[e-mail]> wrote:
>>> 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/
>>>
>>
>

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