Re: [tcpm] [tsvwg] L4S status tracking

[Dave Taht <[e-mail]>]

"Scharf, Michael" <[e-mail]> 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; [e-mail]; [e-mail]
> 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; [e-mail]; [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-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:[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 http://bobbriscoe.net/
>     
>     > _______________________________________________
>     > tcpm mailing list
>     > [e-mail]
>     > https://www.ietf.org/mailman/listinfo/tcpm
>     
>     -- 
>     Rod Grimes [e-mail]