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

Bob Briscoe <> Mon, 04 November 2019 15:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7B1A120A8F; Mon, 4 Nov 2019 07:27:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, 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 32TKIU1HNmCe; Mon, 4 Nov 2019 07:27:04 -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 37301120A35; Mon, 4 Nov 2019 07:27:01 -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:From:References:Cc:To: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=D3uNgk5YEqkUTWHJyhutKneYVtHQiCUxBmxSm1UOw20=; b=b42yhpL/AprCugsFDXjRbjdwy /TgCszv7AeS/bocwdyRI/IkZxzzH18B/43e/Rk85fq8EiETZ6tjESe8SI35E31FftdUCUj4OjRF+x 26hlVYehnULSg975bUZrIbPB3ygfpV3mBeNzpts5YgoWRuWDH7lVWuj2iRnQxcznu/WZui6JpXcOH oqklg44EzcD7LZxgSk8MQOTKxESXMfT0m6Q/e73OEnGUcrbR44R/tnkb9sXbKAigdKhoUj47R5+Lc UelIKFKNRl6RqoUyMp5H+AoWnTm/bI1cLBqbaqz9bvo35VxlZsCeXDAJ1Xnny0i0jry+ArJum+Lzh wEJngWIJw==;
Received: from [] (port=46678 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <>) id 1iReFt-0001M4-SP; Mon, 04 Nov 2019 15:26:59 +0000
To: "Scharf, Michael" <>, "" <>
Cc: "" <>, "" <>
References: <>
From: Bob Briscoe <>
Message-ID: <>
Date: Mon, 4 Nov 2019 15:26:57 +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="------------BA91E393F4763088F771707F"
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, 04 Nov 2019 15:27:12 -0000


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.


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