Re: [tcpm] [tsvwg] draft-ietf-tsvwg-ecn-l4s-id

Bob Briscoe <> Mon, 11 November 2019 09:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF050120288; Mon, 11 Nov 2019 01:39:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 VFvwcJ8SYpHQ; Mon, 11 Nov 2019 01:39:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DB07120013; Mon, 11 Nov 2019 01:39:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:References:Cc:To:From:Subject:Sender:Reply-To: Content-Transfer-Encoding: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=o/LwOwvc32VTb8blb+blBCvCcFKCPUKuSXfqkDmdsx0=; b=xKzPT1mi/1iOHlHpUUzkp0qnY IOQ1KzW79n9j0kT60pPiLFiBf+RoQg7rjq1zwvWLmnBzdgI/SxA7Q/K6czFDiqRhKLaVks4zXwVpf iLj2xWmYrwLb0CYnRnruvIvY0AwKnbEOAC5gcl8scbevTFATvC3Zcw169+61OxZ8MCuZSiZuJowDo ypWNdMqEFXs8HfLjas1Nwaq9lJJDtE4l/BoH6CUrOVgGJGIu05c4FPqj0pNznTr86pJ/zGuKMjNLd JoZVk1DOkmuCRIlR8MHB87iL+c3sUudqNmusv6OKxYxkX8+39MbUXZLgXDtKxzPWBOsqWQLgV0nMZ h+NNjKrMg==;
Received: from [] (port=35714 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <>) id 1iU6A1-0007pk-C9; Mon, 11 Nov 2019 09:39:01 +0000
From: Bob Briscoe <>
To: "Scharf, Michael" <>, "" <>
Cc: "" <>, "" <>
References: <> <>
Message-ID: <>
Date: Mon, 11 Nov 2019 09:39:00 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------F0E8646B1CE24840474C1F0D"
Content-Language: en-GB
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-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [tcpm] [tsvwg] draft-ietf-tsvwg-ecn-l4s-id
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Nov 2019 09:39:07 -0000


On a similar question of dependency between experiments, I think you 
also expressed concern that ecn-l4s-id depends on the RACK experiment. 
However, ecn-l4s-id only refers to RACK informatively, because it only 
uses the general idea behind RACK. Just as quic-recovery (stds track) 
uses the general idea behind RACK (expt track) by referring to it 


On 04/11/2019 15:26, Bob Briscoe wrote:
> Michael,
> Thank you for pointing this out, many months ago now.
> There is no formal dependency of draft-ietf-tsvwg-ecn-l4s-id on 
> AccECN, as explained below.
> For any transport protocol to comply with ecn-l4s-id, it needs 
> sufficiently accurate feedback of the extent of CE marking on the 
> forward path. You pointing this out has made me realize that there is 
> a 'needs' that should be a 'MUST' in the spec:
> 4.2.  Prerequisite Transport Feedback
>     In general, a scalable congestion control, needs feedback of the
>     extent of CE marking on the forward path.
>     In general,for a transport protocol to provide  scalable congestion control,
>     it MUST provide  feedback of the
>     extent of CE marking on the forward path.
> However, ecn-l4s-id only specifies the requirements that any L4S 
> transport protocol would have to satisfy. It does not define a 
> transport protocol itself. So AccECN is not a normative ref. So I am 
> also altering the text a little further down, where it refers to 
> AccECN, as follows:
>    TCP:  Support for accurate ECN feedback (AccECN
>        [I-D.ietf-tcpm-accurate-ecn  <>]) by both ends is a prerequisite for
>        scalable congestion control.
>    TCP:  Support for accurate ECN feedback (such as AccECN
>        [I-D.ietf-tcpm-accurate-ecn  <>]) by both ends is a prerequisite for
>        scalable congestion control.
> Thanks again for pointing this out.
>       Dependencies between Experiments
> The case of TCP Prague provides a counter-argument:
> TCP Prague could be specified in one monolithic experimental spec.
> Or it could be broken down into experimental components, and a top 
> level experimental spec that pulls them all together.
> The latter option would create multiple dependencies of one experiment 
> on others. But IMHO such modularity is preferable to a monolithic 
> spec. Especially if some of the components might have other uses 
> outside of TCP Prague (which is exactly the case with TCP Prague, e.g. 
> AccECN, ECN++, RACK are all potentially parts of the base TCP stack, 
> and paced-chirping is potentially usable by any other congestion 
> control - these are all experimental component parts).
> As another example, BBR was written up as an experimental draft, and 
> the Linux implementation uses RACK (although not mentioned in the 
> draft) which is enabled by default in Linux.
> Such modularity is good.
> Bob
> On 24/03/2019 19:15, Scharf, Michael wrote:
>> I have just parsed through draft-ietf-tsvwg-ecn-l4s-id-06 and I run into the following sentence:
>> TCP:  Support for accurate ECN feedback (AccECN
>>        [I-D.ietf-tcpm-accurate-ecn]) by both ends is a prerequisite for
>>        scalable congestion control.  Therefore, the presence of ECT(1) in
>>        the IP headers even in one direction of a TCP connection will
>>        imply that both ends support AccECN.  However, the converse does
>>        not apply.  So even if both ends support AccECN, either of the two
>>        ends can choose not to use a scalable congestion control, whatever
>>        the other end's choice.
>> Can the authors please clarify whether there is a normative dependency of draft-ietf-tsvwg-ecn-l4s-id on draft-ietf-tcpm-accurate-ecn?
>> If so, I think the formal dependency on implementing AccECN has to be spelt out explicitly. In that case, I would be looking for a statement of the sort "MUST/SHOULD/MAY implement draft-ietf-tcpm-accurate-ecn" somewhere. If such a requirement does not exist, I think the above paragraph is confusing.
>> As individual contributor, I want to note that I disagree with mandatory dependencies between experiments. I have mentioned in the past that I believe that different experiments must be specified independently of each other and should be implementable independently of each other, specifically also to be able to fail independently of each other. It is possible that I am in the rough part of the consensus. But I haven't changed my mind.
>> Michael (as individual)
> -- 
> ________________________________________________________________
> Bob Briscoe

Bob Briscoe