Subject: Re: [tsvwg] [tcpm] L4S status tracking

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 6 Nov 2019 06:12:39 +0000

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 <[email-masked]>
> To: "Scharf, Michael" <[email-masked]>, "Rodney W.
> 	Grimes" <[email-masked]>
> Cc: Wesley Eddy <[email-masked]>, "[email-masked]"
> 	<[email-masked]>, "[email-masked]" <[email-masked]>
> Subject: Re: [tcpm] [tsvwg] L4S status tracking
> Message-ID: <[email-masked]>
> 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:[email-masked]>
> > *Gesendet: *Montag, 4. November 2019 20:17
> > *An: *Scharf, Michael <mailto:[email-masked]>
> > *Cc: *Bob Briscoe <mailto:[email-masked]>; Wesley Eddy
> > <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>;
> > [email-masked] <mailto:[email-masked]>
> > *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:[email-masked]>
> > > Gesendet: Montag, 4. November 2019 19:09
> > > An: Scharf, Michael<mailto:[email-masked]>; Wesley
> > Eddy<mailto:[email-masked]>;
> > [email-masked]<mailto:[email-masked]>
> > > Cc: [email-masked]<mailto:[email-masked]>
> > > 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:[email-masked]>
> > > Gesendet: Sonntag, 11. August 2019 07:08
> > > An: [email-masked]<mailto:[email-masked]>
> > > 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
> > > [email-masked]<mailto:[email-masked]>
> > > 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
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/tcpm
> >
> > --
> > Rod Grimes [email-masked]
> 
> --
> ________________________________________________________________
> 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/de797
> fd1/attachment.html>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
> 
> 
> ------------------------------
> 
> End of tcpm Digest, Vol 187, Issue 15
> *************************************

---

From: Sebastian Moeller <[email-masked]>
Date: Wed, 06 Nov 2019 08:07:30 +0100

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

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

---

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 8 Nov 2019 17:04:20 +0000

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 <[email-masked]>
> Sent: den 6 november 2019 08:08
> To: Ingemar Johansson S
> <ingemar.s.johansson=[email-masked]>; Michael.Scharf@hs-
> esslingen.de; [email-masked]
> Cc: Ingemar Johansson S <[email-masked]>; [email-masked];
> [email-masked]
> 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=[email-masked]> wrote:
> >Hi
> >
> >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".
> >> -------------- next part -------------- An HTML attachment was
> >> scrubbed...
> >> URL:
> >>

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 08 Nov 2019 17:19:34 +0000

I think we need to look to the TCPM working group chairs for advice on 
the naming of TCP varients that are specified in the RFC-series. I 
expect this question can be asked at the next TCPM meeting in Singapore 
- if there is no answer emerging from this thread.

Gorry

On 08/11/2019, 17:04, Ingemar Johansson S wrote:
>> From: Sebastian Moeller<[email-masked]>
>> Cc: Ingemar Johansson S<[email-masked]>; [email-masked];
>> [email-masked]
>>>> From: Bob Briscoe<[email-masked]>
>>>> To: "Scharf, Michael"<[email-masked]>, "Rodney W.
>>>> 	Grimes"<[email-masked]>
>>>> Cc: Wesley Eddy<[email-masked]>, "[email-masked]"
>>>> 	<[email-masked]>, "[email-masked]"<[email-masked]>
>>>> Message-ID:<[email-masked]>
>>>>> *Von: *Rodney W. Grimes<mailto:[email-masked]>
>>>>> *An: *Scharf, Michael<mailto:[email-masked]>
>>>>> *Cc: *Bob Briscoe<mailto:[email-masked]>; Wesley Eddy

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 08 Nov 2019 17:22:12 +0000

Going up one level. This is punted to you as chairs for a common decison 
- AFAIK, it is your protocol to maintain, please think and advise on 
what it is called.

Gorry

---

From: "Scharf, Michael" <[email-masked]>
Date: Fri, 8 Nov 2019 18:41:02 +0000

Hi Ingemar,

A question for clarification, given that the term "classic" is used for different aspects in L4S:

Does your preference include the terms 'Classic' TCP and 'Classic' congestion control, specifically when referring to a state-of-the-art TCP stack as currently shipped by major operating systems?

If so, can you provide references for use of the terms 'Classic' TCP and 'Classic' congestion control for what is currently widely deployed in the Internet? 

Thanks

Michael

> From: Ingemar Johansson S <[email-masked]>
> Sent: Friday, November 8, 2019 6:04 PM
> To: Sebastian Moeller <[email-masked]>; Ingemar Johansson S
> <ingemar.s.johansson=[email-masked]>; Scharf, Michael
> <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked]; Ingemar Johansson S
> <[email-masked]>
> Subject: RE: [tsvwg] [tcpm] L4S status tracking
> 
> 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
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 11 Nov 2019 09:44:22 +0000

Hi
I believe that it is best that I leave this discussion for the time being, I guess that it will be brought up again in some organized fashion. Hopefully then it will not eat up all the meeting time :-| 

/Ingemar

> From: Scharf, Michael <[email-masked]>
> Sent: den 8 november 2019 19:41
> To: Ingemar Johansson S <[email-masked]>; Sebastian
> Moeller <[email-masked]>; Ingemar Johansson S
> <ingemar.s.johansson=[email-masked]>;
> [email-masked]
> Cc: [email-masked]; [email-masked]
> Does your preference include the terms 'Classic' TCP and 'Classic' congestion
> control, specifically when referring to a state-of-the-art TCP stack as currently
> shipped by major operating systems?
> 
> If so, can you provide references for use of the terms 'Classic' TCP and 'Classic'
> congestion control for what is currently widely deployed in the Internet?
> 
> Thanks
> 
> Michael
> 
> 
> 
> > 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
> >
> > > <ingemar.s.johansson=[email-masked]>;
> > > Michael.Scharf@hs- esslingen.de; [email-masked]
> > > 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
> > > 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
> > > >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".
> > > >> 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
> > > >> 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.
> > > >>
> > > >> 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
> > > >> > > Terminology does matter to me given that I strongly disagree
> > > >> > > to
> > > >any
> > > >> > 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
> > > >> > 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
> > > >> > 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.
> > > >> > >
> > > >> > 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
> > > >> > > l4s-arch is getting a complete make-over for terminology, so
> > > >> > > I
> > > >will
> > > >> > check that next.
> > > >> > >
> > > >> > > inline...
> > > >> > >
> > > >> > >
> > > >> > hopefully be sorted just out by re-wording, albeit it may
> > > >> > require a careful analysis of all documents.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > As already noted in
> > > >> > KyHY> , I object to the terms ?traditional TCP? and also
> > > >> > KyHY> ?classic
> > > >TCP?
> > > >> > or ?legacy? TCP when referring to a TCP implementation
> > > >> > according to IETF standards-track RFCs.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > think 'classic' or 'traditional' are particularly pejorative,
> > > >> > tho
> > > >they
> > > >> > can be when used in a context that intends them to be. They
> > > >> > also
> > > >mean
> > > >> > > This is an enduring problem when trying to improve on the
> > > >> > > good
> > > >work
> > > >> > 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
> > > >> > > Nonetheless, it is also important not to be too precious
> > > >> > > about
> > > >past
> > > >> > negative connotations. Indeed, you have been an author (with
> > > >> > me) of
> > > >an
> > > >> > > When we (the L4S developers) were first looking for a term
> > > >> > > for
> > > >the
> > > >> > 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.
> > > >> > >
> > > >> > 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.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > 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.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > 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
> > > >> > apply to ?Classic QUIC? once the QUIC standard is finished. To
> > > >> > me
> > > >as a
> > > >> > ?classic? in the context of a brand-new transport protocol.
> > > >> > IMHO in that case the term ?classic? would be even more confusing.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > 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:
> > > >> > >
> > > >> > >
> > > >> > > 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.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > ><https://mailarchive.ietf.org/arch/browse/tcpm/attachments/20191106
> > > >/de7
> > > >97
> > > >> fd1/attachment.html>
> > > >>

---

From: "Scharf, Michael" <[email-masked]>
Date: Mon, 11 Nov 2019 10:30:29 +0000

Indeed, we will find a way to figure out what the consensus is.

@all: Input to the TCPM (and TSVWG) chairs is welcome, so that we can prepare a well-structured discussion and hopefully find a solution that works reasonably well for all.

Michael 

> Sent: Monday, November 11, 2019 10:44 AM
> To: Scharf, Michael <[email-masked]>; Sebastian Moeller
> <[email-masked]>; Ingemar Johansson S
> I believe that it is best that I leave this discussion for the time being, I guess
> that it will be brought up again in some organized fashion. Hopefully then it will
> not eat up all the meeting time :-|
> 
> /Ingemar
>