Re: [tcpm] [tsvwg] L4S status tracking

[Sebastian Moeller <[e-mail]>]

Dear Bob,

> On Nov 6, 2019, at 19:12, Bob Briscoe <[e-mail]> wrote:
> 
> Sebastien,
> 
> On 06/11/2019 07:18, Sebastian Moeller wrote:
>> 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.
> Which is a good starting point, because that's what is intended. 

	[SM] I know that this is what you intend, but it is the test of time that makes classics classics, no amount of wishful thinking of the new-kid-on-the-block will relegate the reigning champion into classic mode, your solution really has to a) be better, and more importantly b) supersede that champion in the first place.


> Plus it already has a slightly positive natural meaning of "something robust that has stood the test of time". Then it is defined precisely for the context of each L4S doc, e.g.:
> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-07#section-1.2

"Classic service:  The 'Classic' service is intended for all the
      behaviours that currently co-exist with TCP Reno (e.g.  TCP Cubic,
      Compound, SCTP, etc)."

Reading this implies that TCP Reno is not in the classic set, as you define that set as those co-existing with Reno and that is does not include Reno. But really =you can define what ever you want, but to have others accept your definition it better be useful.

> 
> 
>> 
>> 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?
> It is a decent description of the set of all phones that are not iPhones. But it has negative connotations when describing an instance, as in "Oh, you've got a non-iPhone"
> 
> Just as it is fine to use the phrase 'non-white people' when publishing the results of a survey comparing privileges for white people versus everyone else. But it would be totally insulting to describe black people as non-white people.

	[SM] Doing that will qualify you as a racist, but your description is precise; calling non-white people classic however might not be racist but also is not a useful dichotomy. I am totally capable of being oposed to both racism and sloppy ad-hoc definitions.


> 
>> 
>>> 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.
> [BB] Please try to understand why this is very much the critical issue (more important than the negative connotation question, which is subjective).

	[SM] Your are debating me to score points here, are you? You sort all flows into two categories, those that show L4S-style response to ECN signals and those that do not. The first group is reasonably homogenous, the second is not. So calling the second set non-L4S-style seems totally reasonably to me, unless you find another PROPERTY that defines that set, and no "classic" is not a property. This is getting as ridiculous as your 17 year old car example....


> 
> I believe you are thinking in the context of all traffic. Let's call that set A. And let's call the set of all L4S traffic L1.
> Then in this context, "Non-L4S" naturally means A - L1.
> 
> However, consider another context, say the context of all Low Latency traffic, that we'll call L2. This was the context of the example I found in the draft. In that context, the term "Non-L4S" already naturally means L2 - L1.

	[SM] Well, for me L4S traffic is traffic that show a "linear" response to CE markings instead of a "multiplicative" (we can argue whether that is the correct definition, but it sure beats the what ever I feel is L4S definition you seem to propose) and in that sense the set theoretical observations boil down to your first formulation. The fact that the L4S draft allows for your second formulation is a defect in that draft. The other stuff is not L4S but rather LoW-Latency traffic (which might be qualified to share L4S low latency queue with true L4S traffic).

> 
> So the term "Non-L4S" already has the intended meaning of Classic, but only in one context (A), and it has other meanings in every other context.

	[SM] If you insist on overloading definitions, be my guest to keep the pieces once things break.


> 
> It's a very bad idea to choose a name that already has a natural meaning that can be different to what you want to define the name to mean.

	[SM] I apologize I was not thinking about "in Wonderland" but about Through the Looking Glass (https://sabian.org/looking_glass6.php) :
"'When I make a word do a lot of work like that,' said Humpty Dumpty, 'I always pay it extra.'"
L4S has exactly zero natural meaning, so please stop pretending it does.

> 
>>> 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?
> [BB] Changing it to a problematic name like non-L4S (as explained above) would be a problem. 
> 
> Leaving it as it is, is not a significant problem, particularly because we chose Classic because it had the least negative connotation of all the words the thesaurus could throw at us. So this is obviously quite a subtle dependence on the mindset of the individuals involved.

	[SM] ??? Seems circular logic to me.


> 
> 
>> 
>> 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....
> Not at all. The aim of review is to ensure a draft is clearer - you will see we've made literally hundreds of changes already in response to those sort of requests. A reviewer doesn't have an automatic right to have all their requests satisfied, if they are not considered useful by the draft editor (or WG consensus if nec.)

	[SM] Sure, at the same time not every draft will be accepted.

> 
> I am resisting all the suggestions for a change of name so far, because "non-L4S" has the context-dependence problem I've already described. And all the other suggestions already have at best roughly equal negative connotations to Classic.
> 
> Anyway, nearly any choice of name for "something intended to be superseded" will develop negative connotations as soon as it is defined, even if it was completely meaningless when first coined. 

	[SM] How about you first sufficiently demonstrate that your "usurper" actually has the chops to dethrone the current king? And then if L4S proves ot be superior and dominant you can start calling what was before classic or legacy, but until then this seems not helpful.

> 
> A huge amount of care went into getting the names right, before we started.

	[SM] The head winds you encounter here (and I am not really counting myself here) seems to indicate that the magnitude might not have been sufficient...

SebastiAn


> I remember quoting Dijkstra at my colleagues at the time (I can't find the quote right now, but it's about how choice of names is paramount in programming). This one is nearly as relevant: 
> "Besides a mathematical inclination, an exceptionally good mastery of one’s native tongue is the most vital asset of a competent programmer. " Edsger Dijkstra
> 
> 
> 
> Bob
> 
> 
>> 
>>> 
>>> 
>>> 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]
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               
> http://bobbriscoe.net/