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

From: Bob Briscoe <[email-masked]>
Date: Mon, 4 Nov 2019 18:09:17 +0000

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:[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]
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: "Scharf, Michael" <[email-masked]>
Date: Mon, 4 Nov 2019 19:08:11 +0000

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.

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

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.

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

_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Mon, 4 Nov 2019 11:17:02 -0800 (PST)

> 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

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

-- 
Rod Grimes                                                 [email-masked]

---

From: "Scharf, Michael" <[email-masked]>
Date: Mon, 4 Nov 2019 19:21:59 +0000

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

Rod

---

From: "Scharf, Michael" <[email-masked]>
Date: Tue, 5 Nov 2019 07:47:54 +0000

I just parse the abstract of draft-ietf-tsvwg-ecn-l4s-id-08: "It gives an incremental migration path so that existing 'Classic' TCP traffic will be no worse off"

This wording does not work for me, as explained already. I disagree to moving forward with this terminology.

Thanks

Michael

From: tsvwg <[email-masked]> On Behalf Of Scharf, Michael
Sent: Monday, November 4, 2019 8:22 PM
To: Rodney W. Grimes <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [tsvwg] [tcpm] L4S status tracking

I agree. "non-L4S" may be even better.

Michael

Rod

> An: Scharf, Michael<mailto:[email-masked]>; Wesley Eddy<mailto:[email-masked]>; tsvwg@ietf..org<mailto:[email-masked]>
> Cc: [email-masked]<mailto:tcpm@ietf..org<mailto:[email-masked]>>
> As already noted in https://mailarchive.ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY<https://mailarchive..ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY<https://mailarchive.ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY%3chttps:/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.
>
>
>
> Bob Briscoe                               http://bobbriscoe.net/<http://bobbriscoe..net/>

--
Rod Grimes                                                 [email-masked]<mailto:[email-masked]>

---

From: Sebastian Moeller <[email-masked]>
Date: Tue, 5 Nov 2019 10:14:37 +0100

Hi Michael,

> On Nov 4, 2019, at 20:21, Scharf, Michael <[email-masked]> wrote:
> 

	[SM] except that L4S, which expands to "Low Latency, Low Loss, Scalable Throughput" (so it arguably should be LLLLST or L4ST)
arguably that is also "marketing language", no?

Sebastian

> Von: Rodney W. Grimes
> An: Scharf, Michael
> Cc: Bob Briscoe; Wesley Eddy; [email-masked]; [email-masked]
> > Cc: [email-masked]<mailto:tcpm@ietf..org>

---

From: "Scharf, Michael" <[email-masked]>
Date: Tue, 5 Nov 2019 22:21:42 +0000

And, well, there are no precedents for that in the IETF?

😉

Michael

Von: Sebastian Moeller<mailto:[email-masked]>
Gesendet: Dienstag, 5. November 2019 10:14
An: Scharf, Michael<mailto:[email-masked]>
Cc: Rodney W. Grimes<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Betreff: Re: [tsvwg] [tcpm] L4S status tracking

Hi Michael,

Sebastian

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 6 Nov 2019 00:22:44 +0000

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:
> *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
>
> > Terminology does matter to me given that I strongly disagree to any 
> use of ?marketing language? when it comes to TCP.
>
> > An: Scharf, Michael<mailto:[email-masked]>; Wesley 
> Eddy<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> > 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'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).
> >
> > I?d like to add a smaller item that is mostly editorial and can 
> 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.
> >
> > 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.
> >
> specification is ?standard TCP?. I would also be fine with other terms 
> > 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 
> 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 
> ?classic? in the context of a brand-new transport protocol. IMHO in 
> that case the term ?classic? would be even more confusing.
> >
> >
> >

---

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

Hi Bob,

On November 6, 2019 1:22:44 AM GMT+01:00, Bob Briscoe <[email-masked]> wrote:
>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.

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?

>you want it to have in certain contexts.

        [SM] Well, that use does not seem to interfere much, but if it does that would be another term to change, no?

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

>problem. 

        [SM] If it is not significant, then changing it surely is not a problem?

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

>> > I have never, to my knowledge, used the term classic TCP, or
>classic 
>> TCP congestion control.
>> >

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

---

From: "Scharf, Michael" <[email-masked]>
Date: Wed, 6 Nov 2019 07:23:24 +0000

Bob,

I am not convinced by any of your statements.

There are more than 500.000 hits in Google for „non-iPhone“ and I see many that are not about fakes.

Certainly, I don’t insist in the term „non-L4S“. This is just an example. I already proposed „non-L4S-enabled“ as well. I fail to understand how „non-L4S-enabled TCP“ could be confused with „non-L4S traffic“. But, as outlined below, anyway there are other solutions.

Also, I don’t object to the term „Classic“ when referring to ECN and other related concepts if that use of the term has strong TSVWG consensus. For instance, "classic“ ECN feedback, „classic“ queue, „classic“ traffic would work for me in case TSVWG strongly supports that term.

Thus, personally, I am not asking for any disruptive change. I don’t ask to avoid „Classic“ in general.

What does *not* work for me is the term „Classic“ TCP, in particular when refering to TCP as standardized by TCPM. I also don’t agree to the term „classic“ congestion Control for Reno, CUBIC, CTCP, i.e., work of the TCPM working group. To me, the authors of this document do not have the right to tag work of the TCPM working group with a term such as „classic“ that is used in marketing language.

And there are plenty of simple ways to avoid that problematic term „Classic“ TCP. Here are some more examples:

  *   TCP without the L4S extension
  *   TCP (senders/stacks/connections) not using L4S
  *   TCP without support of L4S
  *   TCP (senders/stacks/connections) lacking L4S support
  *   TCP (senders/stacks/connections) not participating in the L4S experiment
  *   … and more and also permutations thereof

You can also try to reword text to just to avoid the term „Classic“ TCP to work around the problem.

Regarding congestion control, you can refer instead to

  *   specific algorithms such as Reno or CUBIC
  *   „high-speed loss-based congestion control“
  *   or any of the above terms, e.g., „congestion control without L4S support“ and the like

My ask is a simple editorial change that will IMHO only affect few occurences of the term „Classic“. Can you please propose next steps that addess my concern?

Thanks

Michael

Von: Bob Briscoe<mailto:[email-masked]>
Gesendet: Mittwoch, 6. November 2019 01:22
An: Scharf, Michael<mailto:[email-masked]>; Rodney W. Grimes<mailto:[email-masked]>
Cc: Wesley Eddy<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Betreff: Re: [tcpm] [tsvwg] L4S status tracking

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

Michael

Rod

> An: Scharf, Michael<mailto:[email-masked]>; Wesley Eddy<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
> An: [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]><mailto:[email-masked]>

---

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

Hi Greg,

> On Sep 11, 2019, at 19:16, Greg White <[email-masked]> wrote:
> 
> I'm planning on doing testing as well, but it will be more than a day or two to get it done.  Rough timeframe would be 2-3 weeks from now.

	Since I can not hide my impatience any loger, did anything come out of this yet?

Best Regards
	Sebastian

> 
> -Greg
> 
> On 9/11/19, 1:52 AM, "Pete Heist" <[email-masked]> wrote:
> 
> 
>> On Sep 9, 2019, at 9:01 PM, Wesley Eddy <[email-masked]> wrote:
>> 
>> Since this thread seems to have dwindled, I just wanted to summarize that it looks to me like we have agreement that testing as described is needed.
>> 
>> I updated the issue tracker with a comment saying as much and pointing back to this thread in the archive for reference.
>> 
>> Is anyone planning to perform this testing in a rough timeframe they might want to share?
> 
>    Hi Wesley, I’ll share results from relevant testing in the next day or two...
> 
>    Regards,
>    Pete
> 
> 
>

---

From: Dave Taht <[email-masked]>
Date: Wed, 06 Nov 2019 07:49:25 -0800

> I am not convinced by any of your statements.

Me neither. Outside of this echo chamber no-one at any conference
I've been to of late has heard of L4S. 

I am recently back from the nanog+arin meetings in austin. (I'm not
there on aqm related business, I'm trying to do something new in
the NRO election [
https://www.youtube.com/playlist?list=PL726kQ53RX6imaiNabIZZKNZUmrBrT6pc
 ]  )

... but, being "mr bufferbloat", my self-selecting audience does come
up to me and chat. I've enjoyed learning all the places where cake is
penetrating in particular.

I would think that the nanog folk in particular would have heard
of l4s or SCE by now, but none had on this particular trip, and I
find myself explaining it (in as neutral terms as I can muster),
and the only thing that works is describing "classic" as "normal" traffic,
and the l4s queue as dctcp-style, and even then, it's rare
I don't have to burn 10s of minutes explaining any of it.

I would vastly prefer that that the term normal, or RFC3168-compliant or -style
be used instead of classic throughout these materials. 

> Certainly, I don’t insist in the term „non-L4S“. This is just an
> example. I already proposed „non-L4S-enabled“ as well. I fail to
> understand how „non-L4S-enabled TCP“ could be confused with „non-L4S
> traffic“. But, as outlined below, anyway there are other solutions.
>
> Also, I don’t object to the term „Classic“ when referring to ECN and
> other related concepts if that use of the term has strong TSVWG
> consensus. For instance, "classic“ ECN feedback, „classic“ queue,
> „classic“ traffic would work for me in case TSVWG strongly supports
> that term.
>
> What does *not* work for me is the term „Classic“ TCP, in particular
> when refering to TCP as standardized by TCPM. I also don’t agree to
> the term „classic“ congestion Control for Reno, CUBIC, CTCP, i.e.,
> work of the TCPM working group. To me, the authors of this document do
> not have the right to tag work of the TCPM working group with a term
> such as „classic“ that is used in marketing language.
>
> And there are plenty of simple ways to avoid that problematic term
> „Classic“ TCP. Here are some more examples:
>
> My ask is a simple editorial change that will IMHO only affect few
> occurences of the term „Classic“. Can you please propose next steps
> that addess my concern?
>
> Thanks
>
> Michael
>
> Von: Bob Briscoe
> An: Scharf, Michael; Rodney W. Grimes
> Cc: Wesley Eddy; [email-masked]; [email-masked]
> 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.
>
> 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
>
>     > Terminology does matter to me given that I strongly disagree to
>     any use of ?marketing language? when it comes to TCP.
>     
>     > An: Scharf, Michael<mailto:[email-masked]>;
>     Wesley Eddy<mailto:[email-masked]>;
>     [email-masked]<mailto:[email-masked]>
>     > 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.
>     > 
>     classic TCP congestion control.
>     > 
>     > 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).
>     > 
>     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.
>     > 
>     > 
>     > 
>     > 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.
>     > 
>     > 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.
>     > 
>     > 
>     > 
>     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.
>     > 
>     > 
>     >

---

From: Greg White <[email-masked]>
Date: Wed, 6 Nov 2019 16:23:18 +0000

Good timing __

We've just wrapped up our findings on Issue 17, and have posted them here (along with some comments on Issue 16 as well):

https://l4s.cablelabs.com 
 
(Note, the ns3 repo is not public yet, but will be shortly.   We'll update that page with links within a day or two.)

In summary, we reached the following conclusions:

- the main result of concern was due to a bug in initializing the value of TCP Prague alpha, which has been fixed and demonstrated to resolve the latency impact that was spanning multiple seconds

- the remaining short duration latency spike in the FIFO queue is seen in *all* congestion control variants tested, including BBRv1, NewReno, and Cubic, and is not specific to Prague

- if the CoDel queue is upgraded to perform Immediate AQM on L4S flows, the latency spike can be largely avoided.

We invite a thorough review of the work, but believe that this closes issue #17.

Best Regards,

Greg White, Tom Henderson, Olivier Tilmans

On 11/6/19, 12:59 AM, "Sebastian Moeller" <[email-masked]> wrote:

    Hi Greg,

    
    Best Regards
    	Sebastian

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 6 Nov 2019 18:12:30 +0000

Sebastien,

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

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

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

>          [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] 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

>> thing(s)

---

From: Dave Taht <[email-masked]>
Date: Wed, 06 Nov 2019 10:15:02 -0800

Greg White <[email-masked]> writes:

> - the main result of concern was due to a bug in initializing the
> value of TCP Prague alpha, which has been fixed and demonstrated to
> resolve the latency impact that was spanning multiple seconds
>
> - the remaining short duration latency spike in the FIFO queue is seen
> in *all* congestion control variants tested, including BBRv1, NewReno,
> and Cubic, and is not specific to Prague
>

I'm very glad to see y'all finding bugs in the initial implementations.

>     > I'm planning on doing testing as well, but it will be more than
>     > a day or two to get it done.  Rough timeframe would be 2-3 weeks
>     > from now.
>     
>     >> Since this thread seems to have dwindled, I just wanted to
>     >> summarize that it looks to me like we have agreement that
>     >> testing as described is needed.
>     >>

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 6 Nov 2019 18:36:37 +0000

Michael,

Regarding the only usage you say you do object to, I've already said...

> I have never, to my knowledge, used the term classic TCP, or classic 

...because Classic is intended as a a description of a set of congestion 
controls. The protocol is relatively irrelevant.

Pls see my response to Sebastien concerning the slightly positive 
connotation of the word 'classic'.
And how even a nonsense word coined for "something intended to be 
superseded" will develop a negative connotation as soon as it is defined.
This implies that the problem you've raised is impossible to solve 
without upsetting certain sensitive people.

Bob

On 06/11/2019 07:23, Scharf, Michael wrote:
> What does **not** work for me is the term „Classic“ TCP, in particular 
> *Von: *Bob Briscoe <mailto:[email-masked]>
> *Gesendet: *Mittwoch, 6. November 2019 01:22
> *An: *Scharf, Michael <mailto:[email-masked]>; Rodney 
> W. Grimes <mailto:[email-masked]>
> *Cc: *Wesley Eddy <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>> 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).
>> >
>> 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 
>> from the new, but we don't want to completely trash the thing that 
>> has already been successful, but had its day.
>> >
>> negative connotations. Indeed, you have been an author (with me) of 
>> an RFC on open issues in congestion control.
>> >
>> thing(s) we are trying to improve on". Not surprising, because it's 
>> difficult.
>> >
>> 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.
>> >
>> >
>> >
>> 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 
> Bob Briscoehttp://bobbriscoe.net/

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Wed, 6 Nov 2019 10:44:43 -0800 (PST)

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

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

> one?s native tongue is the most vital asset of a competent programmer. 
> "/ Edsger Dijkstra
> 
> 
> 
> Bob
> 
> 
> >
> >>
> >>
> >> Bob
> >>
> >>
> >>
> >>> I agree. ?non-L4S? may be even better.
> >>>
> >>> Michael
> >>>
> >>> as Michael suggests above, "non-L4S".?? Note that enabled
> >> appendix
> >> they
> >> has
> >> an
> >> terms
> >> is
> >> a

---

From: "Scharf, Michael" <[email-masked]>
Date: Wed, 6 Nov 2019 18:57:48 +0000

Bob,

>From draft-ietf-tsvwg-ecn-l4s-id-08: "It gives an incremental migration path so that existing 'Classic' TCP traffic will be no worse off"

You are proposing an experiment. Not more than that. I will be fine with the term "Classic" for TCP and TCPM-specified congestion control when more than 50% of Internet traffic uses that new technology.

Until this happens, I insist that the word "Classic" must be removed in all context of TCP and congestion control (as far as it is owned by TCPM), including the reference above. BTW, "normal" as suggested would also work for me. So, you have plenty of options for other terms.

Michael

From: Bob Briscoe <[email-masked]>
Sent: Wednesday, November 6, 2019 7:37 PM
To: Scharf, Michael <[email-masked]>; Rodney W. Grimes <[email-masked]>
Cc: Wesley Eddy <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [tcpm] [tsvwg] L4S status tracking

Michael,

...because Classic is intended as a a description of a set of congestion controls. The protocol is relatively irrelevant.

Pls see my response to Sebastien concerning the slightly positive connotation of the word 'classic'.
And how even a nonsense word coined for "something intended to be superseded" will develop a negative connotation as soon as it is defined.
This implies that the problem you've raised is impossible to solve without upsetting certain sensitive people.

Bob

There are more than 500.000 hits in Google for "non-iPhone" and I see many that are not about fakes.

Certainly, I don't insist in the term "non-L4S". This is just an example. I already proposed "non-L4S-enabled" as well. I fail to understand how "non-L4S-enabled TCP" could be confused with "non-L4S traffic". But, as outlined below, anyway there are other solutions.

Also, I don't object to the term "Classic" when referring to ECN and other related concepts if that use of the term has strong TSVWG consensus. For instance, "classic" ECN feedback, "classic" queue, "classic" traffic would work for me in case TSVWG strongly supports that term.

Thus, personally, I am not asking for any disruptive change. I don't ask to avoid "Classic" in general.

What does *not* work for me is the term "Classic" TCP, in particular when refering to TCP as standardized by TCPM. I also don't agree to the term "classic" congestion Control for Reno, CUBIC, CTCP, i.e., work of the TCPM working group. To me, the authors of this document do not have the right to tag work of the TCPM working group with a term such as "classic" that is used in marketing language.

And there are plenty of simple ways to avoid that problematic term "Classic" TCP. Here are some more examples:

  *   ... and more and also permutations thereof

You can also try to reword text to just to avoid the term "Classic" TCP to work around the problem.

  *   specific algorithms such as Reno or CUBIC
  *   "high-speed loss-based congestion control"
  *   or any of the above terms, e.g., "congestion control without L4S support" and the like

My ask is a simple editorial change that will IMHO only affect few occurences of the term "Classic". Can you please propose next steps that addess my concern?

Thanks

Michael

Michael, Rod,

Bob

Michael

Rod

--

--

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 6 Nov 2019 14:54:27 -0500

On 11/6/2019 1:57 PM, Scharf, Michael wrote:
>
> Bob,
>
> From draft-ietf-tsvwg-ecn-l4s-id-08: “It gives an incremental 
> migration path so that existing 'Classic' TCP traffic will be no worse 
> off”
>
> You are proposing an experiment. Not more than that. I will be fine 
> with the term “Classic” for TCP and TCPM-specified congestion control 
> when more than 50% of Internet traffic uses that new technology.
>
> Until this happens, I insist that the word “Classic” must be removed 
> in all context of TCP and congestion control (as far as it is owned by 
> TCPM), including the reference above. BTW, “normal” as suggested would 
> also work for me. So, you have plenty of options for other terms.
>

If Dave+Michael's suggestion of replacing "classic" with "normal" is 
agreable to others, this seems like a good way forward to me. It should 
be easy enough to explain in other SDOs that classic and normal mean the 
same thing, if this is a real issue.

(FWIW, I've never had a problem myself with "classic", nor read any 
negative connotations to it.  However, for the sake of working group 
progress, I think we just need to pick something that seems the least 
terrible and agree to move on.)

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 7 Nov 2019 00:04:10 +0100

Dear Bob,

> On Nov 6, 2019, at 19:12, Bob Briscoe <[email-masked]> wrote:
> 
> Sebastien,
> 
>> On November 6, 2019 1:22:44 AM GMT+01:00, Bob Briscoe 
>> <[email-masked]>
>>  wrote:
>> 
>>> Michael, Rod,
>>> 
> 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.:

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

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

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

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

> 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
>>> 
>>> 
>>> 
>>>> *Cc: *Bob Briscoe 
>>>> <mailto:[email-masked]>
>>>> ; Wesley Eddy 
>>>> 
>>>>> <mailto:[email-masked]>
>>>>> 
>>>>> <mailto:[email-masked]>
>>>>> ; Wesley 
>>>>> 
>>>> Eddy<mailto:[email-masked]>
>>>> ;
>>>> 
>>>>> Finally, I do not want this issue to take up any time that would 
>>>>> 
>>>> detract from technical issues.
>>>> 
>>>>> 
>>>>> 
>>>>> Bob
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> I created tickets in the TSVWG "trac" tool in order to help keep
>>>>> 
>>> track
>>> 
>>>>> 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.
>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>

---

From: Jonathan Morton <[email-masked]>
Date: Thu, 7 Nov 2019 05:14:56 +0200

> On 6 Nov, 2019, at 6:23 pm, Greg White <[email-masked]> wrote:
> 

Assuming this is still the same Alpha variable as in DCTCP, I take it that you are pre-loading the EWMA over the observed CE marking rate so that, upon first exiting slow-start, you're guaranteed to have a sharp reduction of cwnd.

If I'm understanding that correctly, I would characterise it as treating the symptom rather than the cause.  I do see the Flent graphs you've produced from the new version, and I find it interesting that you apparently now need a period of linear cwnd growth to converge on the actual path capacity after exiting slow-start, indicating a large negative-going overshoot.  I think this sort of artefact is illustrative of a poor match of solution to problem.

SCE's approach to halving the send rate immediately on slow-start exit is to tune the pacing scale factors, as described in the final slide from my Montreal presentation.  It strikes me that this would have the same effect for you, without needing to initialise Alpha to an unnatural value.

May I now draw your attention to the two-flow tests from Pete Heist's collection, in which the two flows are started 10 seconds apart?  I don't immediately see how this particular class of workarounds deals with the problem of needing to sharply reduce send rate in the first flow when the second flow starts, as this is not marked by an exit from slow-start, and by then the EWMA will have decayed to a relatively low steady-state value.  In this case the traffic collecting in the dumb FIFO will be a mixture of both flows.  SCE's approach to this problem utilises the original definition of CE, which SCE preserves but L4S does not.

Since I see that this workaround has been applied to the public TCP Prague repo a few days ago, we should be able to check this behaviour ourselves fairly soon.

> - the remaining short duration latency spike in the FIFO queue is seen in *all* congestion control variants tested, including BBRv1, NewReno, and Cubic, and is not specific to Prague

This is true, and we don't hold that against you.  It's an unfortunate property of this particular network topology.  The aim is to avoid making it worse or introducing additional problems.

> - if the CoDel queue is upgraded to perform Immediate AQM on L4S flows, the latency spike can be largely avoided.

This is not relevant, since the point of this exercise is to establish the extent of L4S' compatibility with existing, unmodified networks, in which Codel happens to be the most widely deployed AQM.  You cannot reasonably expect the entire Internet to "upgrade" to L4S compatible AQMs before you can safely begin deployment.

With that said, SCE behaves similarly when the FQ-AQM is SCE enabled.  Note that the AQM doesn't need to know whether the traffic is SCE-aware in order to safely apply the SCE signal, because the SCE and CE signals are not mutually ambiguous.

> We invite a thorough review of the work, but believe that this closes issue #17.

I think that remains to be established with more thorough testing, since a theoretical regression still appears to exist, and we need to be sure whether it's real or not.

Of course, if you are able to robustly solve issue #16, then it is likely that issue #17 will also go away.  I've skimmed your paper on the subject in the past couple of days, and I'm honestly surprised that you are only tackling that problem so late in the development cycle.  Again, we stand ready to test your solutions when they are properly implemented and thus testable.

 - Jonathan Morton

---

From: "Scharf, Michael" <[email-masked]>
Date: Thu, 7 Nov 2019 08:11:11 +0000

... and just to show that _my_ concern would be trivial to address by small editorial changes:

For the abstract of draft-ietf-tsvwg-ecn-l4s-id, the wording "It gives an incremental migration path so that normal TCP traffic classified in the 'Classic' service of L4S will be no worse off" would already work for me.  It just takes a small editorial change to make me happy. This can't be so hard.

Personally, I wonder if "classic" is indeed the best name for a service class (and, e.g., "normal" sounds better to me), but in the context of a service class, "classic" could actually work for me, if TSVWG really wants that name with strong consensus. I don't care how about names for DiffSe^D^D^D^D^D^D traffic classifiers, traffic policers/shapers, AQM schemes, or whatever else is done in the fast path of a router to implement low latency service.

I only object to specific terminology such as 'Classic' TCP or 'Classic' congestion control because I don't think that 'classic' is a proper characterization for TCPM standards or TCP/IP stack behavior not aligned with whatever L4S believes the bright future shall be.

Whether such small rewording address fully the concerns from others may be a different question.

Michael

From: Wesley Eddy <[email-masked]>
Sent: Wednesday, November 6, 2019 8:54 PM
To: Scharf, Michael <[email-masked]>; Bob Briscoe <[email-masked]>; Rodney W. Grimes <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [tcpm] [tsvwg] L4S status tracking

If Dave+Michael's suggestion of replacing "classic" with "normal" is agreable to others, this seems like a good way forward to me.  It should be easy enough to explain in other SDOs that classic and normal mean the same thing, if this is a real issue.

(FWIW, I've never had a problem myself with "classic", nor read any negative connotations to it.  However, for the sake of working group progress, I think we just need to pick something that seems the least terrible and agree to move on.)

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 7 Nov 2019 12:54:44 +0000 (UTC)

> This is not relevant, since the point of this exercise is to establish the extent of L4S' compatibility with existing, unmodified networks, in which Codel happens to be the most widely deployed > AQM.  You cannot reasonably expect the entire Internet to "upgrade" to L4S compatible AQMs before you can safely begin deployment.

I wonder if Codel actually is the most widely deployed AQM. This is not to dispute your point, which is correct - proposing an update to Codel doesn't addess existing deployments.It's just that I'm aware that there is an awful lot of kit out there which has an implementation of RED (or WRED) in hardware - eg for TR-059 [1], which mandates WRED support in BRAS. That's from having worked at a silicon vendor, so it doesn't give me visibility of actual usage. I understand a lot of it isn't switched on, but if even a small fraction of it was, it would be a pretty big deployment. It would be interesting if anyone has actual numbers. .  Of course, to be relevant to this discussion, it would need to be configured to do ECN marking as well. 

[1] https://www.broadband-forum.org/technical/download/TR-059.pdf
Alex

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 7 Nov 2019 14:06:07 +0100

Hi Greg,

great that you found this "bug".

But this also indicates to me that basically all testing for the L4S project needs to be repeated, since at least early tests were performed with DCTCP and it is clear that DCTCP and TCP Prague are not bug-to-bug compatible.

I wonder whether the proper order of things might not be:
a) finalize and stress-test at least one TCP Prague implementation
b) write a RFC describing TCP Prague
c) wait for acceptance of that RFC
d) introduce the next L4S related drafts again

Starting with d) before at least a) is achieved does not strike me as terribly efficient, as if a) should prove elusive d) would not need to be retracted?

Best Regards
	Sebastian

> On Nov 6, 2019, at 17:23, Greg White <[email-masked]> wrote:
> 
> Good timing __
>

---

From: Pete Heist <[email-masked]>
Date: Thu, 7 Nov 2019 11:25:11 -0500

> On Nov 7, 2019, at 7:54 AM, [email-masked] wrote:
> 
> I wonder if Codel actually is the most widely deployed AQM. This is not to dispute your point, which is correct - proposing an update to Codel doesn't addess existing deployments..

I can’t contribute any information to which is the most widely deployed, however to counter any suggestion that CoDel _isn’t_ widely deployed, Ubiquiti’s UniFi and EdgeMAX line of products use fq_codel in what they call their “smart queueing” feature, and are often deployed at bottlenecks (CPE equipment and backhauls). In their UniFi administrative controller, they also passively monitor TCP RTT, and according to some internal heuristic, send notifications to the administrator to consider turning on smart queueing (i.e. fq_codel) at the UniFi gateway. In the subtitle for the UniFi product page is the text “millions of shipments per year in 180+ countries”. Although that’s only marketing, it gives some idea of the scale of deployment from this vendor.

It does look like the issue is being worked on though, so this is just to add some weight to the importance of handling it well, which to me means minimizing false positives or negatives for non-L4S queue detection, minimizing detection time, and taking into account path changes that might move the bottleneck at any time. :)

---

From: Jonathan Morton <[email-masked]>
Date: Thu, 7 Nov 2019 18:36:35 +0200

> On 7 Nov, 2019, at 2:54 pm, [email-masked] wrote:
> 
> It's just that I'm aware that there is an awful lot of kit out there which has an implementation of RED (or WRED) in hardware - eg for TR-059 [1], which mandates WRED support in BRAS. That's from having worked at a silicon vendor, so it doesn't give me visibility of actual usage. I understand a lot of it isn't switched on, but if even a small fraction of it was, it would be a pretty big deployment. It would be interesting if anyone has actual numbers. .  Of course, to be relevant to this discussion, it would need to be configured to do ECN marking as well. 

My experience is that these hardware features are not actually deployed, ie. switched on, unless it is effectively mandated by backhaul usage pricing, to eliminate excess backhaul traffic that would get dropped at the DSLAM.  Then, it is as a hard-dropping policer, ie. without RFC-3168 support.

In your linked document, there is not a single mention of RFC-3168 or ECN, and even WRED is *only* mentioned in the context of upstream policing, which I would expect to be mostly irrelevant at the BRAS.

There are two DSL ISPs I know of that have deployed RFC-3168 compliant AQM in both directions (in BRAS and in CPE).  In both cases, it is a software implementation of fq_codel.

 - Jonathan Morton

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 07 Nov 2019 17:47:31 +0100

See below....

On November 7, 2019 5:25:11 PM GMT+01:00, Pete Heist <[email-masked]> wrote:
>> > > - if the CoDel queue is upgraded to perform Immediate AQM on L4S
>flows, the latency spike can be largely avoided.
>> 
>> > This is not relevant, since the point of this exercise is to
>establish the extent of L4S' compatibility with existing, unmodified
>networks, in which Codel happens to be the most widely deployed > AQM. 
>You cannot reasonably expect the entire Internet to "upgrade" to L4S
>compatible AQMs before you can safely begin deployment.
>> 
>> I wonder if Codel actually is the most widely deployed AQM. This is
>not to dispute your point, which is correct - proposing an update to
>Codel doesn't addess existing deployments..
>
>I can’t contribute any information to which is the most widely
>deployed, however to counter any suggestion that CoDel _isn’t_ widely
>deployed, Ubiquiti’s UniFi and EdgeMAX line of products use fq_codel in
>what they call their “smart queueing” feature, and are often deployed
>at bottlenecks (CPE equipment and backhauls). In their UniFi
>administrative controller, they also passively monitor TCP RTT, and
>according to some internal heuristic, send notifications to the
>administrator to consider turning on smart queueing (i.e. fq_codel) at
>the UniFi gateway. In the subtitle for the UniFi product page is the
>text “millions of shipments per year in 180+ countries”. Although
>that’s only marketing, it gives some idea of the scale of deployment
>from this vendor.
>
>It does look like the issue is being worked on though, so this is just
>to add some weight to the importance of handling it well, which to me
>means minimizing false positives or negatives for non-L4S queue
>detection, minimizing detection time, and taking into account path
>changes that might move the bottleneck at any time. :)

 [SM] I guess it is worth repeating that the obvious solution to all of these challenges would be to fix the actual root cause of the issue, instead of trying to paper over the symptoms. If L4S would not try to make the ECT(1) and the CE codepoint do the work that would require 2 independent bits neither issue 16 nor 17 would exist in the first place. I wonder how, after having eloquently argued for the requirement of strict isolation/separation between tcp-friendly and dctcp-style traffic, one could have converged on this clearly sub-optimal approach. 
I have read the discussion of the alternatives in the L4S draft and while clearly none of the options is perfect, most have less undesirable side effects on normal traffic than the admittedly clever 'overload ECN codepoints' variant that currently is being pushed.

Best Regards
        Sebastian

---

From: Jonathan Morton <[email-masked]>
Date: Thu, 7 Nov 2019 19:00:38 +0200

> On 7 Nov, 2019, at 6:47 pm, Sebastian Moeller <[email-masked]> wrote:
> 

> I have read the discussion of the alternatives in the L4S draft and while clearly none of the options is perfect, most have less undesirable side effects on normal traffic than the admittedly cleve…

I'm reasonably sure that most if not all of L4S' purported goals can be met, without the need for these complex workarounds, by switching to SCE-type signalling.  If it is then still desired to implement a distinct traffic class for L4S traffic, that can be done by defining a PHB and assigning a DSCP to it.

This isn't exactly rocket surgery; the KISS principle applies.

 - Jonathan Morton

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 07 Nov 2019 18:29:51 +0100

More below....

On November 7, 2019 6:00:38 PM GMT+01:00, Jonathan Morton <[email-masked]> wrote:
>> [SM] I guess it is worth repeating that the obvious solution to all
>of these challenges would be to fix the actual root cause of the issue,
>instead of trying to paper over the symptoms. If L4S would not try to
>make the ECT(1) and the CE codepoint do the work that would require 2
>independent bits neither issue 16 nor 17 would exist in the first
>place. I wonder how, after having eloquently argued for the requirement
>of strict isolation/separation between tcp-friendly and dctcp-style
>traffic, one could have converged on this clearly sub-optimal approach.
>
>
>> I have read the discussion of the alternatives in the L4S draft and
>while clearly none of the options is perfect, most have less
>undesirable side effects on normal traffic than the admittedly clever
>'overload ECN codepoints' variant that currently is being pushed.
>
>I'm reasonably sure that most if not all of L4S' purported goals can be
>met, without the need for these complex workarounds, by switching to
>SCE-type signalling.  If it is then still desired to implement a
>distinct traffic class for L4S traffic, that can be done by defining a
>PHB and assigning a DSCP to it.
>

Yes, not redefining what CE is supposed to mean, and using a new effectively unambiguous  method to signal a milder slow down command to interested listeners elegantly will remove the L4S side effects on normal traffic. At Wich point the requirement for strict isolation moves from essential to nice to have for L4S to achieve it's goals. I am sure there are workable solutions for L4S that are good enough to still merits the experiment for interested parties. IMHO the value of L4S will not be generically end 2 end anyway but will mostly consist in allowing to build dedicated low latency routes between paying parties and in that deployment model PHB/dscps should be genuinely feasible. I have high hopes that the IETF will in the end make the right decision that will reliably allow the L4S experiment to be performed in the open internet without putting normal traffic into potential risk, after all the E in IETF stands for engineering not experiments...

Sebastian

---

From: Dave Taht <[email-masked]>
Date: Thu, 07 Nov 2019 09:50:47 -0800

> I wonder if Codel actually is the most widely deployed AQM. This is

Codel is almost never deployed by itself.

FQ-codel is the most widely deployed, enabled AQM and so far as
I can tell, the only one with ECN enabled by default.

It is the default in apple's IOS (you have to jailbreak your iphone to
see it), on all interfaces, the default in OSX, the default in nearly
every linux distribution. (the last to add it was RHEL8). One thing
I've lost a lot of sleep over is the heavy use of containers and
network namespaces nowadays (billions of instances), where I fear
fq_codel is the only thing keeping the internet from exploding as
the box is essentially a "router" when used as such. 

The wifi version is the default (in linux) on QCA's ath9k and ath10k
chips, the mt76, and most recently, many of intel's chips as well.

So, that's kind of over a billion boxes.

Merely counting up the major wifi vendors shipping a version - google
chromebooks, google wifi, google fiber, evenroute, eero, meter, meraki,
tp-link, netgear, etc...

I hate to wave figures around without doing detailed research, but I can
comfortably say the wifi version is in the 10s of millions a year....

As for using fq_codel in QoS/SQM systems, it's got huge penetration, but
I doubt more than a fraction of a percent of users (outside the gaming
and clued business markets using ubnt and/or pfsense) enable it.

Free.fr shared details with me of a percentage of their deployment in a
few million dsl home routers. Of the 36,000 samples that I have, the top
level bits were:

* It's on the uplink only as the downlink invisibly multiplexes tv
* It is configured in the 3 class QoS system so common in SQM,
  with fq_codel on each class. Prioirity, best effort and background
* They have a *tight* - bql-like - interface to their DSL chip, so
  they don't need to shape at all, system automagically has pushback,
  copes with dsl problems, thus extremely low cpu costs.
  (I have extreme frustration with not seeing bql deploy widely elsewhere)
* 48% had exherted a CE at some point in this boot cycle. 
* A fairly typical drop and mark ratio is about 20/1 - meaning the
  majority of connections aren't using ecn.
* The customers are happy. Since 2012 :)
* They wish strongly that they could somehow get this into their fiber
* deployment, instead they use small fifos and hope for the best.

Me randomly picking a piece of data from their reference QoS
implemntation looks like this. You can infer the speed of the uplink
by the size of the target variable. (target is set to 1.5MTU at their
link rate)

qdisc prio 1: root refcnt 2 bands 2 priomap  1 1 1 1 1 1 0 0 1 1 1 1 1 1 1 1
 Sent 25418296010 bytes 152822679 pkt (dropped 329184, overlimits 0 requeues 481924) 
 backlog 0b 0p requeues 481924 
qdisc fq_codel 8001: parent 21:1 limit 10240p flows 1024 quantum 1538 target 61.0ms interval 100.0ms ecn 
 Sent 25308497918 bytes 152490355 pkt (dropped 327079, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
  maxpacket 44385 drop_overlimit 0 new_flow_count 17308870 ecn_mark 20738
  new_flows_len 0 old_flows_len 9
qdisc drr 21: parent 1:2 
 Sent 25418296010 bytes 152822679 pkt (dropped 329184, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc fq_codel 8002: parent 21:2 limit 10240p flows 1024 quantum 1538 target 61.0ms interval 100.0ms ecn 
 Sent 109798092 bytes 332324 pkt (dropped 2105, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
  maxpacket 1500 drop_overlimit 0 new_flow_count 369 ecn_mark 0
  new_flows_len 1 old_flows_len 4
qdisc fq_codel 11: parent 1:1 limit 10240p flows 1024 quantum 1538 target 61.0ms interval 100.0ms ecn 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
  maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0

The router itself runs multiple services locally and its tcp is cubic
with ecn enabled.

I know of about 14 other ISPs that have done some deployment but they
aren't willing to talk about it. One was overjoyed to share data with me
(as most of their network was fully fq_codeled and even "caked" at the
peering points) until they ran some rrul tests and realized how bloated
(seconds) some of their wireless services were. I figure they'll get
back to me after they fix that....

I've been looking for someone to collaborate with on a paper on this
dataset for some time. (I've got another fun research project going on
which is looking at bufferbloat in coffeeshops. Aside from google
starbucks, it's pretty dismal worldwide)

> It's just that I'm aware that there is an awful lot of kit out there
> which has an implementation of RED (or WRED) in hardware - eg for
> TR-059 [1], which mandates WRED support in BRAS. That's from having
> worked at a silicon vendor, so it doesn't give me visibility of actual
> usage. I understand a lot of it isn't switched on, but if even a small

I wish it was switched on, but it seems too hard to tune for most.

> fraction of it was, it would be a pretty big deployment. It would be
> interesting if anyone has actual numbers. . Of course, to be relevant

I have (in the US) only seen one (dsl) ISP that appears to have enabled
WRED in the BRAS, but my data set is limited,

> to this discussion, it would need to be configured to do ECN marking
> as well.

---

From: Pete Heist <[email-masked]>
Date: Fri, 8 Nov 2019 07:59:32 +0000

> On Nov 6, 2019, at 11:23 AM, Greg White <[email-masked]> wrote:
> 

Hi Greg, would it be possible to merge any changes you’d like to include in further testing into the testing (default) branch at https://github.com/L4STeam/linux? We’ll evaluate what we can with what time there is, but a prerequisite to that is making sure we have the right changes you want tested. :)

Thanks,
Pete

---

From: "Tilmans, Olivier (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 8 Nov 2019 10:41:52 +0000

> Hi Greg, would it be possible to merge any changes you’d like to include in
> further testing into the testing (default) branch at
> https://github.com/L4STeam/linux? We’ll evaluate what we can with what time
> there is, but a prerequisite to that is making sure we have the right
> changes you want tested. :)

Hi Pete,

As mentioned at https://l4s.cablelabs.com/l4s-testing/README.html (link
at the bottom of the page Greg linked), we ran your full set of flent
tests using this tag:
https://github.com/L4STeam/linux/releases/tag/testing%2F5-11-2019 

I doubt we'll push anything else on that repo for the moment being
unless someone comes out with a bug/fix/improvement. 

Best,
Olivier

---

From: Sebastian Moeller <[email-masked]>
Date: Fri, 8 Nov 2019 12:18:58 +0100

Hi Oliver,

I wonder how you intend to deal with scenario 1, cubic versus prague, where prague for short RTTs pummels cubic throughput, quite unlike what one naively could expect from reading the dualQ draft:

"Analytical study and implementation testing of the Coupled AQM have
   shown that Scalable and Classic flows competing under similar
   conditions run at roughly the same rate."

at 0ms RTT prague is ~10 times faster than cubic, and at 10ms this still is around a factor of 3, only at 80ms that gets into what I would consider "roughly the same rate". I now wonder what happens if you pair a short RTT (say 10ms) prague flow (simulating traffic from a nearby data center) with a cubic flow with a typical internet RTT (say 80ms). My prediction is that prague will dominate cubic similarly to the 0ms RTT. I guess this is coming from the default 1/16 scheduling weight for the normal queue, do you agree? 

> On Nov 8, 2019, at 11:41, Tilmans, Olivier (Nokia - BE/Antwerp) <[email-masked]> wrote:
> 

	Well, I would like to see scenario 1 with unequal RTTs between the two flows, like prague@10ms vs. cubic@80ms, and prage@80ms vs. cubic@10ms (and the same for cubic vs. cubic)
and I would like to see tests pitting 2 flows of one type versus one flow of the other type, like 2 cubic versus 1 prague and 2 prague vs. 1 cubic.

Best Regards
	Sebastian

---

From: Sebastian Moeller <[email-masked]>
Date: Fri, 8 Nov 2019 14:39:00 +0100

Hi Oliver,

I just stumbled over:
	
• TCP Prague will always use Accurate ECN, regardless of the net.ipv4.tcp_ecn value. This eases up concurrent testing of different CCA that may or may not want to use ECN (e.g., plain non-ECN cubic).

I assume that this is only for testing and not supposed to be the default for an eventual up-stream submission of tcp prague?

Sebastian

---

From: "Black, David" <[email-masked]>
Date: Fri, 8 Nov 2019 20:48:45 +0000

Hopefully not adding confusion, I'm in favor of Michael's suggestion (below), as I understand it:
                - L4S has a "Classic" service
                - Protocols and traffic that use the L4S "Classic" service are identified/named/described with terms other than "Classic".

For congestion control in particular, I've found myself referring to 1/p and 1/sqrt(p) congestion response behaviors for technical clarity/precision in discussion, but those terms don't exactly roll off the tip of the tongue ... and assume that the reader is familiar enough with TCP throughput equations to know what the variable p stands for.

Thanks, --David

From: tsvwg <[email-masked]> On Behalf Of Scharf, Michael
Sent: Thursday, November 7, 2019 3:11 AM
To: Wesley Eddy; Bob Briscoe; Rodney W. Grimes
Cc: [email-masked]; [email-masked]
Subject: Re: [tsvwg] [tcpm] L4S status tracking

[EXTERNAL EMAIL]

Michael

From: Wesley Eddy <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, November 6, 2019 8:54 PM
To: Scharf, Michael <[email-masked]<mailto:[email-masked]>>; Bob Briscoe <[email-masked]<mailto:[email-masked]>>; Rodney W. Grimes <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [tcpm] [tsvwg] L4S status tracking

---

From: "Scharf, Michael" <[email-masked]>
Date: Fri, 8 Nov 2019 21:03:16 +0000

Yep, that is exactly what I would suggest.

Michael

From: Black, David <[email-masked]>
Sent: Friday, November 8, 2019 9:49 PM
To: Scharf, Michael <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [tsvwg] [tcpm] L4S status tracking

Thanks, --David

From: tsvwg <[email-masked]<mailto:[email-masked]>> On Behalf Of Scharf, Michael
Sent: Thursday, November 7, 2019 3:11 AM
To: Wesley Eddy; Bob Briscoe; Rodney W. Grimes
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [tsvwg] [tcpm] L4S status tracking

[EXTERNAL EMAIL]

Michael

---

From: Pete Heist <[email-masked]>
Date: Sat, 9 Nov 2019 10:52:20 +0000

> On Nov 8, 2019, at 10:41 AM, Tilmans, Olivier (Nokia - BE/Antwerp) <[email-masked]> wrote:
> 

Ok, I see it now. I had assumed that we’d keep using the testing branch as we talked about before, so I could use its commit hashes as an identifier for what version was under test. My test scripts record only those hashes. I’ll adjust- that’s just to explain why I was looking to the testing branch for the latest changes. :)

Pete

---

From: "Tilmans, Olivier (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 11 Nov 2019 00:01:18 +0000

Hi Pete,

> Ok, I see it now. I had assumed that we’d keep using the testing branch as
> we talked about before, so I could use its commit hashes as an identifier
> for what version was under test. My test scripts record only those hashes.
> I’ll adjust- that’s just to explain why I was looking to the testing branch
> for the latest changes. :)

Given that 'testing' is the result of stacking the branches
[net-next] / AccECN-tcphdr / tcp_prague / sch_dualpi2

Its tip hash is unreliable/hence the tags. I'd guess your previous round
of tests was based on an earlier tag.

Best,
Olivier

---

From: "Tilmans, Olivier (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 11 Nov 2019 00:18:36 +0000

Hi Sebastian,

> I just stumbled over:
> 
> • TCP Prague will always use Accurate ECN, regardless of the
> net.ipv4.tcp_ecn value. This eases up concurrent testing of different CCA
> that may or may not want to use ECN (e.g., plain non-ECN cubic).
> 
> I assume that this is only for testing and not supposed to be the default
> for an eventual up-stream submission of tcp prague?

To achieve its goal (low latency even in the high percentiles), a sender has
to finely tune its sending rate to match the bottleneck queueing limit.
- CBR-sparse-* flows have no issue doing this as they tend to under-utilize the
link (or their service is simply broken anyway).
- Capacity-seeking/greedy flows need a way to estimate this limit--that is what
motivates the needs for a 1/p response with L4S.

DCTCP can achieve this estimation with an implicit, negociation-less, estimate
as it operates in a controlled environment (both in terms of endhost configuration
as they need to cooperate, and in terms of network behaviors, as ACK losses/thinning
could massively impact peformances)

Given that Prague aims to be "DCTCP over the internet", it has to withstand
middleboxes toying with the receive window, ACK thinning in WiFi/LTE/..., pure
ACK losses, encapsulation, proxies, ... Getting this fine-grained CE estimate in
order to deliver its service--LL even in the high percentiles, has to work in all
cases. AccECN is at the moment the only (as far as I know) reliable way
to get this fine-grained feedback/congestion estimate for TCP.
QUIC has this built-in its ACK frame, so does rmcat/SCReAM.

This is similar to DCTCP forcing the use/negociation of ECN, regardless of the actual
sysctl value, as it cannot provide its service without it (in other words, becomes
plains reno).

Of course, anyone can decide to write its own TCP CCA that does not want to rely on
AccECN yet somehow benefit from the marking given by the L queue, and experiment with
it--e.g., playing with the usual latency/bandwidth tradeoff.

Best,
Olivier

---

From: "Tilmans, Olivier (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 11 Nov 2019 00:38:09 +0000

Hi Sebastian,

> I wonder how you intend to deal with scenario 1, cubic versus prague, where
> prague for short RTTs pummels cubic throughput, quite unlike what one
> naively could expect from reading the dualQ draft:
> 
> at 0ms RTT prague is ~10 times faster than cubic, and at 10ms this still is
> around a factor of 3, only at 80ms that gets into what I would consider
> "roughly the same rate". 

I had the same question a couple of months ago when introduced to the dualQ.
The short answer here is that both flows do not compete under similar conditions:
they operate at different RTTs, which varies depending on their propagation delays.
E.g., at 0ms base, L4S flows see 1ms on average while classic flows see 15ms; at
10ms base, L4S sees 11ms and classic 25ms.

Given that flows have different overall RTTs, but are subject to the same marking
probabilities (albeit tuned to their reponse, i.e., linear or multiplicative), you
instead need to look at their cwnd--which must be equal[1]. Unfortunately, eye-balling
this from flent graph is not super convenient--tracing it, e.g., using eBPF, is
however straightforward.

[1] The 0ms case will likely yield a smaller than expected cwnd for L4S, cause by
10% WRR protection kicking it and artificially increasing classic's cwnd (as 1ms
vs 15ms would yield a 15x throughput difference if it was reno).

> I now wonder what happens if you pair a short RTT
> (say 10ms) prague flow (simulating traffic from a nearby data center) with a
> cubic flow with a typical internet RTT (say 80ms). My prediction is that
> prague will dominate cubic similarly to the 0ms RTT. I guess this is coming
> from the default 1/16 scheduling weight for the normal queue, do you agree?

You can disable the WRR entirely (i.e., set it to 0%) and the results will stay
the same (except for the 0ms case...).

Best,
Olivier

> 
> 
> 
> 
> > On Nov 8, 2019, at 11:41, Tilmans, Olivier (Nokia - BE/Antwerp)
> <[email-masked]> wrote:
> >
> 	Well, I would like to see scenario 1 with unequal RTTs between the
> two flows, like prague@10ms vs. cubic@80ms, and prage@80ms vs. cubic@10ms
> (and the same for cubic vs. cubic)
> and I would like to see tests pitting 2 flows of one type versus one flow of
> the other type, like 2 cubic versus 1 prague and 2 prague vs. 1 cubic.
> 
> Best Regards
> 	Sebastian
> 
> >
> >
> > Best,
> > Olivier

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 11 Nov 2019 01:33:56 +0100

Hi Oliver,

more below.

> On Nov 11, 2019, at 01:18, Tilmans, Olivier (Nokia - BE/Antwerp) <[email-masked]> wrote:
> 
> Hi Sebastian,
> 
>> I just stumbled over:
>> 

	[SM] Sorry, that does not compute to me, if at all it points at a bug in dctcp that would merit fixing. In essence dctcp aims a specific niche where this can be toerated, but since yi aim for replacing all current CCs, you need to play by the rules. TCP Prague with ECN disabled should behave like Reno, it should IMHO accept that a systems admin sets policy and needs to respect the tools used for that purpose. 

> it--e.g., playing with the usual latency/bandwidth tradeoff.

	[SM] I first want to be convinced by data that this whole idea actually works under real-world conditions (for short RTTs your data indicates that dualQ/TCP Prague actually does not manage to decouple bandwidth and latency), and for that purpose being able to disable the ECN/AccECN part of TCP Prague while keeping the rest seems like much better suited for A/B testing than silently ignoring the syscontrol. This, as I repeat myself too often in the L4S related threads, is not rocket science.

Best Regards
	Sebastian

---

From: "Tilmans, Olivier (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 11 Nov 2019 00:47:26 +0000

> 	[SM] Sorry, that does not compute to me, if at all it points at a bug
> in dctcp that would merit fixing. In essence dctcp aims a specific niche
> where this can be toerated, but since yi aim for replacing all current CCs,
> you need to play by the rules. TCP Prague with ECN disabled should behave
> like Reno, it should IMHO accept that a systems admin sets policy and needs
> to respect the tools used for that purpose.

Forcing to initiate the negotiation of (Acc)ECN (i.e., sending a SYN with
ECE/CWR(/NS) set) does not imply that said negotiation succeeds (e.g., if
the remote endpoint does not implement/allow it).
If the handshake fails, then the CC has an explicit trigger that it should
fallback to something else (at the moment, both become plain new reno).

Best,
Olivier

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 11 Nov 2019 01:58:01 +0100

Hi Oliver,

> On Nov 11, 2019, at 01:47, Tilmans, Olivier (Nokia - BE/Antwerp) <[email-masked]> wrote:
> 

	I am not a gate keeper for any of this (I guess you are lucky), but if you are telling me that to disable ECN use in TCP prague I need to intercept and mangle SYN packets, because you decided to ignore one toggle commonly used to disable/enable ECN on a host you will not make me happy. I assume that this assessment will be shared by a noticeable fractions of system administrators. But I guess the challenge is going to be to get this into the mainline kernel.

Best Regards
	Sebastian

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 11 Nov 2019 01:54:04 +0100

Hi Oliver,

> On Nov 11, 2019, at 01:38, Tilmans, Olivier (Nokia - BE/Antwerp) <[email-masked]> wrote:
> 
> Hi Sebastian,
> 

	[SM] You are telling me you were sitting on the knowledge that DualQ does not work as advertised, and just accepted that? No attempt have been made to remedy this (like setting the WRR to 50%).

> 10ms base, L4S sees 11ms and classic 25ms.

	[SM] Sorry that is not how humans interpret the claim in the introduction of the dualQ rfc. Similar conditions clearly imply the externally visible path length (aka unloaded RTT). 

> this from flent graph is not super convenient--tracing it, e.g., using eBPF, is

	[SM] This confirms my hypothesis that dualQ is not the proper tool here, just compare https://l4s.cablelabs.com/l4s-testing/key_plots/batch-l4s-s1-2-cubic-vs-prague-50Mbit-0ms_var.png with https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-09-13T045427-r1/l4s-s2-2/batch-l4s-s2-2-cubic-vs-prague-50Mbit-10ms_fixed.png. This is the expected 50:50 haring behaviour the dualQ draft implies, this is what you need to get close to if you want dualQ to be allowed on the internet, as on short RTTs to the nearest DC, L4S/TCP Prague will absolutely eat normal TCP's lunch and dinner. 

> the same (except for the 0ms case...).

	[SM] Again that implies that on intranet timescales dualQ does not offer the quality of isolation required to have L4S and non-L4S-style traffic peacefully coexist. But that is dualQ's whole "raison d'être". And this in the best case scenario, with an L4S AQM, this is quite sad.

---

From: Dave Taht <[email-masked]>
Date: Sun, 10 Nov 2019 17:09:48 -0800

As I keep sayin, a rrul test on an asymmetric network will also show
the side-effects of the RTT path inflation any of this stuff induces.

looking forward to seeing that result one day soon.

"Tilmans, Olivier (Nokia - BE/Antwerp)"

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 11 Nov 2019 09:48:46 +0100

Hi Dave,

> On Nov 11, 2019, at 02:09, Dave Taht <[email-masked]> wrote:
> 
> 

	Back of the envelop, instead of 1ms versus 15, we would in the best case see 2ms versus 30, same ratio but double the delta, this will make the imbalance probably even worse. I wonder how this would look with codel's 5ms @100ms interval instead of the proposed 15ms for pi2. Effectively this design gives a massive bandwidth advantage to L4S flows that can only be remedied by placing the non-L4S sources >=15ms closer to the endpoint, which for close DC type of loads does not seem very realistic.
	I now would like to see tests with say 5-10 flows for both classes with different RTTs each to see how/if the bandwidth distribution differs. It is well possible that I am overly alarmists here, but that can be easily ruled-out by simple tests.

Best Regards
	Sebastian

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Mon, 11 Nov 2019 10:34:02 +0100

Hi Olivier,

> instead need to look at their cwnd--which must be equal[1]. Unfortunately, eye-balling

Not sure that I understand what you mean here. Flows with different RTTs
typically need different CWnds to achieve sufficient throughput, but
their share of queued data at the bottleneck needs to be the same in
case you want flow rate fairness between them. This is, however,
different from requiring their CWnds to be equal...

> the same (except for the 0ms case...).

Regards,
 Roland

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 11 Nov 2019 10:48:36 +0100

Hi Roland,

> On Nov 11, 2019, at 10:34, Bless, Roland (TM) <[email-masked]> wrote:
> 
> Hi Olivier,
> 

	The Issue seems to be that, the language in the introduction not withstanding, DualQ/L4S effectively only guarantees to not completely starve non-L4S flows; as designed L4S traffic will outcompete non-L4S-traffic at any reference RTT, the shorter the base RTT the more pronounced this issue is going to be. Lets look at https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-10:

"Similar conditions" here according to Oliver is intended to denote RTT under load (wonder how this would look with codel's 5ms target @ 100ms instead of pi2's 15ms?). This might be working as intended, but I am still not convinced that that is as safe a design as claimed:

"However, until now, Scalable congestion controls
   did not co-exist with existing TCP Reno/Cubic traffic --- Scalable
   controls are so aggressive that 'Classic' TCP algorithms drive
   themselves to a small capacity share."

As fas as I can see this paragraph is still true for the currently implemented DualQ AQM TC Prague versions.

For what it is worth:

"Therefore, until now, L4S
   controls could only be deployed where a clean-slate environment could
   be arranged, such as in private data centres (hence the name DCTCP).
   This specification defines `DualQ Coupled Active Queue Management
   (AQM)', which enables these Scalable congestion controls to safely
   co-exist with Classic Internet traffic."

Effectively also seems counter to the data, as especially traffic from close by data centers will show the base RTT dependent imbalance. IMHO this effectively renders all the lofty words about decoupling latency under load from bandwidth moot.

Best Regards
	Sebastian

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 11 Nov 2019 14:58:45 +0000

Rod,

> marked as B.  I believe the inference at B is that of "Classic Service".
[BB]
B isn't a third term. The term is 'Classic service' which was just 
defined earlier.

It's regular English that, "Both red and green services..." means "Both 
the red service and the green service..."

Nonetheless, this does make me realize that we need an extra sentence at 
the end of each definition to explain that other nouns can be qualified 
by 'L4S' or 'Classic'. E.g. queue, congestion control, codepoint, 
packet, flow.

> written, the date I am reading the draft?  This is a poor quality
[BB] (When 'currently' is used in an RFC or any text for that matter, 
I'm sure everyone always understands it to mean, "when this was written".)

However, you're right that 'currently' is actually incorrect here, 
because the definition needs to include any Reno-friendly behaviours 
introduced in future as well. Thx. All the L4S drafts use these 
definitions, so I'll remove 'currently' from them all.

> on what it can cope with.  For me this is not a definition of
[BB] Good point. This is indeed not comprehensible without a definition 
of 'scalable congestion control', which we need to copy across from 
l4s-arch.

On "L4S variant of SCREAM", I don't believe it's self-referential, 'cos 
it's given in a list of examples, not as part of the definition. I had 
to call it that, because the variant doesn't have a name of its own.

However, this does make me realize that the use of SCTP as an example of 
a Classic behaviour is not right, because one could build a scalable 
congestion control into SCTP. In the list of examples of Classic 
behaviour I will change it to 'Reno-SCTP'.

> would make these drafts more understadable.
[BB] That's a possibility, and I use it sometimes. But many people use 
the term Classic ECN these days, probably because RFC3168 ECN requires 
the reader to remember yet another RFC number, which some people don't 
find easy. I'm not hearing a lot of resistance to the term 'Classic ECN'.

For instance, I find the names below are easier to read than the 
numbers, not just because they are shorter:
* 'RFC5681 congestion control' vs. 'Reno'.
* 'RFC8511 Cubic' vs. 'ABE-Cubic'?

Also, RFC3168 defined the response to ECN as equivalent to drop. So 
there is a useful (and deliberate) reinforcement of understanding in the 
association between Classic ECN and the Classic service (assuming we 
continue to use 'Classic' as the name for the service).

Thanks

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 11 Nov 2019 15:22:56 +0000

Sebastien,

      Chambers (British English)

classic adj *1* made of or belonging to the highest quality; established 
as the best. *2* entirely typical. *3* simple, neat and elegant, 
especially in a traditional style. noun *1* an established work of 
literature. *2* an outstanding example of its type. *3* something, eg an 
item of clothing, which will always last, irrespective of fashions and 
fads • /the little black dress, a classic of the 50s/. *4* (*Classic*) a 
celebrated annual sporting event, especially a horse race. See also the 
Classics <https://chambers.co.uk/search?xref=21C07352&query=the 
Classics&title=21st>. *classically* adverb *1* in a classic or classical 
way. *2* so as to be classical.
ETYMOLOGY: 17c: from Latin /classicus/ relating to classes, especially 
the best.

      Merriam Webster (US English)

clas·​sic | \ ˈkla-sik
1a *: *serving as a standard of excellence *: *of recognized value 
classic literary works a classic case study on hysteria
b *: *traditional 
<https://www.merriam-webster.com/dictionary/traditional>, enduring 
<https://www.merriam-webster.com/dictionary/enduring> classic designs
c *: *characterized by simple tailored lines in fashion year after year 
a classic suit
2 *: *of or relating to the ancient Greeks and Romans or their culture 
*: *classical <https://www.merriam-webster.com/dictionary/classical>
3a *: *historically memorable a classic battle
b *: *noted because of special literary or historical associations Paris 
is the classic refuge of expatriates
4a *: *authentic <https://www.merriam-webster.com/dictionary/authentic>, 
authoritative <https://www.merriam-webster.com/dictionary/authoritative> 
a classic study of eyewitness accounts
b *: *typical <https://www.merriam-webster.com/dictionary/typical> a 
classic example of chicanery a classic error

Responses inline...

> 	[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 int…
[BB] Not at all. Because classic has no hint of inferior. Quite the 
opposite according to the dictionaries.

This is an excellent demonstration of how any term, even a good positive 
one, attracts a negative connotation as soon as it is used to mean "the 
things that are claimed to be improved on". This says to me that the 
quest for a better word than classic will be fruitless.

Just like how kids quickly started to use the word 'special' as a term 
of abuse soon after the phrase "children with special needs" was 
introduced by well-meaning people.

> 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,…
[BB] Good point. I'll certainly fix that along with the problems that 
Rod pointed out.

> 	[SM] Your are debating me to score points here, are you?
[BB] Not at all. We need a context-independent meaning. I am raising a 
practical problem with choosing a name that contains an element ("non-") 
with a natural meaning that will change the presumed meaning of 
"non-L4S" dependent on context.

> 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.
[BB] Non-L4S would be reasonable, were it not for its context-dependence 
problem. On what basis can you say that classic is not a property, when 
it is (both as defined for the L4S drafts, and as a well-understood 
adjective)?

> This is getting as ridiculous as your 17 year old car example....
>
>
> 	[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)
[BB] Are you really meaning to say that I don't know the theoretical 
grounding of my own research as well as you do?

BTW, Reno, Cubic and L4S responses to congestion are all multiplicative.

>   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).
>
[BB] The current draft does not overload any definition of 'non-L4S'. It 
uses its natural meaning of "traffic that is not L4S" in the reduced 
context of the low latency queue. That's why I picked it as an example 
of a context-dependent word that would not be useful as a 
context-independent name.

> L4S has exactly zero natural meaning, so please stop pretending it does.
[BB] When expanded it completely describes what it means: "Low Latency 
Low Loss Scalable throughput".

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 11 Nov 2019 15:30:43 +0000

Michael,

On 07/11/2019 08:11, Scharf, Michael wrote:
>
> … and just to show that _/my/_ concern would be trivial to address by 
> small editorial changes:
>
> For the abstract of draft-ietf-tsvwg-ecn-l4s-id, the wording “It gives 
> an incremental migration path so that normal TCP traffic classified in 
> the ‘Classic’ service of L4S will be no worse off” would already work 
> for me.  It just takes a small editorial change to make me happy. This 
> can’t be so hard.
>
> Personally, I wonder if “classic” is indeed the best name for a 
> service class (and, e.g., “normal” sounds better to me), but in the 
> context of a service class, “classic” could actually work for me, if 
> TSVWG really wants that name with strong consensus. I don’t care how 
> about names for DiffSe^D^D^D^D^D^D traffic classifiers, traffic 
> policers/shapers, AQM schemes, or whatever else is done in the fast 
> path of a router to implement low latency service.
>
> I only object to specific terminology such as ‘Classic’ TCP or 
> ‘Classic’ congestion control because I don’t think that ‘classic’ is a 
> proper characterization for TCPM standards or TCP/IP stack behavior 
> not aligned with whatever L4S believes the bright future shall be.
>
I thought I had already agreed to remove 'TCP' from all instances of 
'Classic TCP traffic' etc, and that I hadn't intended to include 'TCP' 
in the first place. Because it's the congestion controls that are 
relevant in L4S drafts, not the protocols.

Bob
> *From:*Wesley Eddy <[email-masked]>
> *Sent:* Wednesday, November 6, 2019 8:54 PM
> *To:* Scharf, Michael <[email-masked]>; Bob Briscoe 
> <[email-masked]>; Rodney W. Grimes <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [tcpm] [tsvwg] L4S status tracking
>
>     migration path so that existing 'Classic' TCP traffic will be no
>     worse off”
>
>     You are proposing an experiment. Not more than that. I will be
>     fine with the term “Classic” for TCP and TCPM-specified congestion
>     control when more than 50% of Internet traffic uses that new
>     technology.
>
>     Until this happens, I insist that the word “Classic” must be
>     removed in all context of TCP and congestion control (as far as it
>     is owned by TCPM), including the reference above. BTW, “normal” as
>     suggested would also work for me. So, you have plenty of options
>     for other terms.
>
> agreable to others, this seems like a good way forward to me.  It 
> should be easy enough to explain in other SDOs that classic and normal 
> mean the same thing, if this is a real issue.
>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 11 Nov 2019 16:00:28 +0000

Wes,

Pls see the dictionary definitions of classic (as just posted in a 
response to Sebastian), which are all about superlative and enduring 
quality. I really don't think we will find a better word.

I'm afraid what is 'normal' changes over time, which is to be avoided 
for an RFC. We deliberately chose 'Classic' because it had a sense of 
"The stuff that has stood the test of time up to publication of this RFC".

If we use 'Normal' for the Reno-friendly service, it will always imply 
that L4S is not normal, even if L4S becomes normal (which is usually the 
intent of the IETF publishing an RFC).

I have no desire to use a word that means 'inferior to L4S'. But I'm not 
happy to use a word that implies that L4S is abnormal. Sorry to make 
resolution of this one difficult (and BTW, thanks go to Michael Scharf 
for being clear on what he can compromise on).

PS. I would like to hear whether anyone who has been either neutral or 
supportive of L4S perceives anything negative in the word 'Classic'. I 
suspect they have tuned out of this thread.

Bob

On 06/11/2019 19:54, Wesley Eddy wrote:
>> in all context of TCP and congestion control (as far as it is owned 
>> by TCPM), including the reference above. BTW, “normal” as suggested 
>> would also work for me. So, you have plenty of options for other terms.
>>
>

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 11 Nov 2019 17:30:26 +0100

Hi Bob,

to be quite honest, the definitions you seem to insist upon are annoying and your rationale to explain your choices do not really convince me as given in good-faith.
To repeat once more before I move on to more substantial issues:
	You use classic in a sense of "The stuff that has stood the test of time up to publication of this RFC", and I believe it is very pretentious to assume that "this RFC" is going to replace the status quo especially given that the drafts seem to be in the experimental track. 

But my bigger problem is not how you name non-L4S traffic, but what L4S does to non-L4S traffic,
According to recently the measured and posted data L4S/dualQ/ AQMTCP Prague simply does not work as advertised.

Not sure about the consensus opinion here, but the reported unfairness at low RTTs does indicate that at least the tested dualQ aqm implementation does not actually manage to make "Scalable and Classic flows competing under similar conditions run at roughly the same rate." 

Neither ~10:1 @~0ms RTT (https://l4s.cablelabs.com/l4s-testing/key_plots/batch-l4s-s1-2-cubic-vs-prague-50Mbit-0ms_var.png) nor 3:1 @ 10ms RTT (https://l4s.cablelabs.com/l4s-testing/key_plots/batch-l4s-s1-2-cubic-vs-prague-50Mbit-10ms_var.png) qualify as "roughly the same rate" in my opinion. Oliver argued that this might be to be expected behavior due to the different RTTS under load for both queues, but he also admitted that he posed the same question, indicating that even members of the L4S development team consider traffic on the same path as "under similar conditions".

	This imbalance could be caused by (hopefully fixable) inefficiencies/bugs in the dualQ and/or TCP Prague implementations, or it could be part of L4S design; in which case I argue that this needs to be spelled out in excruciating detail in the draft. 
	I find it a bit hard to believe that someone as verbose as you could use the term "run at roughly the same rate" to mean "Scalable traffic does not completely starve non-scalable traffic". 
	The fact that this bias seems to diminish with increasing RTTs could be construed that at typical internet RTTs of ~100ms this effect does not matter much anymore, but that interpretation ignores that a considerable fraction of traffic is delivered from close-by data centers. 

Best Regards
	Sebastian

> On Nov 11, 2019, at 16:22, Bob Briscoe <[email-masked]> wrote:
> 
> Sebastien,
> 
> classic adj 1 made of or belonging to the highest quality; established as the best. 2 entirely typical. 3 simple, neat and elegant, especially in a traditional style. noun 1 an established work of literature. 2 an outstanding example of its type. 3 something, eg an item of clothing, which will always last, irrespective of fashions and fads • the little black dress, a classic of the 50s. 4 (Classic) a celebrated annual sporting event, especially a horse race. See also the Classics. classically adverb 1 in a classic or classical way. 2 so as to be classical. 
> ETYMOLOGY: 17c: from Latin classicus relating to classes, especially the best.
> 
> 1a : serving as a standard of excellence : of recognized value classic literary works a classic case study on hysteria
> b : traditional, enduring classic designs
> c : characterized by simple tailored lines in fashion year after year a classic suit
> 2 : of or relating to the ancient Greeks and Romans or their culture : classical
> 3a : historically memorable a classic battle
> b : noted because of special literary or historical associations Paris is the classic refuge of expatriates
> 4a : authentic, authoritative a classic study of eyewitness accounts
> b : typical a classic example of chicanery a classic error
> 
> Responses inline...
> 
> 
> [BB] Not at all. Because classic has no hint of inferior. Quite the opposite according to the dictionaries.
> 
> This is an excellent demonstration of how any term, even a good positive one, attracts a negative connotation as soon as it is used to mean "the things that are claimed to be improved on". This says to me that the quest for a better word than classic will be fruitless.
> 
> Just like how kids quickly started to use the word 'special' as a term of abuse soon after the phrase "children with special needs" was introduced by well-meaning people.
> 
>> 
>> 
>> 
> [BB] Good point. I'll certainly fix that along with the problems that Rod pointed out.
> 
> 
> [BB] Not at all. We need a context-independent meaning. I am raising a practical problem with choosing a name that contains an element ("non-") with a natural meaning that will change the presumed meaning of "non-L4S" dependent on context.
> 
> [BB] Non-L4S would be reasonable, were it not for its context-dependence problem. On what basis can you say that classic is not a property, when it is (both as defined for the L4S drafts, and as a well-understood adjective)?
> 
> 
> [BB] Are you really meaning to say that I don't know the theoretical grounding of my own research as well as you do? 
> 
> [BB] The current draft does not overload any definition of 'non-L4S'. It uses its natural meaning of "traffic that is not L4S" in the reduced context of the low latency queue. That's why I picked it as an example of a context-dependent word that would not be useful as a context-independent name.
> 
> 
>> 
>> 
>> 
> [BB] When expanded it completely describes what it means: "Low Latency Low Loss Scalable throughput".
> 
> 
> 
> Bob
> 
> --

---

From: Pete Heist <[email-masked]>
Date: Mon, 11 Nov 2019 20:57:23 +0100

Hi, thanks for working on the issues we posted in our “bakeoff” tests on Sep. 12. We have updated our repo with a re-run of the tests using the L4S code as of the tag 'testing/5-11-2019', and those results are at the same location:

https://github.com/heistp/sce-l4s-bakeoff/

We’ve put together a list of changes we saw in the results:

https://github.com/heistp/sce-l4s-bakeoff#changes

The changes are:

- The previously reported intermittent TCP Prague utilization issues appear to be fixed.

- TCP Prague vs Cubic now does converge to fairness, but appears to have fairly long convergence times at 80ms RTT (example: https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-11-11T090559-r2/l4s-s3-2/batch-l4s-s3-2-prague-vs-prague-50Mbit-80ms_fixed.png). Convergence times in other scenarios are similarly long.

- In scenarios 2, 5 and 6, the previously reported L4S interaction with CoDel seems to be partially, but not completely fixed. By reversing the flow start order (prague vs cubic instead of cubic vs prague, second flow delayed by 10 seconds), we can see that while the TCP RTT spikes no longer occur at flow start, they are still present when a second flow is introduced after slow-start exit (example: https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-11-11T090559-r2/l4s-s2-2/batch-l4s-s2-2-prague-vs-cubic-50Mbit-80ms_fixed.png).

- In scenario 3 (single queue AQM at 10ms RTT), the previously reported unfairness between TCP Prague and Cubic grew larger, from ~4.1x (40.55/9.81Mbit) to ~7.7x (44.25/5.78Mbit). This trend appears to be consistent at other RTT delays in the same scenario (0ms and 80ms).

I will update the issues in trac with these results, and if there are any questions let us know…

Pete

> On Nov 6, 2019, at 5:23 PM, Greg White <[email-masked]> wrote:
> 
> Good timing __
>

---

From: Greg White <[email-masked]>
Date: Mon, 11 Nov 2019 21:31:43 +0000

Hi Pete,

Thanks for posting the updated results.

In the Issue 17 related scenario (Scenario 6), you observed that there was a 5-second-long latency spike for the TCP cubic flow (but for none of the other flows) when the cubic flow starts up.  

https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-11-11T090559-r2/l4s-s6-2/batch-l4s-s6-2-prague-vs-cubic-50Mbit-80ms_fixed.png

Since this latency spike is only present for the cubic flow, it is clearly not in the shared FIFO, but in the fq_codel queue. I'm having trouble understanding how TCP Prague could be causing queuing delay that *only* affects a cubic flow in a different queue.  Could you explain how this is possible?  It seems like it may be an error in your result.

-Greg

On 11/11/19, 12:57 PM, "Pete Heist" <[email-masked]> wrote:

    

    The changes are:

    

    
    Pete

---

From: Greg White <[email-masked]>
Date: Mon, 11 Nov 2019 21:51:35 +0000

....actually, I think I misread your comment (and plot*).   The latency spike is _not_ for the TCP cubic flow, but rather for the Prague flow.

So, this is a case of fq immediately cutting the BDP in half due to the arrival of a second flow, but not providing sufficient congestion signaling to Prague to cause it to reduce its cwnd quickly.   The sluggish ramp up of the marking probability in the CoDel AQM being a mismatch to the Prague congestion response is the cause here.

-Greg

*in my defense the flent plots aren't the friendliest for color-deficient viewers.

On 11/11/19, 2:32 PM, "tsvwg on behalf of Greg White" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Pete,

    

    -Greg

    

        
        
        The changes are:

        

        
        Pete

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 11 Nov 2019 23:32:54 +0100

Hi Greg,

> On Nov 11, 2019, at 22:51, Greg White <[email-masked]> wrote:
> 

	Interestingly, it seems that the recent change of exiting slow start by ~halving the sending rate helps for Prague on position 2, by effectively making Prague respond to the first CE mark in a RFC3168 compatible fashion, but as the Prague at 1st position test shows, this does not help if Prague is running at too high a rate in congestion avoidance mode.
	IMHO, that is one of the reasons why there is so much concern about re-defining the meaning of CE markings. In this specific case the negative side-effect of this seem to be restricted to Prague, that is something I could live with. 
What happens at scenario 1 at low RTTs and at scenario 3 is different, here it is the non-L4S traffic that takes an unexpected/undeserved hit. 

> *in my defense the flent plots aren't the friendliest for color-deficient viewers.

	I believe no defense necessary, there are lots of plots with often only subtle differences and colors that are nicely organized, but hard to keep apart. Loading the files into flent's GUI allows to hover over the legend and the according line gets highlighted, maybe an option if higher saliency is required?

Sebastian

---

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

OK, so we seem to make some progress at least regarding the term 'classic' TCP. As mentioned before, I personally would find the term 'Classic' QUIC very confusing and you cannot avoid that if you talk about 'Classic' TCP, IMHO. So, it seems better to avoid that terminology for all transport protocols. For the record, in draft-ietf-tsvwg-ecn-l4s-id-08 the combination of the terms 'classic' and 'TCP' back-to-back is used 11 times as far as I can see.

Regarding congestion control, I'd like to emphasize that David's proposal would also work well for me, i.e., characterizing the congestion control by functional properties. This avoids all issues regarding whether something will supersede something else (including the issue that EXP is just an experiment that won't update or replace any PS document).

Michael

From: Bob Briscoe <[email-masked]>
Sent: Monday, November 11, 2019 4:31 PM
To: Scharf, Michael <[email-masked]>; Wesley Eddy <[email-masked]>; Rodney W. Grimes <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [tcpm] [tsvwg] L4S status tracking

Michael,

I only object to specific terminology such as 'Classic' TCP or 'Classic' congestion control because I don't think that 'classic' is a proper characterization for TCPM standards or TCP/IP stack behavior not aligned with whatever L4S believes the bright future shall be.
I thought I had already agreed to remove 'TCP' from all instances of 'Classic TCP traffic' etc, and that I hadn't intended to include 'TCP' in the first place. Because it's the congestion controls that are relevant in L4S drafts, not the protocols.

Bob

Michael

From: Wesley Eddy <[email-masked]><mailto:[email-masked]>
Sent: Wednesday, November 6, 2019 8:54 PM
To: Scharf, Michael <[email-masked]><mailto:[email-masked]>; Bob Briscoe <[email-masked]><mailto:[email-masked]>; Rodney W. Grimes <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [tcpm] [tsvwg] L4S status tracking

--

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Mon, 11 Nov 2019 18:09:25 -0800 (PST)

> OK, so we seem to make some progress at least regarding the term 'classic' TCP. As mentioned before, I personally would find the term 'Classic' QUIC very confusing and you cannot avoid that if you…

As a slight point, 'Classic' is not defined standalone in the terminology.  I think that is also a partial cause of problems here.

> Regarding congestion control, I'd like to emphasize that David's proposal would also work well for me, i.e., characterizing the congestion control by functional properties. This avoids all issues r…

This also works for me.

> .... and just to show that _my_ concern would be trivial to address by small editorial changes:
> 
> To: Scharf, Michael <[email-masked]><mailto:[email-masked]>; Bob Briscoe <[email-masked]><mailto:[email-masked]>; Rodney W. Grimes <[email-masked]><mailto:[email-masked]..net>

---

From: Pete Heist <[email-masked]>
Date: Tue, 12 Nov 2019 10:10:59 +0100

> On Nov 11, 2019, at 10:51 PM, Greg White <[email-masked]> wrote:
> 

Yes, I think that’s what’s happening. This would likely be solved by RFC 3168 bottleneck detection and transitioning to a compatible response. We usually use the term “standard” here as opposed to “sluggish”, but that reveals the two perspectives. :)

> *in my defense the flent plots aren't the friendliest for color-deficient viewers.

This can happen to me as well with green vs teal. I’ll see if we can’t improve that a bit.

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 13 Nov 2019 09:47:59 +0000

Sebastian,

I am very much arguing in good faith about the term 'Classic', because I 
care about the comprehensibility and correctness of RFCs. So I am always 
willing to change text (or technology) in the face of successfully 
argued reasoned constructive criticism.

In order to keep each thread to its topic, I'll respond on that thread 
to the points about flow rates (unless others have already made the 
points I would make). {Note 1}

It is not pretentious for an experiment to state what it aims to achieve 
in its specification. That is how everyone writes and reads experimental 
specs. I can certainly say that L4S is ambitious. But that is a feature, 
not a bug, and it was well-understood when the work was adopted onto the 
experimental track. It will only have been pretentious if it eventually 
fails to deliver on its promises. Nonetheless, when problems are found, 
there should be a presumption that the proponents might be able to fix 
them, and space should be allowed for that process.

Regards

Bob

{Note 1}: These mailing lists are for co-ordinating a large amount of WG 
work. Please yourself try not to merely repeat the arguments of others 
when posting (unless the chairs have asked for a consensus call). Rough 
consensus requires every substantive objection to be addressed. So 
're-tweeting' just leaves everyone less time for technical progress.

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 13 Nov 2019 10:00:04 +0000

Michael,

I see the problem. Nearly all the occurrences of 'Classic TCP' are in 
the appendix that was written v early on, when the focus was only TCP. 
That text was not written by me, and I haven't got round to editing it 
for consistency. However, there are 4 occurrences of "'Classic' TCP" in 
the abstract and intro, which I will also fix.

Can you say which "David's proposal" you mean please?

Bob

On 11/11/2019 23:10, Scharf, Michael wrote:
>
> OK, so we seem to make some progress at least regarding the term 
> ‚classic‘ TCP. As mentioned before, I personally would find the term 
> ‘Classic’ QUIC very confusing and you cannot avoid that if you talk 
> about ‘Classic’ TCP, IMHO. So, it seems better to avoid that 
> terminology for all transport protocols. For the record, in 
> draft-ietf-tsvwg-ecn-l4s-id-08 the combination of the terms ‘classic’ 
> and ‘TCP’ back-to-back is used 11 times as far as I can see.
>
> Regarding congestion control, I’d like to emphasize that David’s 
> proposal would also work well for me, i.e., characterizing the 
> congestion control by functional properties. This avoids all issues 
> regarding whether something will supersede something else (including 
> the issue that EXP is just an experiment that won’t update or replace 
> any PS document).
>
> Michael
>
> *From:*Bob Briscoe <[email-masked]>
> *Sent:* Monday, November 11, 2019 4:31 PM
> *To:* Scharf, Michael <[email-masked]>; Wesley Eddy 
> <[email-masked]>; Rodney W. Grimes <[email-masked]>
>     … and just to show that _/my/_ concern would be trivial to address
>     by small editorial changes:
>
>     For the abstract of draft-ietf-tsvwg-ecn-l4s-id, the wording “It
>     gives an incremental migration path so that normal TCP traffic
>     classified in the ‘Classic’ service of L4S will be no worse off”
>     would already work for me.  It just takes a small editorial change
>     to make me happy. This can’t be so hard.
>
>     service class (and, e.g., “normal” sounds better to me), but in
>     the context of a service class, “classic” could actually work for
>     me, if TSVWG really wants that name with strong consensus. I don’t
>     care how about names for DiffSe^D^D^D^D^D^D traffic classifiers,
>     traffic policers/shapers, AQM schemes, or whatever else is done in
>     the fast path of a router to implement low latency service.
>
>     ‘Classic’ congestion control because I don’t think that ‘classic’
>     is a proper characterization for TCPM standards or TCP/IP stack
>     behavior not aligned with whatever L4S believes the bright future
>     shall be.
>
>     *From:*Wesley Eddy <[email-masked]> <mailto:[email-masked]>
>     *To:* Scharf, Michael <[email-masked]>
>     <mailto:[email-masked]>; Bob Briscoe
>     <[email-masked]> <mailto:[email-masked]>; Rodney W.
>     Grimes <[email-masked]> <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>         migration path so that existing 'Classic' TCP traffic will be
>         no worse off”
>
>         fine with the term “Classic” for TCP and TCPM-specified
>         congestion control when more than 50% of Internet traffic uses
>         that new technology.
>
>         removed in all context of TCP and congestion control (as far
>         as it is owned by TCPM), including the reference above. BTW,
>         “normal” as suggested would also work for me. So, you have
>         plenty of options for other terms.
>
>     If Dave+Michael's suggestion of replacing "classic" with "normal"
>     is agreable to others, this seems like a good way forward to me. 
>     It should be easy enough to explain in other SDOs that classic and
>     normal mean the same thing, if this is a real issue.
>
>     (FWIW, I've never had a problem myself with "classic", nor read
>     any negative connotations to it.  However, for the sake of working
>     group progress, I think we just need to pick something that seems
>     the least terrible and agree to move on.)
>
>
>
> --

---

From: "Scharf, Michael" <[email-masked]>
Date: Wed, 13 Nov 2019 11:12:21 +0000

I was referring to this statement from David Black:

<snip>
</snip>

Instead of using equations, one could also define two acronyms to make it more handy. I am pretty open to different variants.

To me, a key advantage of this approach is that it would be a technically neutral (mathematical) description of behavior that should not be controversial. At least to me, this would work well.

Michael

Sent: Wednesday, November 13, 2019 11:00 AM

Michael,

I see the problem. Nearly all the occurrences of 'Classic TCP' are in the appendix that was written v early on, when the focus was only TCP. That text was not written by me, and I haven't got round to editing it for consistency. However, there are 4 occurrences of "'Classic' TCP" in the abstract and intro, which I will also fix.

Bob

Michael

From: Bob Briscoe <[email-masked]><mailto:[email-masked]>
Sent: Monday, November 11, 2019 4:31 PM
To: Scharf, Michael <[email-masked]><mailto:[email-masked]>; Wesley Eddy <[email-masked]><mailto:[email-masked]>; Rodney W. Grimes <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [tcpm] [tsvwg] L4S status tracking

Michael,

Bob

Michael

--

--