Re: [tsvwg] [tcpm] L4S status tracking

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Mon, 11 November 2019 09:44 UTC

Return-Path: <ingemar.s.johansson@ericsson.com>
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 A499712081E; Mon, 11 Nov 2019 01:44:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 RttWhoLgpZQ5; Mon, 11 Nov 2019 01:44:25 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30075.outbound.protection.outlook.com [40.107.3.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7A012080B; Mon, 11 Nov 2019 01:44:25 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nzhZB8eAES4EFlOysOnbRxuwBfTSsUkM3Nvx13THxSVEyusjeQY1FMuERcvZH3sAlCZjBvrVeVDxih+Gxwrb5eDgKBxKVfL5eQU28gwERgE4nXc73JPKN0CwZfl8uXWTswAc6m6fIJV95ynVRNIs8kmFoczfNpZh6+s4lySvNyCwwfa3zqNBq95MIwO2vpPUZYBo3wadPnvscUJEOV1EPT0t9zV5pSEUeE0QM3Fs6Ef2gGd2466p8tIeKeudtJ7WBYLZVemjPpA1MUxhHLiMNNLfK9a9RaleThDkXZrd6/VTq06qHo7rgt79xTxHaUKdPJhIpYC/ADx4vrN1XYeAdQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dzzO9vflJcNzuV0GZmd37J88rvFiY2nhrzMdYfdfeSs=; b=nJ8zEcX1i5wemk9h9f0tGavS1/yqJb776r1IXZhC8hFfGYPPH42C4KyT0KNfynpdyepO1KKP19oAPvCG2VGyJNDP8w6zbLRVCFgkBxrbIV9pmhbHTrKquTicbAJ6VOpfDKxL0TCG5nqQwQUhpKv4wXyl3q/EC+4wwpcNEk94XrKqMxchwf5851ezUFxTUmbGOIt5X6+A8W5FCN7MiBfHvSWddJaxIDD7WVCINx7nN2O7BKrNT6n9pfvZrfeEUxQ4BxJr1SgkFm5CaXzXeqf3Uf3V3P6gIRIl1quja6+67ahVOQmiFBkAZ2VPIUf6eIQI1lytRAKS96zmGeQ1VcvZJg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dzzO9vflJcNzuV0GZmd37J88rvFiY2nhrzMdYfdfeSs=; b=YoLjsRgteLQ5s1DYnndBwGYRxtNX5m64CLJeudbLnZYVXnjmp+AHLHLaIlwUxN2iqRvwuSqFbXVyd6/SEld3Mpg5zphlHvd2375yTIkLxAT3vprlihYXEzS6kTiKgqeCwM2U8SlNagKDmiRRApJ9SJf8acVE/mcjb0EYFuNejaU=
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.162.29) by HE1PR07MB3481.eurprd07.prod.outlook.com (10.170.246.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.21; Mon, 11 Nov 2019 09:44:22 +0000
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::dc3f:bc2e:d106:e087%7]) with mapi id 15.20.2451.018; Mon, 11 Nov 2019 09:44:22 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>, Sebastian Moeller <moeller0@gmx.de>, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>, "4bone@gndrsh.dnsmgr.net" <4bone@gndrsh.dnsmgr.net>
CC: "tcpm@ietf.org" <tcpm@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Thread-Topic: [tsvwg] [tcpm] L4S status tracking
Thread-Index: AQHVlHDpO72yLQ1dAky9TO/zJYqoYqeBgjoggAAdCACABCA3IA==
Date: Mon, 11 Nov 2019 09:44:22 +0000
Message-ID: <HE1PR07MB442569B09E4D7120BBE427DDC2740@HE1PR07MB4425.eurprd07.prod.outlook.com>
References: <HE1PR07MB4425250E0E10522A4574210FC2790@HE1PR07MB4425.eurprd07.prod.outlook.com> <E0CE23BB-F1B4-4CB0-8415-16AEB8730B12@gmx.de> <HE1PR07MB44252042E5B7743B81B55529C27B0@HE1PR07MB4425.eurprd07.prod.outlook.com> <6EC6417807D9754DA64F3087E2E2E03E2D4EDE27@rznt8114.rznt.rzdir.fht-esslingen.de>
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4EDE27@rznt8114.rznt.rzdir.fht-esslingen.de>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com;
x-originating-ip: [192.176.1.80]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 416937a8-d7f6-4b5d-5be3-08d7668bbb59
x-ms-traffictypediagnostic: HE1PR07MB3481:|HE1PR07MB3481:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR07MB3481DCFC68D363B2D037A1BAC2740@HE1PR07MB3481.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:205;
x-forefront-prvs: 0218A015FA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(346002)(376002)(136003)(366004)(51444003)(189003)(199004)(13464003)(64756008)(86362001)(6436002)(66066001)(30864003)(99936001)(7736002)(8676002)(305945005)(81166006)(66574012)(55016002)(5660300002)(74316002)(52536014)(6246003)(81156014)(66476007)(66616009)(6306002)(9686003)(107886003)(66446008)(229853002)(66556008)(76116006)(476003)(25786009)(486006)(2501003)(33656002)(66946007)(446003)(4326008)(3846002)(102836004)(2906002)(478600001)(99286004)(26005)(186003)(966005)(19627235002)(7696005)(76176011)(53546011)(6506007)(14454004)(110136005)(256004)(54906003)(5024004)(14444005)(71200400001)(316002)(71190400001)(8936002)(11346002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3481; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1pNHTAVa7EhJ+qcIfhcczGzlvd+hieFZnBJlh2MImEgNcjqPGPxsKQ528tPPcAZCXE3lJLtLqBfKBOB3udrA1KgRRxdy/JK5KH8ZqJiiIXx4IVeBOqMpUs2aGFn0VOA1rI6UtgAe+3bvE3+h5482KKV7a4ZS7FQMv4k79CUO4wmA4YNWOEk/Grs4oMwG9C2EK5LOgm9T4z2wRbpmE6snAjLB79zMRU1aiByO4xmtsmtfc5LpnNDRx6C1fYGN8vfYEVyD6VHmgrpdCa0V2oZ4DEhCHPH7N4ttbaUzr8emF1T7h5Pd7aWL1h5mcqmlQFBadD9Gn9nAuMM/nVLZUdhgaccoRpUK0zFAh817bDDDO0pifzJWbyG9YdVhlpBmu8HcmSYoxe2aZzjXC8GUXhrcnG6+Ou6LQTeqvmFk/7hPO5xIRVjsCI8bagF/q1Qu4xwL
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0014_01D5987C.F944A5D0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 416937a8-d7f6-4b5d-5be3-08d7668bbb59
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2019 09:44:22.5027 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: heJzG3j75s1hdh5Xj9GtwJ8OZbhsVc/M80Hi6PauuQgNOaeuXTrskAZpoNcNrORlBTxmWl95SKAmmB7MrC3tjB+MFzsbymtpYbNURdc9NuQPnBP7SurBC0y19kkx1BEv
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3481
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/urc6cljJYgrMpfczSK4BB9z4XK4>
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: Mon, 11 Nov 2019 09:44:30 -0000

Hi
I believe that it is best that I leave this discussion for the time being, I guess that it will be brought up again in some organized fashion. Hopefully then it will not eat up all the meeting time :-| 

/Ingemar

> -----Original Message-----
> From: Scharf, Michael <Michael.Scharf@hs-esslingen.de>
> Sent: den 8 november 2019 19:41
> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>om>; Sebastian
> Moeller <moeller0@gmx.de>de>; Ingemar Johansson S
> <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>rg>;
> 4bone@gndrsh.dnsmgr.net
> Cc: tcpm@ietf.org; tsvwg@ietf.org
> Subject: RE: [tsvwg] [tcpm] L4S status tracking
> 
> Hi Ingemar,
> 
> A question for clarification, given that the term "classic" is used for different
> aspects in L4S:
> 
> Does your preference include the terms 'Classic' TCP and 'Classic' congestion
> control, specifically when referring to a state-of-the-art TCP stack as currently
> shipped by major operating systems?
> 
> If so, can you provide references for use of the terms 'Classic' TCP and 'Classic'
> congestion control for what is currently widely deployed in the Internet?
> 
> Thanks
> 
> Michael
> 
> 
> 
> > -----Original Message-----
> > From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
> > Sent: Friday, November 8, 2019 6:04 PM
> > To: Sebastian Moeller <moeller0@gmx.de>de>; Ingemar Johansson S
> > <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>rg>; Scharf, Michael
> > <Michael.Scharf@hs-esslingen.de>de>; 4bone@gndrsh.dnsmgr.net
> > Cc: tcpm@ietf.org; tsvwg@ietf.org; Ingemar Johansson S
> > <ingemar.s.johansson@ericsson.com>
> > Subject: RE: [tsvwg] [tcpm] L4S status tracking
> >
> > Hi Sebastian
> >
> > I clearly mentioned that I would prefer that the term "classic" is
> > kept, the earth will likely continue to spin around its axis even if
> > it is changed to something else
> > 😊. But then it should be something that the group can agree on, I
> > don't however see any consensus.
> >
> > /Ingemar
> >
> > > -----Original Message-----
> > > From: Sebastian Moeller <moeller0@gmx.de>
> > > Sent: den 6 november 2019 08:08
> > > To: Ingemar Johansson S
> > > <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>rg>;
> > > Michael.Scharf@hs- esslingen.de; 4bone@gndrsh.dnsmgr.net
> > > Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>om>;
> > tcpm@ietf.org;
> > > tsvwg@ietf.org
> > > Subject: Re: [tsvwg] [tcpm] L4S status tracking
> > >
> > > Hi Ingmar,
> > >
> > > IMHO this is a slippery slope argument. Because if minor changes to
> > > the
> > naming
> > > are "impossible" how will changed to the underlying concepts and
> > > methods
> > be
> > > acceptable to you. Because surely these other organizations already
> > committed
> > > to what is proposed to the IETF as an experiment?
> > > My gripe with the classic moniker is that this term is not outcome neutral.
> > What
> > > I mean is, that while in itself not necessarily negative, it implies
> > > that the new
> > kid
> > > on the block is the way into the future, while the classic version
> > > should head
> > into
> > > it's well-deserved retirement. And on the facts this simply is not
> > > settled or accepted in the case of L4S. IMHO the testing published
> > > by the L4S/RITE folks always tested conditions that are very
> > > favorable to L4S and completely
> > ignored
> > > to reach out to the actual user community interested in low latency
> > > under
> > load.
> > > It might well be that the L4S approach might also do well in a true
> > > stress test
> > (bi-
> > > directiomal saturation on a asymmetric path with bursty cross
> > > traffic for starters), but I would like to see numbers first. And
> > > the L4S sce back-off data posted to this list in the path seems to
> > > indicate that L4S still has open ends
> > that
> > > IMHO need addressing (independent of whether 3GPP likes this or not).
> > >
> > > Best Regards
> > >         Sebastian
> > >
> > > On November 6, 2019 7:12:39 AM GMT+01:00, Ingemar Johansson S
> > > <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org> wrote:
> > > >Hi
> > > >
> > > >I would prefer that the term "Classic" is kept.
> > > >L4S is not anymore an IETF only matter. Work is ongoing to get
> > > >support for L4S in 3GPP for 5G and the input papers there use the term
> classic.
> > > >It is of course too late for changing classic to something else,
> > > >but then it is appreciated that It is something that the group can
> > > >agree on and I don't see that we are there, therefore it is better
> > > >to stick to "classic".
> > > >And to me the term "classic" does not sound negative.
> > > >
> > > >/Ingemar
> > > >
> > > >> Message: 3
> > > >> Date: Wed, 6 Nov 2019 00:22:44 +0000
> > > >> From: Bob Briscoe <ietf@bobbriscoe.net>
> > > >> To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>de>, "Rodney W.
> > > >> 	Grimes" <4bone@gndrsh.dnsmgr.net>
> > > >> Cc: Wesley Eddy <wes@mti-systems.com>om>, "tsvwg@ietf.org"
> > > >> 	<tsvwg@ietf.org>rg>, "tcpm@ietf.org" <tcpm@ietf.org>
> > > >> Subject: Re: [tcpm] [tsvwg] L4S status tracking
> > > >> Message-ID: <7f1aa4ae-05d6-b07c-50b0-
> ab899c5c30b7@bobbriscoe.net>
> > > >> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
> > > >>
> > > >> Michael, Rod,
> > > >>
> > > >> Altho non-L4S is a reasonable idea, I think it has more of a
> > > >> negative
> > > >connotation
> > > >> than classic. For instance, consider describing Android phones as
> > > >non-iPhones.
> > > >>
> > > >> Also, in the ecn-l4s-id draft, we introduce the possibility that
> > > >> some
> > > >operators
> > > >> might classify non-L4S traffic (DNS, VoIP, EF, NQB, etc) into the
> > > >same
> > > >queue as
> > > >> L4S traffic (and we say that in this case the queue would be
> > > >> called
> > > >the
> > > >Low
> > > >> Latency queue). This shows that the term non-L4S is not a good
> > > >> choice
> > > >for
> > > >a
> > > >> name, because the words it is made from already give it a meaning
> > > >> of
> > > >its
> > > >own
> > > >> that conflicts with the definition you want it to have in certain
> > > >contexts.
> > > >>
> > > >> For example, if you did define the name "non-iPhone" to mean
> > > >> phones
> > > >such
> > > >as
> > > >> Android, Windows, etc, then you would expect the phrase
> > > >> "non-iPhone
> > > >knock-
> > > >> off products" to mean "fake Android and Windows phones". However
> > > >> the constituent elements "non" and "iPhone" already have a
> > > >> meaning of
> > > >their
> > > >own,
> > > >> so in the context of this phrase, it means "fake iPhones", which
> > > >> is
> > > >the
> > > >opposite
> > > >> of what you wanted.
> > > >>
> > > >> The term Classic for the non-L4S service, its queue, its traffic,
> > > >> its
> > > >congestion
> > > >> control, etc. is defined in the terminology section of the
> > > >> drafts, so
> > > >I
> > > >think it's
> > > >> best to live with this - it's not a significant problem. Indeed,
> > > >> it
> > > >has
> > > >become widely
> > > >> used and widely understood since 2015, and changing it to non-L4S
> > > >> now
> > > >would
> > > >> cause unnecessary confusion.
> > > >>
> > > >>
> > > >>
> > > >> Bob
> > > >>
> > > >>
> > > >>
> > > >> On 04/11/2019 19:21, Scharf, Michael wrote:
> > > >> >
> > > >> > I agree. ?non-L4S? may be even better.
> > > >> >
> > > >> > Michael
> > > >> >
> > > >> > *Von: *Rodney W. Grimes <mailto:4bone@gndrsh.dnsmgr.net>
> > > >> > *Gesendet: *Montag, 4. November 2019 20:17
> > > >> > *An: *Scharf, Michael <mailto:Michael.Scharf@hs-esslingen.de>
> > > >> > *Cc: *Bob Briscoe <mailto:ietf@bobbriscoe.net>; Wesley Eddy
> > > >> > <mailto:wes@mti-systems.com>; tsvwg@ietf.org
> > > ><mailto:tsvwg@ietf.org>;
> > > >> > tcpm@ietf.org <mailto:tcpm@ietf.org>
> > > >> > *Betreff: *Re: [tcpm] [tsvwg] L4S status tracking
> > > >> >
> > > >> > > You can e.g. use ?non-L4S-enabled TCP?.
> > > >> > >
> > > >> > > Terminology does matter to me given that I strongly disagree
> > > >> > > to
> > > >any
> > > >> > use of ?marketing language? when it comes to TCP.
> > > >> >
> > > >> > My concern here of use of terms like, legacy, classic, new, old
> > > >> > is that they are pretty much all of the relative from and thus
> > > >ambiguous
> > > >> > over time.
> > > >> >
> > > >> > newReno is new only relative to Reno, that is fairly clear, but
> > > >> > if
> > > >I
> > > >> > said newTCP or oldTCP with what frame should the reference be
> > > >> > evaluated.
> > > >> >
> > > >> > I believe in the case of L4S the time invariant term would be,
> > > >> > as Michael suggests above, "non-L4S".?? Note that enabled for
> > > >> > me is a noise word in this context, and TCP may or may not be
> > > >> > needed
> > > >depending
> > > >> > on context, but for literal replacement of Legacy or Classic
> > > >"non-L4S"
> > > >> > is invariant over time.
> > > >> >
> > > >> > Rod
> > > >> >
> > > >> > > Michael
> > > >> > >
> > > >> > >
> > > >> > > Von: Bob Briscoe<mailto:ietf@bobbriscoe.net>
> > > >> > > Gesendet: Montag, 4. November 2019 19:09
> > > >> > > An: Scharf, Michael<mailto:Michael.Scharf@hs-esslingen.de>;
> > > >Wesley
> > > >> > Eddy<mailto:wes@mti-systems.com>;
> > > >> > tsvwg@ietf.org<mailto:tsvwg@ietf.org>
> > > >> > > Cc: tcpm@ietf.org<mailto:tcpm@ietf.org>
> > > >> > > Betreff: Re: [tcpm] [tsvwg] L4S status tracking
> > > >> > >
> > > >> > > Michael,
> > > >> > >
> > > >> > > Previously, I have been told not to use the term standard for
> > > >RFCs
> > > >> > that are not standards. RFC5681 is 'only' a draft standard.
> > > >> > This is why, in the IETF at least, I avoid using the term
> > > >> > "standard TCP congestion control". I generally call it Reno
> > > >> > when referring to the congestion control.
> > > >> > >
> > > >> > > I have never, to my knowledge, used the term classic TCP, or
> > > >classic
> > > >> > TCP congestion control.
> > > >> > >
> > > >> > > And I rarely use the term legacy, and if I do I'm happy to
> > > >> > > have
> > > >> > alternatives suggested.
> > > >> > >
> > > >> > > I've checked the L4S drafts, and there is one phrase that I
> > > >> > > shall
> > > >> > leave in ecn-l4s-id: "the traditional TCP Reno additive
> > > >> > increase", because this is correctly used to mean the
> > > >> > traditional increase (in numerous AIMD CCs), not traditional
> > > >> > TCP. There was one other occurrence of "traditional TCP
> > > >> > senders" in a whole para in an
> > > >appendix
> > > >> > that has just been deleted anyway. And in aqm-dualq-coupled
> > > >> > there
> > > >was
> > > >> > one "legacy TCP flows" (changed to "Classic traffic" now in my
> > > >local
> > > >> > copy, using the defined term in all the L4S drafts).
> > > >> > >
> > > >> > > l4s-arch is getting a complete make-over for terminology, so
> > > >> > > I
> > > >will
> > > >> > check that next.
> > > >> > >
> > > >> > > inline...
> > > >> > >
> > > >> > >
> > > >> > > On 23/08/2019 15:01, Scharf, Michael wrote:
> > > >> > >
> > > >> > > Hi Wes,
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > I?d like to add a smaller item that is mostly editorial and
> > > >> > > can
> > > >> > hopefully be sorted just out by re-wording, albeit it may
> > > >> > require a careful analysis of all documents.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > As already noted in
> > > >> > https://mailarchive.ietf.org/arch/msg/tsvwg/zZkYZKF-
> > > >> hDvWO3I5MudwpNkKyH
> > > >> >
> > > >Y<https://mailarchive..ietf.org/arch/msg/tsvwg/zZkYZKF-
> > hDvWO3I5MudwpNk
> > > >> > KyHY> , I object to the terms ?traditional TCP? and also
> > > >> > KyHY> ?classic
> > > >TCP?
> > > >> > or ?legacy? TCP when referring to a TCP implementation
> > > >> > according to IETF standards-track RFCs.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > To me as a non-native native speaker, all these terms have a
> > > >> > negative connotation. I also think this language is typical to
> > > >> > marketing material.
> > > >> > >
> > > >> > > You're entitled to your opinion but, as a native speaker, I
> > > >> > > don't
> > > >> > think 'classic' or 'traditional' are particularly pejorative,
> > > >> > tho
> > > >they
> > > >> > can be when used in a context that intends them to be. They
> > > >> > also
> > > >mean
> > > >> > "stood the test of time". I find 'legacy' has a connotation of
> > > >> > marketing-speak, but it's not that bad.
> > > >> > >
> > > >> > > This is an enduring problem when trying to improve on the
> > > >> > > good
> > > >work
> > > >> > that other people have done before you (which is the context of
> > > >> > everything we are doing). We need a word that distinguishes the
> > > >> > old from the new, but we don't want to completely trash the
> > > >> > thing that
> > > >has
> > > >> > already been successful, but had its day.
> > > >> > >
> > > >> > > Nonetheless, it is also important not to be too precious
> > > >> > > about
> > > >past
> > > >> > work. We all recognize that Reno TCP is unscalable and has
> > > >problems.
> > > >> > IMO, it is OK to describe technologies that have had their time
> > > >with
> > > >> > negative connotations. Indeed, you have been an author (with
> > > >> > me) of
> > > >an
> > > >> > RFC on open issues in congestion control.
> > > >> > >
> > > >> > > I notice you haven't suggested an alternative term for "the
> > > >thing(s)
> > > >> > we are trying to improve on". Not surprising, because it's
> > > >difficult.
> > > >> > >
> > > >> > > When we (the L4S developers) were first looking for a term
> > > >> > > for
> > > >the
> > > >> > non-L4S queue and the non-L4S service, we didn't want to use
> > > >'legacy'
> > > >> > for the above reasons, but we did want to imply pre-existing,
> > > >> > so we decided on 'classic', which we all felt had a generally
> > > >> > neutral connotation, but said what we meant.
> > > >> > >
> > > >> > > Finally, I do not want this issue to take up any time that
> > > >> > > would
> > > >> > detract from technical issues.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > Bob
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > My prefered term when referring to TCP according to
> > > >standards-track
> > > >> > specification is ?standard TCP?. I would also be fine with
> > > >> > other
> > > >terms
> > > >> > as long as they are neutral and make clear that experiments do
> > > >> > not replace, deprecate, or outperform standards.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > Similarly, I think that term such as ?classic? is not
> > > >> > > appropriate
> > > >> > for the TCP standard congestion control (?Reno?). As of today,
> > > >> > this
> > > >is
> > > >> > the TCP congestion control algorithm on standards track that
> > > >> > has
> > > >IETF
> > > >> > consensus. The term in the TCPM charter is ?TCP standard
> > > >> > congestion control?. I also think that terms such as
> > > >> > ?Reno-compatible? or the like would be neutral.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > Note that I do not object to the terms ?classic ECN?, ?legacy
> > > >ECN?,
> > > >> > ?legacy AQM? or the like, i.e., if the context is ECN and not
> > > >> > specifically TCP or the TCP congestion control. I believe it is
> > > >> > up
> > > >to
> > > >> > the TSVWG do decide if this term shall be used for compliance
> > > >> > to
> > > >RFC
> > > >> > 3168. I have no strong opinion on that. As far as I can see,
> > > >> > most
> > > >use
> > > >> > of the term ?classic? is in this context and I don?t ask for
> > > >changes
> > > >> > in those cases.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > Some use of the term ?Classic Service? may also require
> > > >> > > careful
> > > >> > review to clearly separate it from TCP Standard behavior.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > Note that some use of the term ?Classic TCP? would probably
> > > >> > > also
> > > >> > apply to ?Classic QUIC? once the QUIC standard is finished. To
> > > >> > me
> > > >as a
> > > >> > non-native speaker, it would be really strange to use the term
> > > >> > ?classic? in the context of a brand-new transport protocol.
> > > >> > IMHO in that case the term ?classic? would be even more confusing.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > I also add the TCPM list in CC to ensure consistency.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > Thanks
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > Michael (with no hat)
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > Von: Wesley Eddy<mailto:wes@mti-systems.com>
> > > >> > > Gesendet: Sonntag, 11. August 2019 07:08
> > > >> > > An: tsvwg@ietf.org<mailto:tsvwg@ietf.org>
> > > >> > > Betreff: [tsvwg] L4S status tracking
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > I created tickets in the TSVWG "trac" tool in order to help
> > > >> > > keep track of the individual things that look like they
> > > >> > > should be addressed in progressing L4S document set:
> > > >> > >
> > > >> > >
> > > >https://trac.ietf.org/trac/tsvwg/report/1?sort=ticket&asc=1&page=1
> > > >> > >
> > > >> > > I'll try to update these based on the ongoing discussions,
> > > >updates,
> > > >> > > etc., but it will make it very easy if you happen to mention
> > > >> > > the ticket numbers or some key words in threads and messages,
> > > >> > > when
> > > >> significant.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > _______________________________________________
> > > >> > > tcpm mailing list
> > > >> > > tcpm@ietf.org<mailto:tcpm@ietf.org>
> > > >> > > https://www.ietf.org/mailman/listinfo/tcpm
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > --
> > > >> > >
> > > >>
> > >
> >
> ________________________________________________________________
> > > >> > > Bob Briscoe
> > > >> > >
> > > >https://protect2.fireeye.com/v1/url?k=9e3cf770-c2e8fb81-9e3cb7eb-86
> > > >4
> > > >> > > 685b2085c-4ba6a1960c4f3e7a&q=1&e=bf49c0f0-380b-42d4-93a2-
> > > >> 9ebedff802e
> > > >> > > 0&u=http%3A%2F%2Fbobbriscoe.net%2F
> > > >> >
> > > >> > > _______________________________________________
> > > >> > > tcpm mailing list
> > > >> > > tcpm@ietf.org
> > > >> > > https://www.ietf.org/mailman/listinfo/tcpm
> > > >> >
> > > >> > --
> > > >> > Rod Grimes rgrimes@freebsd.org
> > > >>
> > > >> --
> > > >>
> > >
> >
> ________________________________________________________________
> > > >> Bob Briscoe
> > > >https://protect2.fireeye.com/v1/url?k=861241a8-
> > > >> dac64d59-86120133-864685b2085c-
> > 16120a27ab4a751a&q=1&e=bf49c0f0-
> > > >> 380b-42d4-93a2-9ebedff802e0&u=http%3A%2F%2Fbobbriscoe.net%2F
> > > >>
> > > >> -------------- next part -------------- An HTML attachment was
> > > >> scrubbed...
> > > >> URL:
> > > >>
> > > ><https://mailarchive.ietf.org/arch/browse/tcpm/attachments/20191106
> > > >/de7
> > > >97
> > > >> fd1/attachment.html>
> > > >>
> > > >> ------------------------------
> > > >>
> > > >> Subject: Digest Footer
> > > >>
> > > >> _______________________________________________
> > > >> tcpm mailing list
> > > >> tcpm@ietf.org
> > > >> https://www.ietf.org/mailman/listinfo/tcpm
> > > >>
> > > >>
> > > >> ------------------------------
> > > >>
> > > >> End of tcpm Digest, Vol 187, Issue 15
> > > >> *************************************
> > >
> > > --
> > > Sent from my Android device with K-9 Mail. Please excuse my brevity.