Re: [tsvwg] [tcpm] L4S status tracking

Bob Briscoe <> Mon, 11 November 2019 16:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B21C1200B2; Mon, 11 Nov 2019 08:00:32 -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 uQrBzGhHgi-Q; Mon, 11 Nov 2019 08:00:31 -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 5026F120128; Mon, 11 Nov 2019 08:00:30 -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=y4vjd7qpx2rXL/hVMacocukL3qxvnJjrkdmu0PNzqVU=; b=1DU2ECzpsyR8NM9QYopfqi2Ux osnsOGDaXDk5LFY0ydlOxOCvYKbGK1ROJUfhFSak2/Z3DHNEkzZze0MSuQ2ARUQtuWxOb8xnI2ZRZ QEDVsgneYZZldQRvQkoLx+pNA7TF0gzqWzEXSMNB3qAIK22pGBjnAz/jF74GQKiNw3nC86gIBktdk BlaZuEXquWsRMnypGuHUivtk5RCuN7rL13IcGmHOJFWgbX7EZ2D2nqkrwQPsipUt3u0eYvvtXWQjE Y7sGE9sEUtRpEZytqnStbAVup7Dc6L4b7kPIsSR/qiAozVQCAcjjoPydMuJ8sNL1tEOPL/Dnt9KGd 7zTlB0JiA==;
Received: from [] (port=56010 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <>) id 1iUC7A-0003mf-JW; Mon, 11 Nov 2019 16:00:28 +0000
To: Wesley Eddy <>, "Scharf, Michael" <>
Cc: "Rodney W. Grimes" <>, "" <>, "" <>
References: <> <> <> <> <> <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Mon, 11 Nov 2019 16:00:28 +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="------------B1E6D8F7E58476FD25D53CEE"
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: Mon, 11 Nov 2019 16:00:32 -0000


Pls see the dictionary definitions of classic (as just posted in a 
response to Sebastian), which are all about superlative and enduring 
quality. I really don't think we will find a better word.

I'm afraid what is 'normal' changes over time, which is to be avoided 
for an RFC. We deliberately chose 'Classic' because it had a sense of 
"The stuff that has stood the test of time up to publication of this RFC".

If we use 'Normal' for the Reno-friendly service, it will always imply 
that L4S is not normal, even if L4S becomes normal (which is usually the 
intent of the IETF publishing an RFC).

I have no desire to use a word that means 'inferior to L4S'. But I'm not 
happy to use a word that implies that L4S is abnormal. Sorry to make 
resolution of this one difficult (and BTW, thanks go to Michael Scharf 
for being clear on what he can compromise on).

PS. I would like to hear whether anyone who has been either neutral or 
supportive of L4S perceives anything negative in the word 'Classic'. I 
suspect they have tuned out of this thread.


On 06/11/2019 19:54, Wesley Eddy wrote:
> 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