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

["Koen De Schepper (Nokia)" <[e-mail]>]

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]<mailto:[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]<mailto:[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]<mailto:[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/