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

Bob Briscoe <ietf@bobbriscoe.net> Mon, 08 March 2021 01:55 UTC

Return-Path: <ietf@bobbriscoe.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 906D43A2181 for <tsvwg@ietfa.amsl.com>; Sun, 7 Mar 2021 17:55:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.434
X-Spam-Level:
X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
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 Sqk52fqYFfi1 for <tsvwg@ietfa.amsl.com>; Sun, 7 Mar 2021 17:55:04 -0800 (PST)
Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.84.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389B83A2180 for <tsvwg@ietf.org>; Sun, 7 Mar 2021 17:55:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4NIZIps089Hts7gRGjHyip+LQiwPogXaZpQyo/xOYco=; b=8rZvcehsGED0CwWtgMGBWaBRKB 7bR+RGnCs9y0ru+Psk7wokRfcsHllDgLe4d2cxsVs8THwLIfbBenq3PXgD8vtD6Tv8ZG8M+TJw3oK kyBehtUyDGn0iet2aO5qPoLuti/leQ0xEpXYAHrlDrCOBc2i5CvzLAHSN7yNbWL4HQ+nYzcz82hs/ KgibVUZOb8UECJppe9pK6iJoDrF8kew15ZN0fmA1kaDPJkGQTBYX5j+sPZbdAYi++KFJfk5OukKS1 uN1KIKdvORY3AmOmoL/rFFGwgJm+m4v5LPGOcHay8pyTCQIFmxvt3wmevRai8R1MydKfPBgo6v+q2 Zw0UqlDQ==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:35314 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <ietf@bobbriscoe.net>) id 1lJ56q-0006nh-6G; Mon, 08 Mar 2021 01:55:00 +0000
To: Tom Henderson <tomh@tomh.org>
Cc: tsvwg IETF list <tsvwg@ietf.org>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>
References: <161403126355.2878.575062349927307577@ietfa.amsl.com> <08b94ee3-f0f5-086e-2c89-fe6bc48baf12@tomh.org>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <2a571150-ae32-8451-6103-9f76bc99bee0@bobbriscoe.net>
Date: Mon, 8 Mar 2021 01:54:59 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <08b94ee3-f0f5-086e-2c89-fe6bc48baf12@tomh.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/T_RIYboSWR8p6Rq6GbRS1-Uu0_w>
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 01:55:07 -0000

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

So I think that warrants the word "similar".

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


[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/