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

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Wed, 13 November 2024 19:13 UTC

Return-Path: <ietf@gndrsh.dnsmgr.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B41C14F701; Wed, 13 Nov 2024 11:13:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9b7EMQfaV8A; Wed, 13 Nov 2024 11:13:36 -0800 (PST)
Received: from afbr1.dnsmgr.net (sce.dnsmgr.net [65.75.216.238]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CAE9C14F6F0; Wed, 13 Nov 2024 11:13:36 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 4ADJCUKs075412; Wed, 13 Nov 2024 11:12:30 -0800 (PST) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 4ADJCS7O075411; Wed, 13 Nov 2024 11:12:28 -0800 (PST) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202411131912.4ADJCS7O075411@gndrsh.dnsmgr.net>
In-Reply-To: <0a97a22b-fe3c-484a-a74b-a56c246b5021@erg.abdn.ac.uk>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Date: Wed, 13 Nov 2024 11:12:28 -0800
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-ID-Hash: MXHFQHDN2YZ756MRG2CZ4HT26ARH2RLH
X-Message-ID-Hash: MXHFQHDN2YZ756MRG2CZ4HT26ARH2RLH
X-MailFrom: ietf@gndrsh.dnsmgr.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tsvwg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org>, draft-duke-tsvwg-udp-ecn@ietf.org, tsvwg IETF list <tsvwg@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [tsvwg] Re: editorial comments on draft-duke-tsvwg-udp-ecn-03: "ECN mark" vs "codepoint"
List-Id: Transport Area Working Group <tsvwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/EDoWsI92tTLYjoFJ7ihI40Yt_FA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Owner: <mailto:tsvwg-owner@ietf.org>
List-Post: <mailto:tsvwg@ietf.org>
List-Subscribe: <mailto:tsvwg-join@ietf.org>
List-Unsubscribe: <mailto:tsvwg-leave@ietf.org>

> 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.

Personally I would prefer the exactness of saying "apply the CE codepoint value".

> 
> 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.

I agree on this point, TOS/ToS should not be used in any new documents,
these fields are now known as the "DSCP codepoints and ECN codepoints".
IMHO if TOS is mentioned it should be tightly coupled with the word
"legacy", as in "the Legacy TOS byte."

> Best wishes,
> Gorry
> (as an Individual)

-- 
Rod Grimes                                                 rgrimes@freebsd.org