Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-13.txt

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Mon, 08 March 2021 11:43 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 1D3A63A0C00 for <tsvwg@ietfa.amsl.com>; Mon, 8 Mar 2021 03:43:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeYTpP7rBG0I for <tsvwg@ietfa.amsl.com>; Mon, 8 Mar 2021 03:43:48 -0800 (PST)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE64B3A0BFD for <tsvwg@ietf.org>; Mon, 8 Mar 2021 03:43:47 -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 128BhOx1072509; Mon, 8 Mar 2021 03:43:24 -0800 (PST) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 128BhO7b072508; Mon, 8 Mar 2021 03:43:24 -0800 (PST) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202103081143.128BhO7b072508@gndrsh.dnsmgr.net>
In-Reply-To: <2a571150-ae32-8451-6103-9f76bc99bee0@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
Date: Mon, 8 Mar 2021 03:43:24 -0800 (PST)
CC: Tom Henderson <tomh@tomh.org>, tsvwg IETF list <tsvwg@ietf.org>
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/j8SYzq4ImvKJCB_45I8Nd6IwU4I>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-13.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Mar 2021 11:43:50 -0000

Bob,
	Comments inline [RWG].
Regards,
Rod

> Tom,
> 
> On 07/03/2021 20:24, Tom Henderson wrote:
> > Koen and Bob,
> >
> > Below are some comments on draft-ietf-tsvwg-ecn-l4s-id-13 for your and 
> > the working group's consideration.
> >
> > Title
> >
> > The title of this draft suggests that the scope is narrowly defining 
> > the identifier of L4S semantics, but the draft covers much more than 
> > this; in fact, it perhaps it could more accurately be described as an 
> > L4S protocol specification.? At the end of the abstract, the draft 
> > states "This specification defines the rules that L4S transports and 
> > network elements need to follow...", i.e. a protocol.? It also gets 
> > into operational considerations and open questions for experimentation.
> >
> > Perhaps a broader title such as "Explicit Congestion Notification 
> > (ECN) Protocol for Ultra-Low Queuing Delay (L4S)" would better match 
> > the contents.
> 
> [BB] That's a good idea. I like that. Unless anyone shouts, I'll change 
> it to that in my local copy.

 [RWG] I like this title change.

> I intend to post it in the morning, when the IETF servers open.
> It contains some queued up changes that resulted from Koen's Prague 
> Requirements survey - at least those that seemed non-controversial.
> And it will contain the changes from your review below.
> 
> >
> > Abstract
> >
> > 1) If the title is changed to reflect a broader scope, the first 
> > sentence of the abstract should also be changed accordingly.
> >
> > 2) "L4S uses an Explicit Congestion Notification (ECN)
> > ?? scheme that is similar to the original (or 'Classic') ECN approach."
> >
> > Would it be clearer to state that it uses an ECN scheme similar to the 
> > scheme described in RFC 8257 DCTCP (which IMO is distinct from the 
> > original ECN approach)?
> 
> [BB] This is probably nearly as true, but the purpose of this sentence 
> was to help readers who might already know the RFC3168 scheme. I think 
> that's likely to be a much larger set than those who know DCTCP. (Think 
> of all the training courses and Web pages that describe the IP header, 
> and the function of the fields).
> 
> RFC3168 defines the codepoints and the valid transitions of the ECN 
> protocol. The L4S ECN protocol keeps all that, and the semantics of the 
> codepoints. The main difference is that ECT(1) is no longer equivalent 
> to ECT(0), although they still both have the meaning of ECN-capable 
> transport and unmarked.

 [RWG] I would consider the redefinition of the meaning of a CE mark
to be NOT keeping the semantics of the codepoints as defined by RFC 3168.
I disagree on what the main difference is, it is not just that
ECT(0) and (1) now have different meanings, it is that CE is redefined
when ECT(1) is present.  Further more that difference is lost to
the rest of the network, except the receiving end, once a CE mark has
been applied.

> 
> So I think that warrants the word "similar".

 [RWG] Either word is valid, it is similar in some ways and different
in others.  Perhaps best to cover both?

> 
> >
> > 1. Introduction
> >
> > 1) See comment 1 and 2 of Abstract; applicable here as well.
> 
> [BB] Yup to 1 again, but same comment about 2.
> 
> >
> > 2) The goal of less than 1 ms average queuing delay probably should be 
> > qualified; e.g. something like "on networks not subject to multiple 
> > access delays above these thresholds"
> 
> [BB] OK. How about "queuing delay... due to e2e congestion control"
> Meaning if no possible alteration to the behaviour of the e2e CC can 
> reduce a certain type of queuing delay (e.g. queuing for medium access) 
> it's not due to e2e CC.
> 
> >
> > 3) s/transport wire protocol/transport protocol/
> 
> [BB] OK
> 
> >
> > 4) s/prevent it from/prevent such queues from
> 
> [BB] Don't agree here.
> There's been no mention yet of any queues that "such queues" could refer 
> back to.
> 
> The full clause was:
> "...isolate existing Classic traffic from L4S traffic to prevent it from 
> degrading"
> 
> The 'it' here means the existing Classic traffic. If this was unclear 
> I'd happily change it, but I think it's OK as it is, isn't it?

 [RWG] No.  Better to be as clear as possible, these "clear to us" native
english speakers often become unclear when read by non-native speakers.

> [BB] I'll continue tomorrow... need sleep.
> But thx for taking the time to do this.
> 
> Cheers
> 
> 
> 
> Bob
> 
> 
> >
> > 1.1 Latency, Loss and Scaling Problem
> >
> > 1) "Latency is becoming the critical performance factor for many (most?)
> > ?? applications on the public Internet"
> >
> > perhaps soften this to "Latency control is becoming increasingly 
> > important for applications on the public Internet"
> >
> > 2) It seems to me that the paragraph starting with "The DualQ solution 
> > was developed..." could be deleted.? Perhaps instead in the paragraph 
> > before, shorten to state "L4S isolation can be achieved with a queue 
> > per flow (e.g. [RFC8290]) or a DualQ 
> > [I-D.ietf-tsvwg-aqm-dualq-coupled]; both approaches are addressed in 
> > this document."? My rationale for suggesting this is that pros and 
> > cons of different AQMs seems out of scope for this document.
> >
> > 1.2 Terminology
> >
> > 1) The sentence "So it takes longer" is a fragment that could be 
> > appended to the previous.
> >
> > 2) the second paragraph of Classic Congestion Control definition 
> > doesn't seem to be about terminology.? Perhaps consider to move 
> > commentary that isn't about clarifying and distinguishing terms out of 
> > this section.
> >
> > 3) For Reno-friendly, rather than defining it as what it is not 
> > ('subset of traffic that excludes...'), define what it is (e.g. 
> > 'consistent with fairness goals, as described in RFC 2914, in the 
> > presence of other flows using congestion control based on RFC 5681').
> >
> > 2. Consensus Choice of L4S Packet Identifier:? Requirements
> >
> > IMO, this entire section about rationale probably belongs in a 
> > separate appendix or merged with existing Appendix B.? I would suggest 
> > to keep the main sections in this draft about specification as much as 
> > possible.
> >
> > 3. L4S Packet Identification at Run-Time
> >
> > 1) Consider to change the title to 'L4S Packet Identification' (i.e. 
> > drop 'at Run-Time').
> >
> > 2) Consider to change (for more clarity here):
> >
> > ?? "A network node that implements the L4S service normally classifies
> > ?? arriving ECT(1) and CE packets for L4S treatment."
> >
> > to
> >
> > ?? "A network node that implements the L4S service always classifies
> > ?? arriving ECT(1) packets as belonging to the L4S service, and, by 
> > default, classifies arriving CE packets as belonging to the L4S 
> > service, unless other heuristics as described below in Section 5.3 are 
> > employed."
> >
> > 4.? Prerequisite Transport Layer Behavior (the "Prague Requirements")
> >
> > I suggest to change most, if not all, uses of 'prerequisite' to 
> > 'requirement' or else avoid the term.? For instance, the title could 
> > be "Transport Layer Requirements".
> >
> > 4.3 Prerequisite Congestion Response
> >
> > In general, in the first paragraph, I wonder if the congestion 
> > response could be defined more directly in a prescriptive manner for 
> > endpoints (and also for compliance detection in the network), such as 
> > stating that the endpoint must track its base RTT, and it must reduce 
> > its sending rate when it observes more than two reported CE marks per 
> > RTT, possibly averaged over some time scale.
> >
> > 5.1. Prerequisite Classification and Re-Marking Behavior
> >
> > paragraph 3:? The term 'Classic drop' is undefined earlier and 
> > probably should be defined in the terminology section or clarified here.
> >
> > 5.2. The Meaning of L4S CE Relative to Drop
> >
> > I wonder whether this section could be clarified by stating first that 
> > in a dual queue structure with FIFO scheduling, the stated 
> > relationship must be observed, but in a flow queue scheduled AQM, each 
> > flow queue operates independently in this regard?? The title could 
> > also perhaps substitute 'Relationship' for 'Meaning'.
> >
> > ----
> >
> > I did not have time to review the appendices today.
> >
> > - Tom
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
> 
> 

-- 
Rod Grimes                                                 rgrimes@freebsd.org