Re: [tcpm] [tsvwg] L4S status tracking

["Rodney W. Grimes" <[e-mail]>]

Bob,
	Reply inline with quoted text from draft as to "why" I,
and probably others are having issues with Classic and your
terminology.  All IMHO, of cource.

Regards,
Rod

> 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

Quoting the whole section inline: (WIth some markers added)

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

   Low-Latency, Low-Loss and Scalable (L4S) service:  The 'L4S' service
      is intended for traffic from scalable congestion control
      algorithms such as Data Center TCP.  But it is also more general--
      it allows the set of congestion controls with similar scaling
      properties to DCTCP to evolve (e.g.  Relentless TCP [Mathis09] and
      the L4S variant of SCREAM for real-time media [RFC8298].

      Both Classic and L4S services can cope with a proportion of
           ^B
      unresponsive or less-responsive traffic as well, as long as it
      does not build a queue (e.g.  DNS, VoIP, game sync datagrams,
      etc).

   Classic ECN:  The original Explicit Congestion Notification (ECN)
   ^A
      protocol [RFC3168].


Problem with these terminology definitions:

Classic is used in the names of 2 terms, marked A above, and then
used without any qualification in the definition of a third term,
marked as B.  I believe the inference at B is that of "Classic Service".

These terminology definintions are fuzzy, due to the use of words
like "current".  Which current is that?  The date the draft was
written, the date I am reading the draft?  This is a poor quality
term definition.

Since I can not put solid definitions of these terms in my mind
when I read the draft I am always asking myself exactly what is
"Classic" infering here?

My head spins when I try to parse the above "term" "L4S service",
and I can not build a solid model from the definition given.  It
is self referential (L4S is L4S variant of SCREAM).  It has wording
on what it can cope with.  For me this is not a definition of
a term.


Now, having said that, let me at least try to resolve one of
these terms.   There is actually no need to define "Classic ECN"
as its above definitions is "RFC3168 ECN", exactly 2 words, or
11 characters  in length as well, thus the term is not needed
and actually obfuscates the document.  I feel removeing all
references to "CLassic ECN" and replacing them with "RFC3168 ECN"
would make these drafts more understadable.

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

-- 
Rod Grimes                                                 [e-mail]