[tsvwg] Re: editorial comments on draft-duke-tsvwg-udp-ecn-03: "ECN mark" vs "codepoint"

[Gorry Fairhurst <[e-mail]>]

On 13/11/2024 14:02, Neal Cardwell wrote:
> A quick editorial suggestion on draft-duke-tsvwg-udp-ecn-03:
>
> It looks like this draft mostly uses variants of the phrase "ECN mark" 
> (18 occurrences) to mean the two-bit ECN-related values in a packet, 
> and only uses the phrase "codepoint" twice.
>
> RFC 3168 (classic ECN) is fairly consistent in using the phrase 
> "codepoint" to refer to those two ECN-related bits. And RFC 3168 only 
> uses the phrase "ECN marking" as the process of applying the CE code 
> point ("replaced by CE when ECN marking occurs in response to 
> congestion or incipient congestion").
>
> RFC 9331 (L4S ECN) is in line with RFC 3168: the two bits are the 
> "codepoint", "ECN mark" means CE, and "ECN marking" means changing the 
> codepoint to CE.
>
> In line with RFC 3168 and RFC 9331, in my experience, the phrase "ECN 
> mark"  is most commonly used for the CE code point.
>
> For clarity, I'd suggest that the draft-duke-tsvwg-udp-ecn align with 
> RFC 3168 and RFC 9331 terminology in this regard.
>
> best regards,
> neal
>
While we're discussing terms (and assuming you;re tracking issues...

I'd personally prefer CE-Mark, rather than ECN-Mark, to avoid any ambiguity.

Another thing that comes to mind, is did you test ability of a sender to 
set a CE-Mark, because some proposals have used that in the past as part 
of their path probing to see if the receiver correctly reports the CE-Marks?

I'd also encourage not using the word "TOS byte" if we can, because this 
kind of perpetuates the idea that ToS exists, which can lead to some 
akward pathologies with respect to DSCP and ECN codepoints, or I'd 
suggest at least merits statements that ToS is not recommended any more.

Best wishes,

Gorry

(as an Individual)