Re: [tcpm] [tsvwg] L4S status tracking

[Gorry Fairhurst <[e-mail]>]

Going up one level. This is punted to you as chairs for a common decison 
- AFAIK, it is your protocol to maintain, please think and advise on 
what it is called.

Gorry

On 08/11/2019, 17:04, Ingemar Johansson S wrote:
> 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<[e-mail]>
>> Sent: den 6 november 2019 08:08
>> To: Ingemar Johansson S
>> <ingemar.s.johansson=[e-mail]>; Michael.Scharf@hs-
>> esslingen.de; [e-mail]
>> Cc: Ingemar Johansson S<[e-mail]>; [e-mail];
>> [e-mail]
>> 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=[e-mail]>  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<[e-mail]>
>>>> To: "Scharf, Michael"<[e-mail]>, "Rodney W.
>>>> 	Grimes"<[e-mail]>
>>>> Cc: Wesley Eddy<[e-mail]>, "[e-mail]"
>>>> 	<[e-mail]>, "[e-mail]"<[e-mail]>
>>>> Subject: Re: [tcpm] [tsvwg] L4S status tracking
>>>> Message-ID:<[e-mail]>
>>>> 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:[e-mail]>
>>>>> *Gesendet: *Montag, 4. November 2019 20:17
>>>>> *An: *Scharf, Michael<mailto:[e-mail]>
>>>>> *Cc: *Bob Briscoe<mailto:[e-mail]>; Wesley Eddy
>>>>> <mailto:[e-mail]>; [e-mail]
>>> <mailto:[e-mail]>;
>>>>> [e-mail]<mailto:[e-mail]>
>>>>> *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:[e-mail]>
>>>>>> Gesendet: Montag, 4. November 2019 19:09
>>>>>> An: Scharf, Michael<mailto:[e-mail]>;
>>> Wesley
>>>>> Eddy<mailto:[e-mail]>;
>>>>> [e-mail]<mailto:[e-mail]>
>>>>>> Cc: [e-mail]<mailto:[e-mail]>
>>>>>> 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 ?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:[e-mail]>
>>>>>> Gesendet: Sonntag, 11. August 2019 07:08
>>>>>> An: [e-mail]<mailto:[e-mail]>
>>>>>> 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
>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>> ________________________________________________________________
>>>>>> Bob Briscoe
>>>>>>
>>> https://protect2.fireeye.com/v1/url?k=9e3cf770-c2e8fb81-9e3cb7eb-864
>>>>>> 685b2085c-4ba6a1960c4f3e7a&q=1&e=bf49c0f0-380b-42d4-93a2-
>>>> 9ebedff802e
>>>>>> 0&u=http%3A%2F%2Fbobbriscoe.net%2F
>>>>>> _______________________________________________
>>>>>> tcpm mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>> --
>>>>> Rod Grimes [e-mail]
>>>> --
>>>>
>> ________________________________________________________________
>>>> 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
>>>> [e-mail]
>>>> 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.
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm