Re: [tsvwg] [tcpm] L4S status tracking

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Fri, 08 November 2019 21:03 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DDB12084D; Fri, 8 Nov 2019 13:03:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level:
X-Spam-Status: No, score=-1.987 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6A772JVN3iR; Fri, 8 Nov 2019 13:03:21 -0800 (PST)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF03B120871; Fri, 8 Nov 2019 13:03:20 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id D6DF225A12; Fri, 8 Nov 2019 22:03:18 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1573246998; bh=WwzBEWQlrAUstL2sT4DzzbVJH1lxFiSsqpUtBBzaiAQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ECiY5qEY2oyxUeDg6xXv8o5ncLwJjt8mhnuCut8XTOXozXAJVk0QlLK1Pa+qOCDeS LaTObLpVnEvX9U4vtoZkaP1WPFQwKiK2oO90D7EyVRKoQ5EZ+adclPxmzNUb8lfPFg w7gIbQ703jbZACssydV3Hq1HGUaPVfgqThoRuhbo=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RUmVrnXf0Ha; Fri, 8 Nov 2019 22:03:17 +0100 (CET)
Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Fri, 8 Nov 2019 22:03:17 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Fri, 8 Nov 2019 22:03:17 +0100
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: "Black, David" <David.Black@dell.com>
CC: "tcpm@ietf.org" <tcpm@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] [tcpm] L4S status tracking
Thread-Index: AQHVlnXvmwgefRBDRUazKhBQq/SzcKeBv4mg
Date: Fri, 8 Nov 2019 21:03:16 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4EE402@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de> <7f1aa4ae-05d6-b07c-50b0-ab899c5c30b7@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4E4829@rznt8114.rznt.rzdir.fht-esslingen.de> <bc12fc37-2c7a-d6c4-8372-3b341682c4bf@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D4E64F3@rznt8114.rznt.rzdir.fht-esslingen.de> <f4b5bc68-5735-eccd-9abc-0e6a8d8e4ab2@mti-systems.com> <6EC6417807D9754DA64F3087E2E2E03E2D4E732D@rznt8114.rznt.rzdir.fht-esslingen.de> <MN2PR19MB4045216D5E55A08FA8E04859837B0@MN2PR19MB4045.namprd19.prod.outlook.com>
In-Reply-To: <MN2PR19MB4045216D5E55A08FA8E04859837B0@MN2PR19MB4045.namprd19.prod.outlook.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.63.11]
Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D4EE402rznt8114rzntrzd_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/TgIoEqQwve_0dD27EuoZbAlEBps>
Subject: Re: [tsvwg] [tcpm] L4S status tracking
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Nov 2019 21:03:24 -0000

Yep, that is exactly what I would suggest.

Michael

From: Black, David <David.Black@dell.com>
Sent: Friday, November 8, 2019 9:49 PM
To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>
Cc: tcpm@ietf.org; tsvwg@ietf.org
Subject: RE: [tsvwg] [tcpm] L4S status tracking

Hopefully not adding confusion, I'm in favor of Michael's suggestion (below), as I understand it:
                - L4S has a "Classic" service
                - Protocols and traffic that use the L4S "Classic" service are identified/named/described with terms other than "Classic".

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.

Thanks, --David

From: tsvwg <tsvwg-bounces@ietf.org<mailto:tsvwg-bounces@ietf.org>> On Behalf Of Scharf, Michael
Sent: Thursday, November 7, 2019 3:11 AM
To: Wesley Eddy; Bob Briscoe; Rodney W. Grimes
Cc: tcpm@ietf.org<mailto:tcpm@ietf.org>; tsvwg@ietf.org<mailto:tsvwg@ietf.org>
Subject: Re: [tsvwg] [tcpm] L4S status tracking


[EXTERNAL EMAIL]
... 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.

Whether such small rewording address fully the concerns from others may be a different question.

Michael



From: Wesley Eddy <wes@mti-systems.com<mailto:wes@mti-systems.com>>
Sent: Wednesday, November 6, 2019 8:54 PM
To: Scharf, Michael <Michael.Scharf@hs-esslingen.de<mailto:Michael.Scharf@hs-esslingen.de>>; Bob Briscoe <ietf@bobbriscoe.net<mailto:ietf@bobbriscoe.net>>; Rodney W. Grimes <4bone@gndrsh.dnsmgr.net<mailto:4bone@gndrsh.dnsmgr.net>>
Cc: tsvwg@ietf.org<mailto:tsvwg@ietf.org>; tcpm@ietf.org<mailto:tcpm@ietf.org>
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.)