Re: [tcpm] [tsvwg] L4S status tracking

[Ingemar Johansson S <[e-mail]>]

Hi Sebastian

I clearly mentioned that I would prefer that the term "classic" is kept, the earth will likely continue to spin around its axis even if it is changed to something else 😊. But then it should be something that the group can agree on, I don't however see any consensus. 

/Ingemar 

> -----Original Message-----
> From: Sebastian Moeller <[e-mail]>
> Sent: den 6 november 2019 08:08
> To: Ingemar Johansson S
> <ingemar.s.johansson=[e-mail]>; Michael.Scharf@hs-
> esslingen.de; [e-mail]
> Cc: Ingemar Johansson S <[e-mail]>; [e-mail];
> [e-mail]
> Subject: Re: [tsvwg] [tcpm] L4S status tracking
> 
> Hi Ingmar,
> 
> IMHO this is a slippery slope argument. Because if minor changes to the naming
> are "impossible" how will changed to the underlying concepts and methods be
> acceptable to you. Because surely these other organizations already committed
> to what is proposed to the IETF as an experiment?
> My gripe with the classic moniker is that this term is not outcome neutral. What
> I mean is, that while in itself not necessarily negative, it implies that the new kid
> on the block is the way into the future, while the classic version should head into
> it's well-deserved retirement. And on the facts this simply is not settled or
> accepted in the case of L4S. IMHO the testing published by the L4S/RITE folks
> always tested conditions that are very favorable to L4S and completely ignored
> to reach out to the actual user community interested in low latency under load.
> It might well be that the L4S approach might also do well in a true stress test (bi-
> directiomal saturation on a asymmetric path with bursty cross traffic for
> starters), but I would like to see numbers first. And the L4S sce back-off data
> posted to this list in the path seems to indicate that L4S still has open ends that
> IMHO need addressing (independent of whether 3GPP likes this or not).
> 
> Best Regards
>         Sebastian
> 
> On November 6, 2019 7:12:39 AM GMT+01:00, Ingemar Johansson S
> <ingemar.s.johansson=[e-mail]> wrote:
> >Hi
> >
> >I would prefer that the term "Classic" is kept.
> >L4S is not anymore an IETF only matter. Work is ongoing to get support
> >for L4S in 3GPP for 5G and the input papers there use the term classic.
> >It is of course too late for changing classic to something else, but
> >then it is appreciated that It is something that the group can agree on
> >and I don't see that we are there, therefore it is better to stick to
> >"classic".
> >And to me the term "classic" does not sound negative.
> >
> >/Ingemar
> >
> >> Message: 3
> >> Date: Wed, 6 Nov 2019 00:22:44 +0000
> >> From: Bob Briscoe <[e-mail]>
> >> To: "Scharf, Michael" <[e-mail]>, "Rodney W.
> >> 	Grimes" <[e-mail]>
> >> Cc: Wesley Eddy <[e-mail]>, "[e-mail]"
> >> 	<[e-mail]>, "[e-mail]" <[e-mail]>
> >> Subject: Re: [tcpm] [tsvwg] L4S status tracking
> >> Message-ID: <[e-mail]>
> >> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
> >>
> >> 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 <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-
> >> hDvWO3I5MudwpNkKyH
> >> >
> >Y<https://mailarchive..ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNk
> >> > KyHY> , 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
> >> > >
> >https://protect2.fireeye.com/v1/url?k=9e3cf770-c2e8fb81-9e3cb7eb-864
> >> > > 685b2085c-4ba6a1960c4f3e7a&q=1&e=bf49c0f0-380b-42d4-93a2-
> >> 9ebedff802e
> >> > > 0&u=http%3A%2F%2Fbobbriscoe.net%2F
> >> >
> >> > > _______________________________________________
> >> > > tcpm mailing list
> >> > > [e-mail]
> >> > > https://www.ietf.org/mailman/listinfo/tcpm
> >> >
> >> > --
> >> > Rod Grimes [e-mail]
> >>
> >> --
> >>
> ________________________________________________________________
> >> Bob Briscoe
> >https://protect2.fireeye.com/v1/url?k=861241a8-
> >> dac64d59-86120133-864685b2085c-16120a27ab4a751a&q=1&e=bf49c0f0-
> >> 380b-42d4-93a2-9ebedff802e0&u=http%3A%2F%2Fbobbriscoe.net%2F
> >>
> >> -------------- next part -------------- An HTML attachment was
> >> scrubbed...
> >> URL:
> >>
> ><https://mailarchive.ietf.org/arch/browse/tcpm/attachments/20191106/de7
> >97
> >> fd1/attachment.html>
> >>
> >> ------------------------------
> >>
> >> Subject: Digest Footer
> >>
> >> _______________________________________________
> >> tcpm mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tcpm
> >>
> >>
> >> ------------------------------
> >>
> >> End of tcpm Digest, Vol 187, Issue 15
> >> *************************************
> 
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.