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

Tom Henderson <tomh@tomh.org> Mon, 08 March 2021 03:52 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 DC74E3A238E for <tsvwg@ietfa.amsl.com>; Sun, 7 Mar 2021 19:52:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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_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 NQr3ltxX85Ml for <tsvwg@ietfa.amsl.com>; Sun, 7 Mar 2021 19:52:28 -0800 (PST)
Received: from gateway30.websitewelcome.com (gateway30.websitewelcome.com [192.185.192.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5E43A238B for <tsvwg@ietf.org>; Sun, 7 Mar 2021 19:52:28 -0800 (PST)
Received: from cm13.websitewelcome.com (cm13.websitewelcome.com [100.42.49.6]) by gateway30.websitewelcome.com (Postfix) with ESMTP id 88E17C56D for <tsvwg@ietf.org>; Sun, 7 Mar 2021 21:52:27 -0600 (CST)
Received: from box5867.bluehost.com ([162.241.24.113]) by cmsmtp with SMTP id J6wVlDyp34HRaJ6wVlFpjF; Sun, 07 Mar 2021 21:52:27 -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: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=JUjuLPVhVPiPnF24iPkJTMWp3bQCzihSVI/uVwnaZWI=; b=uZ0esl/fQaYo1f/F08+O6J6r6p QYzIqsOcENrRiD5wouUqfhUla1MaX0EmrCT1vlD4EJ+67XCri8NKFjkkwHy7ErabcX4dWqjuGX8dl xNVKHeAX6Pl0j62Wt25+VHRXxn9Nngy79cvxel2EaaqvzOMXCZDSd0MLa3bFJCh7zI7C/XNeOqhYl gKp1K7tPMIJplD6GlXwO41CnhVKeTRQ8Xq+hJHDvf3yUd8nbP7ejthHe9Pr1HCFBhJVM7YRV7q72z sBXXY0bBBGgVik1ehJ8/jYuVb7HUhSPEcEHlIboqaiFbXGK7P9I8M2vp9xbWP6vPH0ZSANRSVb3qz CM6s7GzQ==;
Received: from c-73-35-161-107.hsd1.wa.comcast.net ([73.35.161.107]:48840 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 1lJ6wV-0035F3-9S; Sun, 07 Mar 2021 20:52:27 -0700
To: Bob Briscoe <ietf@bobbriscoe.net>
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> <2a571150-ae32-8451-6103-9f76bc99bee0@bobbriscoe.net>
From: Tom Henderson <tomh@tomh.org>
Message-ID: <0be27223-a7cd-9cfe-a205-46b82431aa23@tomh.org>
Date: Sun, 7 Mar 2021 19:52:26 -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: <2a571150-ae32-8451-6103-9f76bc99bee0@bobbriscoe.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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: 1lJ6wV-0035F3-9S
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]:48840
X-Source-Auth: tomhorg
X-Email-Count: 2
X-Source-Cap: dG9taG9yZzt0b21ob3JnO2JveDU4NjcuYmx1ZWhvc3QuY29t
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/XZMQ5uK_QhRzvqSBkbYWpAc1gZI>
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 03:52:31 -0000

Bob, responding to a couple points below.

On 3/7/21 5:54 PM, Bob Briscoe wrote:
>
>> 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".

In that case, perhaps just call out the differences as follows?

s/is similar to the original (or 'Classic') ECN approach/differs from 
the original (or 'Classic') ECN approach in the following ways/

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

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?

I made the comment because upon first read, I didn't know which traffic 
'it' referred to.  So perhaps change 'it' to 'the former'?

- Tom