Re: [tsvwg] [tcpm] L4S status tracking

Bob Briscoe <> Wed, 13 November 2019 10:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 912EB120088; Wed, 13 Nov 2019 02:00:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Status: No, score=-1.988 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, T_KAM_HTML_FONT_INVALID=0.01, 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 UnnztjaqXzjW; Wed, 13 Nov 2019 02:00:07 -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 E4484120052; Wed, 13 Nov 2019 02:00:06 -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=Ooa88qMG9f4LdQpLXBS+2LxjB4VHeqfyHHfDXmR5WXI=; b=0QaNqAR2nIsau0H0cqFGsHj8w tdF4RnOu4esms8pibn1iXgrobMOvw1xWa6+HvK1NLiVXhG6Qdl1lUyyaNPSLb6LSTPh5DdTEdnh8s HJx0+C94LJpI7G1pMEmCmHT9BCfMVjWRb9h7MRBn/GcN3gRxi1f7Hpv8E+35N1zLRZBUcJtsBGhMm Cl5fYRpORABuLCCv0hXmL2nGhBA8qSiCiVrxMrF6947aQT2IgaWG/EUIOvpDHKETN6b5aF47NJrnA 8Lb8IrOWY+tu7gMjBqUoDFAaurDBTFL/aM57EumYio1tT9uDz4g/xWob/SJFMxs9vDHw9k4iVHjW2 mV/dpMJHg==;
Received: from [] (port=49852 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <>) id 1iUpRV-0000yA-1n; Wed, 13 Nov 2019 10:00:05 +0000
To: "Scharf, Michael" <>, Wesley Eddy <>, "Rodney W. Grimes" <>
Cc: "" <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Wed, 13 Nov 2019 10:00:04 +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="------------2C3E5127504B1214A86383DC"
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: [tsvwg] [tcpm] L4S status tracking
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: Wed, 13 Nov 2019 10:00:10 -0000


I see the problem. Nearly all the occurrences of 'Classic TCP' are in 
the appendix that was written v early on, when the focus was only TCP. 
That text was not written by me, and I haven't got round to editing it 
for consistency. However, there are 4 occurrences of "'Classic' TCP" in 
the abstract and intro, which I will also fix.

Can you say which "David's proposal" you mean please?


On 11/11/2019 23:10, Scharf, Michael wrote:
> OK, so we seem to make some progress at least regarding the term 
> ‚classic‘ TCP. As mentioned before, I personally would find the term 
> ‘Classic’ QUIC very confusing and you cannot avoid that if you talk 
> about ‘Classic’ TCP, IMHO. So, it seems better to avoid that 
> terminology for all transport protocols. For the record, in 
> draft-ietf-tsvwg-ecn-l4s-id-08 the combination of the terms ‘classic’ 
> and ‘TCP’ back-to-back is used 11 times as far as I can see.
> Regarding congestion control, I’d like to emphasize that David’s 
> proposal would also work well for me, i.e., characterizing the 
> congestion control by functional properties. This avoids all issues 
> regarding whether something will supersede something else (including 
> the issue that EXP is just an experiment that won’t update or replace 
> any PS document).
> Michael
> *From:*Bob Briscoe <>
> *Sent:* Monday, November 11, 2019 4:31 PM
> *To:* Scharf, Michael <>de>; Wesley Eddy 
> <>om>; Rodney W. Grimes <>
> *Cc:*;
> *Subject:* Re: [tcpm] [tsvwg] L4S status tracking
> Michael,
> On 07/11/2019 08:11, Scharf, Michael wrote:
>     … and just to show that _/my/_ concern would be trivial to address
>     by small editorial changes:
>     For the abstract of draft-ietf-tsvwg-ecn-l4s-id, the wording “It
>     gives an incremental migration path so that normal TCP traffic
>     classified in the ‘Classic’ service of L4S will be no worse off”
>     would already work for me.  It just takes a small editorial change
>     to make me happy. This can’t be so hard.
>     Personally, I wonder if “classic” is indeed the best name for a
>     service class (and, e.g., “normal” sounds better to me), but in
>     the context of a service class, “classic” could actually work for
>     me, if TSVWG really wants that name with strong consensus. I don’t
>     care how about names for DiffSe^D^D^D^D^D^D traffic classifiers,
>     traffic policers/shapers, AQM schemes, or whatever else is done in
>     the fast path of a router to implement low latency service.
>     I only object to specific terminology such as ‘Classic’ TCP or
>     ‘Classic’ congestion control because I don’t think that ‘classic’
>     is a proper characterization for TCPM standards or TCP/IP stack
>     behavior not aligned with whatever L4S believes the bright future
>     shall be.
> I thought I had already agreed to remove 'TCP' from all instances of 
> 'Classic TCP traffic' etc, and that I hadn't intended to include 'TCP' 
> in the first place. Because it's the congestion controls that are 
> relevant in L4S drafts, not the protocols.
> Bob
>     Whether such small rewording address fully the concerns from
>     others may be a different question.
>     Michael
>     *From:*Wesley Eddy <> <>
>     *Sent:* Wednesday, November 6, 2019 8:54 PM
>     *To:* Scharf, Michael <>
>     <>; Bob Briscoe
>     <> <>; Rodney W.
>     Grimes <> <>
>     *Cc:* <>;
>     <>
>     *Subject:* Re: [tcpm] [tsvwg] L4S status tracking
>     On 11/6/2019 1:57 PM, Scharf, Michael wrote:
>         Bob,
>         From draft-ietf-tsvwg-ecn-l4s-id-08: “It gives an incremental
>         migration path so that existing 'Classic' TCP traffic will be
>         no worse off”
>         You are proposing an experiment. Not more than that. I will be
>         fine with the term “Classic” for TCP and TCPM-specified
>         congestion control when more than 50% of Internet traffic uses
>         that new technology.
>         Until this happens, I insist that the word “Classic” must be
>         removed in all context of TCP and congestion control (as far
>         as it is owned by TCPM), including the reference above. BTW,
>         “normal” as suggested would also work for me. So, you have
>         plenty of options for other terms.
>     If Dave+Michael's suggestion of replacing "classic" with "normal"
>     is agreable to others, this seems like a good way forward to me. 
>     It should be easy enough to explain in other SDOs that classic and
>     normal mean the same thing, if this is a real issue.
>     (FWIW, I've never had a problem myself with "classic", nor read
>     any negative connotations to it.  However, for the sake of working
>     group progress, I think we just need to pick something that seems
>     the least terrible and agree to move on.)
> -- 
> ________________________________________________________________
> Bob Briscoe

Bob Briscoe