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