Re: [tcpm] [tsvwg] L4S status tracking

[Bob Briscoe <[e-mail]>]

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


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

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

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.

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.

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.

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


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

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.

A huge amount of care went into getting the names right, before we 
started. 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/