Re: [tsvwg] [tcpm] L4S status tracking

"Scharf, Michael" <> Wed, 13 November 2019 11:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D564312003F; Wed, 13 Nov 2019 03:12:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.986
X-Spam-Status: No, score=-1.986 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_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gwfd5gWGwWoG; Wed, 13 Nov 2019 03:12:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EEE721200CD; Wed, 13 Nov 2019 03:12:27 -0800 (PST)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 3E9B325A1A; Wed, 13 Nov 2019 12:12:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1573643546; bh=Zh6MkLAht88I6HUx3eGG3BhtUfS6edvTLl2qeAyrQME=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=htCjtOv3R8B7FRbC4TIwh5wJcb3B3VUkc2X95EK7CsjYJOr45BFcS5BfKzMI2Wuhd 6GJzKPxUl/MzgPf8TFZ/+gjvV4ISdIBmbkgeoDrCSUuydqdoptaU2kN1vzpFjw88U5 xB1VZAvV37yUETYehT/jvV1fGJoApvBAvbWBQexQ=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D-TvD4CEqMEk; Wed, 13 Nov 2019 12:12:22 +0100 (CET)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Wed, 13 Nov 2019 12:12:22 +0100 (CET)
Received: from ([]) by ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Wed, 13 Nov 2019 12:12:22 +0100
From: "Scharf, Michael" <>
To: Bob Briscoe <>, Wesley Eddy <>, "Rodney W. Grimes" <>
CC: "" <>, "" <>
Thread-Topic: [tcpm] [tsvwg] L4S status tracking
Date: Wed, 13 Nov 2019 11:12:21 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: de-DE
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D500D21rznt8114rzntrzd_"
MIME-Version: 1.0
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 11:12:32 -0000

I was referring to this statement from David Black:

For congestion control in particular, I've found myself referring to 1/p and 1/sqrt(p) congestion response behaviors for technical clarity/precision in discussion, but those terms don't exactly roll off the tip of the tongue ... and assume that the reader is familiar enough with TCP throughput equations to know what the variable p stands for.

Instead of using equations, one could also define two acronyms to make it more handy. I am pretty open to different variants.

To me, a key advantage of this approach is that it would be a technically neutral (mathematical) description of behavior that should not be controversial. At least to me, this would work well.


From: Bob Briscoe <>
Sent: Wednesday, November 13, 2019 11:00 AM
To: Scharf, Michael <>de>; Wesley Eddy <>om>; Rodney W. Grimes <>
Subject: Re: [tcpm] [tsvwg] L4S status tracking


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).


From: Bob Briscoe <><>
Sent: Monday, November 11, 2019 4:31 PM
To: Scharf, Michael <><>; Wesley Eddy <><>; Rodney W. Grimes <><>
Subject: Re: [tcpm] [tsvwg] L4S status tracking

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.


From: Wesley Eddy <><>
Sent: Wednesday, November 6, 2019 8:54 PM
To: Scharf, Michael <><>; Bob Briscoe <><>; Rodney W. Grimes <><>
Subject: Re: [tcpm] [tsvwg] L4S status tracking

On 11/6/2019 1:57 PM, Scharf, Michael wrote:

>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