Re: [tsvwg] [tcpm] L4S status tracking

Bob Briscoe <> Mon, 11 November 2019 15:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03C2612004A; Mon, 11 Nov 2019 07:30:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Status: No, score=-1.989 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] 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 18fZPe-Ba8bk; Mon, 11 Nov 2019 07:30:46 -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 9C23F12086A; Mon, 11 Nov 2019 07:30:45 -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=dOj27pRFe+7vSOLymT7ggPf6ICTDBI7FOazO20IVDl4=; b=pDrT4jIiR8PRiBLzhz6JlNiAp KKB1Fx9CgS2GeVuXfBnyekbTjv7GcxuB7kO/liX9AiyVqGL1ED6FZ4ykW2t+eO/Fc6U7H0W7W5ppF oae/A9n/eTjEHzdiiVTJKb/L/cFh3PvnJP2ynMOlJdTqPsnwN+/0I3gkiVrvVa7RiE02t0Pu4GNpW kxqbD6C5EaOY3zb3nDPbfyCRVc4IhOb4Uqhev9e9Yl8sIdI6CBIHh2ho7YvT/1qZmbfJhUEK0u3+E xqxewGboGfYOMvwVQ4vZICdoX1k6gnQtZpV2N9JOeEy1XW+VemNhLpTfP3cNHeL4wTHB7hx4M43ss 4n7FexK4w==;
Received: from [] (port=55936 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <>) id 1iUBeN-00081h-O1; Mon, 11 Nov 2019 15:30:44 +0000
To: "Scharf, Michael" <>, Wesley Eddy <>, "Rodney W. Grimes" <>
Cc: "" <>, "" <>
References: <> <> <> <> <> <> <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Mon, 11 Nov 2019 15:30:43 +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="------------23A40A32E98C52F9EA3808FB"
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 15:30:48 -0000


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.

> 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 <>de>; Bob Briscoe 
> <>et>; 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