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

Tom Henderson <> Mon, 08 March 2021 03:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC74E3A238E for <>; Sun, 7 Mar 2021 19:52:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.101
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NQr3ltxX85Ml for <>; Sun, 7 Mar 2021 19:52:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A5E43A238B for <>; Sun, 7 Mar 2021 19:52:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 88E17C56D for <>; Sun, 7 Mar 2021 21:52:27 -0600 (CST)
Received: from ([]) 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;; 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 ([]:48840 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <>) id 1lJ6wV-0035F3-9S; Sun, 07 Mar 2021 20:52:27 -0700
To: Bob Briscoe <>
Cc: tsvwg IETF list <>, "De Schepper, Koen (Nokia - BE/Antwerp)" <>
References: <> <> <>
From: Tom Henderson <>
Message-ID: <>
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: <>
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 -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Source-L: No
X-Exim-ID: 1lJ6wV-0035F3-9S
X-Source-Sender: ([]) []:48840
X-Source-Auth: tomhorg
X-Email-Count: 2
X-Source-Cap: dG9taG9yZzt0b21ob3JnO2JveDU4NjcuYmx1ZWhvc3QuY29t
X-Local-Domain: yes
Archived-At: <>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-13.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


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