Re: [tsvwg] [tcpm] L4S status tracking

[Sebastian Moeller <[e-mail]>]

Hi Bob,

On November 6, 2019 1:22:44 AM GMT+01:00, Bob Briscoe <[e-mail]> wrote:
>Michael, Rod,
>
>Altho non-L4S is a reasonable idea, I think it has more of a negative 
>connotation than classic. 

        [SM] It does have the advantage though of being a testable, with classic all we know is you are talking about something that came before.

For instance, consider describing Android 
>phones as non-iPhones.

         [SM] In a discussion of say the merits of iPhones versus the competition that seems to be a decent description?

>
>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.

        [SM] Well, that use does not seem to interfere much, but if it does that would be another term to change, no?


>
>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.

        [SM] That is completely besides the point, it made me smile though and think about that passage in Alice in Wonderland about the meaning of words.


>
>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. 

        [SM] If it is not significant, then changing it surely is not a problem?

Indeed, it has become widely used and widely understood since 
>2015, and changing it to non-L4S now would cause unnecessary confusion.

        [SM] By that logic nothing in the L4S drafts should be changed? If I recall correctly that is not how getting a draft past reviewers works....

>
>
>
>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-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]

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.