Re: [tcpm] [tsvwg] L4S status tracking

Sebastian Moeller <moeller0@gmx.de> Tue, 05 November 2019 09:20 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B3312085F; Tue, 5 Nov 2019 01:20:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Level:
X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 Cutel_8oh-1s; Tue, 5 Nov 2019 01:20:44 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ABF712085E; Tue, 5 Nov 2019 01:20:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1572945619; bh=zbkdDpqYsn5P55dD/n0UrZx+IRbzso67IUhx7cSHj9s=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=J2VPpGlhIH+v2BRuqiz4CtA4aT96Bj+4ynKPnvuCglDqs2mmDWqlzI4xBBi0O/ui4 0BXGV0CL2xuMQQfypbqxitwHamRguS++/7rIbxoNj8y8vlUrvmSolhfjb/jS5eHkV/ R+KOMardA3sd+73Jbb7PgZIsgNkHnM/dOEBKnvoo=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.33] ([134.76.241.253]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MuUjC-1hbsZ23KR0-00rXWK; Tue, 05 Nov 2019 10:14:38 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de>
Date: Tue, 05 Nov 2019 10:14:37 +0100
Cc: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tcpm@ietf.org" <tcpm@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <00F3EB28-F841-4FA2-8E95-89866404402B@gmx.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2D4DE531@rznt8114.rznt.rzdir.fht-esslingen.de> <201911041917.xA4JH2nX002064@gndrsh.dnsmgr.net> <6EC6417807D9754DA64F3087E2E2E03E2D4DE88E@rznt8114.rznt.rzdir.fht-esslingen.de>
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:mLRGUBTcOipjN78RkEQJ7Uh0XYr1DGY5HYu2nurYR0cpcX3NcGa GcF9cTs7BUgWoKedjk6Xeb3GvKn92CFoaNSFhOWxWsDdI5n8qyJUh3KQJMwGodgaZlmtG1R 5vaWIHcivSxPyn+UlVUWJP6h6YEs3BbUTQ6S6nX3VMm6hq/FcQ1nkhQq8o9MjAX/gnH+dRS ZSLMVqgH70AMsukN8Smdg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:5GF0nGoOjlE=:6Xmrzz+awR7Aevep5usGMe TSmBs7jP2rQZNNUU77HMwMD9W5p2wA8BmCtwGugO8LCtwKlchPe03TXkmHkkb6WStf22jK51h SBJ+x3nXntwMziGLrPZN/4nh1Co1DtuHXffV6RSwys1/peHktsBDJo9/MQWu3WOieEOt8xaF0 XC7Y/3Bk7omPWNxXxPIEbX4RjW8WcsS64ZIpxNAeL/Qhihvc+BzVJHlaWNplIZ8txLYamDygx BaIEf+vTmTKVin30SgNTZ2OXCZWct4Jn3CBi9jEkPdbae2bxO4YTtW1bxMQ4q+JwdFOGZ/aK6 UYErDc4TepDfZztR5SHJMhXkIBvTfLJ4sLFhXbLqUygc3SA+lroYiyiqoB9c8am5f9aO7071Y AGDSvPYl3jBocHjLCEHGVkReyNaYqZeshHkxzNeK8JxjKbRXweywLA8wPyRsxS+01ZMC4TStH ZNmupm8xNDTEqyHzOcd6TclmkLpyohYYjCM05mmmC9Mjx2lzTPFCzKxMuAWqEOx/Ny79WjyXi nB7QT/P0I1StV8a+GXThhyzqV+dvvPXcPnzKaZGSKmPFGYGQVrzs+P0OCaFx98kRq/DGmE1zU LGSE+4XXcgdZqBeDgGne0wZOLDsA/JxG7y5rM823x7kmNyXH2QA+K1TtBR3qwq+T338zfcX5t 3vFNX3WsOmklwSUVAQDNSUMLGaOeqmfrj+31/SPyMilILsw+mXRVIcuuOpTSRIqbQaOON7pJt gxjWmJkS0b2of9hGddfZxFj4QtcBR3UjjPUzP2rGySVOC2v5IYH0LFif7RE4s7TEcPYiGeu/H NC+bgV8VAwF3Ldxv1BDNRwSn8+XguJiwTZze3SjOfTi4If9SBKyLtgKToJv6KCcCSPiQNIuTg +0y/u8vLltJOrUGvlAPGCEMJhJZJjOXtL1/tT9WrNYk5WEulea+7emcdJOtr3vtu/Y0ohgaRw atfrhV+Z+ptP3zAQyWekJdx95aCe8eXlhTr087rjTOSNFirebG/ZcfVMyFkNOk5cstuEZ5D/y M579DJ4KlRc1peQxBdslP+kYeb/PqyUQn3XI8VoksElIdX8sUfComLAJVU3w3zkOKF5xQC67J bZdBrrqhFpRK8dYmNOskniDxOPkLmpf/whnTeST+7erABIgtuz/yWcHJsG/D9erb/NOifqcsW qqtSrTkSZmMlP7l0qQLpHnD92ZaJG77LXKaDuXnFwe/EwMAswJ9EDDhRzEHiVQoIRdnGOF9RL LanRjkhTJcT2oK1lVypKqvCaUB1dhLC/1LeL/inCwQVlu4yS3mgdhHXoQqpo=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/BaEw6Ffr7wqHORKx-lbMpmnVQvM>
Subject: Re: [tcpm] [tsvwg] L4S status tracking
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Nov 2019 09:20:48 -0000

Hi Michael,


> On Nov 4, 2019, at 20:21, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:
> 
> I agree. „non-L4S“ may be even better.

	[SM] except that L4S, which expands to "Low Latency, Low Loss, Scalable Throughput" (so it arguably should be LLLLST or L4ST)
arguably that is also "marketing language", no?

Sebastian


>  
> Michael
>  
>  
> Von: Rodney W. Grimes
> Gesendet: Montag, 4. November 2019 20:17
> An: Scharf, Michael
> Cc: Bob Briscoe; Wesley Eddy; tsvwg@ietf.org; 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-hDvWO3I5MudwpNkKyHY<https://mailarchive..ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY> , I object to the terms ?traditional TCP? and also ?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                               http://bobbriscoe.net/
> 
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
> 
> -- 
> Rod Grimes                                                 rgrimes@freebsd.org