Re: [tcpm] [tsvwg] L4S status tracking
Dave Taht <dave@taht.net> Wed, 06 November 2019 15:49 UTC
Return-Path: <dave@taht.net>
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 3C6C212004C; Wed, 6 Nov 2019 07:49:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.435
X-Spam-Level: *
X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 32OWeAIe_uu4; Wed, 6 Nov 2019 07:49:45 -0800 (PST)
Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E68120072; Wed, 6 Nov 2019 07:49:43 -0800 (PST)
Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id A6C3721B1C; Wed, 6 Nov 2019 15:49:38 +0000 (UTC)
From: Dave Taht <dave@taht.net>
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
Cc: Bob Briscoe <ietf@bobbriscoe.net>, "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tcpm@ietf.org" <tcpm@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
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>
Date: Wed, 06 Nov 2019 07:49:25 -0800
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D4E4829@rznt8114.rznt.rzdir.fht-esslingen.de> (Michael Scharf's message of "Wed, 6 Nov 2019 07:23:24 +0000")
Message-ID: <87lfstgg3e.fsf@taht.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/-8aUFo4ysXEsQ3mpxeqL_5yxZjA>
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: Wed, 06 Nov 2019 15:49:49 -0000
"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> writes: > Bob, > > I am not convinced by any of your statements. Me neither. Outside of this echo chamber no-one at any conference I've been to of late has heard of L4S. I am recently back from the nanog+arin meetings in austin. (I'm not there on aqm related business, I'm trying to do something new in the NRO election [ https://www.youtube.com/playlist?list=PL726kQ53RX6imaiNabIZZKNZUmrBrT6pc ] ) ... but, being "mr bufferbloat", my self-selecting audience does come up to me and chat. I've enjoyed learning all the places where cake is penetrating in particular. I would think that the nanog folk in particular would have heard of l4s or SCE by now, but none had on this particular trip, and I find myself explaining it (in as neutral terms as I can muster), and the only thing that works is describing "classic" as "normal" traffic, and the l4s queue as dctcp-style, and even then, it's rare I don't have to burn 10s of minutes explaining any of it. I would vastly prefer that that the term normal, or RFC3168-compliant or -style be used instead of classic throughout these materials. > > There are more than 500.000 hits in Google for „non-iPhone“ and I see > many that are not about fakes. > > Certainly, I don’t insist in the term „non-L4S“. This is just an > example. I already proposed „non-L4S-enabled“ as well. I fail to > understand how „non-L4S-enabled TCP“ could be confused with „non-L4S > traffic“. But, as outlined below, anyway there are other solutions. > > Also, I don’t object to the term „Classic“ when referring to ECN and > other related concepts if that use of the term has strong TSVWG > consensus. For instance, "classic“ ECN feedback, „classic“ queue, > „classic“ traffic would work for me in case TSVWG strongly supports > that term. > > Thus, personally, I am not asking for any disruptive change. I don’t > ask to avoid „Classic“ in general. > > What does *not* work for me is the term „Classic“ TCP, in particular > when refering to TCP as standardized by TCPM. I also don’t agree to > the term „classic“ congestion Control for Reno, CUBIC, CTCP, i.e., > work of the TCPM working group. To me, the authors of this document do > not have the right to tag work of the TCPM working group with a term > such as „classic“ that is used in marketing language. > > And there are plenty of simple ways to avoid that problematic term > „Classic“ TCP. Here are some more examples: > > * TCP without the L4S extension > * TCP (senders/stacks/connections) not using L4S > * TCP without support of L4S > * TCP (senders/stacks/connections) lacking L4S support > * TCP (senders/stacks/connections) not participating in the L4S > experiment > * … and more and also permutations thereof > > You can also try to reword text to just to avoid the term „Classic“ > TCP to work around the problem. > > Regarding congestion control, you can refer instead to > > * specific algorithms such as Reno or CUBIC > * „high-speed loss-based congestion control“ > * or any of the above terms, e.g., „congestion control without L4S > support“ and the like > > My ask is a simple editorial change that will IMHO only affect few > occurences of the term „Classic“. Can you please propose next steps > that addess my concern? > > Thanks > > Michael > > Von: Bob Briscoe > Gesendet: Mittwoch, 6. November 2019 01:22 > An: Scharf, Michael; Rodney W. Grimes > Cc: Wesley Eddy; tsvwg@ietf.org; tcpm@ietf.org > Betreff: Re: [tcpm] [tsvwg] L4S status tracking > > 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 > 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
- Re: [tcpm] [tsvwg] L4S status tracking Scharf, Michael
- Re: [tcpm] [tsvwg] L4S status tracking Black, David
- Re: [tcpm] [tsvwg] L4S status tracking Wesley Eddy
- Re: [tcpm] [tsvwg] L4S status tracking Bob Briscoe
- Re: [tcpm] [tsvwg] L4S status tracking Scharf, Michael
- Re: [tcpm] [tsvwg] L4S status tracking Rodney W. Grimes
- Re: [tcpm] [tsvwg] L4S status tracking Scharf, Michael
- Re: [tcpm] [tsvwg] L4S status tracking Scharf, Michael
- Re: [tcpm] [tsvwg] L4S status tracking Sebastian Moeller
- Re: [tcpm] [tsvwg] L4S status tracking Scharf, Michael
- Re: [tcpm] [tsvwg] L4S status tracking Bob Briscoe
- Re: [tcpm] [tsvwg] L4S status tracking Ingemar Johansson S
- Re: [tcpm] [tsvwg] L4S status tracking Sebastian Moeller
- Re: [tcpm] [tsvwg] L4S status tracking Scharf, Michael
- Re: [tcpm] [tsvwg] L4S status tracking Sebastian Moeller
- Re: [tcpm] [tsvwg] L4S status tracking Dave Taht
- Re: [tcpm] [tsvwg] L4S status tracking Bob Briscoe
- Re: [tcpm] [tsvwg] L4S status tracking Bob Briscoe
- Re: [tcpm] [tsvwg] L4S status tracking Rodney W. Grimes
- Re: [tcpm] [tsvwg] L4S status tracking Scharf, Michael
- Re: [tcpm] [tsvwg] L4S status tracking Wesley Eddy
- Re: [tcpm] [tsvwg] L4S status tracking Sebastian Moeller
- Re: [tcpm] [tsvwg] L4S status tracking Scharf, Michael
- Re: [tcpm] [tsvwg] L4S status tracking Ingemar Johansson S
- Re: [tcpm] [tsvwg] L4S status tracking Gorry Fairhurst
- Re: [tcpm] [tsvwg] L4S status tracking Gorry Fairhurst
- Re: [tcpm] [tsvwg] L4S status tracking Scharf, Michael
- Re: [tcpm] [tsvwg] L4S status tracking Black, David
- Re: [tcpm] [tsvwg] L4S status tracking Scharf, Michael
- Re: [tcpm] [tsvwg] L4S status tracking Ingemar Johansson S
- Re: [tcpm] [tsvwg] L4S status tracking Scharf, Michael
- Re: [tcpm] [tsvwg] L4S status tracking Bob Briscoe
- Re: [tcpm] [tsvwg] L4S status tracking Bob Briscoe
- Re: [tcpm] [tsvwg] L4S status tracking Bob Briscoe
- Re: [tcpm] [tsvwg] L4S status tracking Bob Briscoe
- Re: [tcpm] [tsvwg] L4S status tracking Sebastian Moeller
- Re: [tcpm] [tsvwg] L4S status tracking Scharf, Michael
- Re: [tcpm] [tsvwg] L4S status tracking Rodney W. Grimes
- Re: [tcpm] [tsvwg] L4S status tracking Bob Briscoe
- Re: [tcpm] [tsvwg] L4S status tracking Bob Briscoe
- Re: [tcpm] [tsvwg] L4S status tracking Scharf, Michael