Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-13.txt
Tom Henderson <tomh@tomh.org> Sun, 07 March 2021 20:24 UTC
Return-Path: <tomh@tomh.org>
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 0C3373A1C38 for <tsvwg@ietfa.amsl.com>; Sun, 7 Mar 2021 12:24:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tomh.org
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 zY_H578iYnAL for <tsvwg@ietfa.amsl.com>; Sun, 7 Mar 2021 12:24:15 -0800 (PST)
Received: from gateway30.websitewelcome.com (gateway30.websitewelcome.com [192.185.145.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94223A1C3D for <tsvwg@ietf.org>; Sun, 7 Mar 2021 12:24:10 -0800 (PST)
Received: from cm13.websitewelcome.com (cm13.websitewelcome.com [100.42.49.6]) by gateway30.websitewelcome.com (Postfix) with ESMTP id 567E3EFAD for <tsvwg@ietf.org>; Sun, 7 Mar 2021 14:24:10 -0600 (CST)
Received: from box5867.bluehost.com ([162.241.24.113]) by cmsmtp with SMTP id Izwgl8mdG4HRaIzwglAkjQ; Sun, 07 Mar 2021 14:24:10 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References: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=WR+/MFSNlFd8jnQ4N1nhfWBl7lV/G2/OaYeG9k76sOI=; b=FVGNjIfCxfimecGPGyCVPZoCLR xervUC3i9sYvNkR3VlWzVevRY8ALZoJyRKDbnW2D5txQ/asI9kglRiEMOnjuq0gLdbA9AO1CFzxue lIjeOBxB2eZvwub/UOBfDjS1tK2XjXZ85fxUtVjTIvBx++b8NPBOLKn4kROy5xKxZuJxtzbZNHPE8 xVJluwPE566RMCfzUgWmCG7n3AiZXD7uQfD7Lq/0fUpGaha5VorWXEbfS6CQr0D2v+F7cNVaU0eTa A8eSHFpCc85z7MSHTgTQNmeaMCWClLyWDsI3CZyxvRAHzUiKZR9e1oQm/81a+RCWX5B4RG/Bn8uIw 0bxF3HcA==;
Received: from c-73-35-161-107.hsd1.wa.comcast.net ([73.35.161.107]:46212 helo=[192.168.168.110]) by box5867.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <tomh@tomh.org>) id 1lIzwf-003NcU-Ub; Sun, 07 Mar 2021 13:24:10 -0700
To: Bob Briscoe <ietf@bobbriscoe.net>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>
References: <161403126355.2878.575062349927307577@ietfa.amsl.com>
Cc: tsvwg IETF list <tsvwg@ietf.org>
From: Tom Henderson <tomh@tomh.org>
Message-ID: <08b94ee3-f0f5-086e-2c89-fe6bc48baf12@tomh.org>
Date: Sun, 07 Mar 2021 12:24:08 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <161403126355.2878.575062349927307577@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box5867.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - tomh.org
X-BWhitelist: no
X-Source-IP: 73.35.161.107
X-Source-L: No
X-Exim-ID: 1lIzwf-003NcU-Ub
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: c-73-35-161-107.hsd1.wa.comcast.net ([192.168.168.110]) [73.35.161.107]:46212
X-Source-Auth: tomhorg
X-Email-Count: 3
X-Source-Cap: dG9taG9yZzt0b21ob3JnO2JveDU4NjcuYmx1ZWhvc3QuY29t
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/O0dRmO_hYUuqlFfh8zU4WGFvnbA>
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: Sun, 07 Mar 2021 20:24:17 -0000
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. 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)? 1. Introduction 1) See comment 1 and 2 of Abstract; applicable here as well. 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" 3) s/transport wire protocol/transport protocol/ 4) s/prevent it from/prevent such queues from 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
- [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-1… internet-drafts
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Asad Sajjad Ahmed
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Ingemar Johansson S
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Ingemar Johansson S
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Asad Sajjad Ahmed
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Ingemar Johansson S
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Rodney W. Grimes
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Ingemar Johansson S
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Asad Sajjad Ahmed
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Asad Sajjad Ahmed
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Tom Henderson
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Tom Henderson
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Rodney W. Grimes
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-… Bob Briscoe