Subject: [tsvwg] A word for "does not have a significantly negative impact on traffic using standard congestion control"?

From: Bob Briscoe <[email-masked]>
Date: Tue, 9 Mar 2021 01:19:12 +0000

tsvwg-ers,

In the survey of the L4S Prague Requirements, we got quite significant 
push-back from developers about our two requirements to fall back to 
Reno-Friendly (which the draft defines as a translation of 
'TCP-Friendly' into transport-agnostic language, 'cos TCP isn't the only 
transport these days).

Basically, people don't want to have to fall back to something as lame a 
Reno (apologies if that's disparaging, but I'm just the messenger).

I was hoping people would interpret 'Reno-Friendly' liberally. But 
everyone takes Reno-Friendly to mean quite close to Reno behaviour - not 
surprising really, given the definition of TCP-Friendly in TFRC is 
roughly within 2x of Reno [RFC5348] (pasted at the end).

What I'm looking for is a word that means "does not have a significantly 
negative impact on traffic using standard congestion control", which
RFC5033 allows for experimental congestion controls.

==Details from the RFCs==

RFCRFC2914 (borrowing from RFC2309) defines TCP-compatible to mean the 
same behaviour as Reno (essentially).

RFC5348 defines the term TCP-Friendly, which was originally intended for 
real-time media - to allow the rate to temporarily stray from 
TCP-compatible because it needed to remain more stable as available 
capacity varied. But it was also used for regular elastic congestion 
controls like Cubic. Here's the TFRC definition.

    TFRC is designed to be reasonably fair when competing for bandwidth
    with TCP flows, where we call a flow "reasonably fair" if its sending
    rate is generally within a factor of two of the sending rate of a TCP
    flow under the same conditions.  However, TFRC has a much lower
    variation of throughput over time compared with TCP, which makes it
    more suitable for applications such as telephony or streaming media
    where a relatively smooth sending rate is of importance.

In RFC5033, Sally Floyd wrote this, which is a useful turn of phrase. 
I'd just like to find a shorter way of saying it:

        Alternate congestion controllers that have a
        significantly negative impact on traffic using standard
        congestion control may be suspect

Bob

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

---

From: Neal Cardwell <[email-masked]>
Date: Mon, 8 Mar 2021 21:35:32 -0500

On Mon, Mar 8, 2021, 8:19 PM Bob Briscoe <[email-masked]> wrote:

> Reno-Friendly (which the draft defines as a translation of 'TCP-Friendly'
> into transport-agnostic language, 'cos TCP isn't the only transport these
> days).
>
> surprising really, given the definition of TCP-Friendly in TFRC is roughly
> within 2x of Reno [RFC5348] (pasted at the end).
>

Reno-considerate?

Reno-accommodating?

neal

---

From: Ian Swett <[email-masked]>
Date: Mon, 8 Mar 2021 21:54:36 -0500

Thanks for moving beyond 'TCP-Friendly'.

My best suggestion is 'fLow-Impact'

I'd also be hesitant to put Reno in the name, but I think a name like
Reno-compatible/considerate/accommodating is ok if the term is still
anchored on Reno in some way.

The goal of this new term is to depart slightly from the traditional
definition of 'TCP-friendly', correct?  ie: If there's an environment(ie:
High-BDP with exogenous random loss) where Reno can only utilize 1% of the
bandwidth, and another congestion controller can utilize the other 99%
without significantly changing Reno's bandwidth, that would not be
'TCP-Friendly', but would be '<new term>'?

Thanks, Ian

---

From: Jonathan Morton <[email-masked]>
Date: Tue, 9 Mar 2021 12:46:25 +0200

> On 9 Mar, 2021, at 3:19 am, Bob Briscoe <[email-masked]> wrote:
> 
> In the survey of the L4S Prague Requirements, we got quite significant push-back from developers about our two requirements to fall back to Reno-Friendly (which the draft defines as a translation of 'TCP-Friendly' into transport-agnostic language, 'cos TCP isn't the only transport these days).
> 
> Basically, people don't want to have to fall back to something as lame a Reno (apologies if that's disparaging, but I'm just the messenger).
> 
> I was hoping people would interpret 'Reno-Friendly' liberally. But everyone takes Reno-Friendly to mean quite close to Reno behaviour - not surprising really, given the definition of TCP-Friendly in TFRC is roughly within 2x of Reno [RFC5348] (pasted at the end).
> 
> What I'm looking for is a word that means "does not have a significantly negative impact on traffic using standard congestion control", which 

"Compliant with RFC-8511" should do the trick.

 - Jonathan Morton

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 9 Mar 2021 23:11:18 +0000

Ian,

On 09/03/2021 02:54, Ian Swett wrote:
> definition of 'TCP-friendly', correct?  ie: If there's an 
> environment(ie: High-BDP with exogenous random loss) where Reno can 
> only utilize 1% of the bandwidth, and another congestion controller 
> can utilize the other 99% without significantly changing Reno's 
> bandwidth, that would not be 'TCP-Friendly', but would be '<new term>'?

I think the concept of using what Reno can't has been around for some time.
I was looking for something more than that.
Something that's not as sensitive to single losses as Reno. Which means 
it could push Reno down (somewhat more than say Cubic in Reno mode 
would), but not "significantly".

Bob

>
> Thanks, Ian
>
> On Mon, Mar 8, 2021 at 9:35 PM Neal Cardwell 
> <ncardwell=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Mon, Mar 8, 2021, 8:19 PM Bob Briscoe <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         tsvwg-ers,
>
>         In the survey of the L4S Prague Requirements, we got quite
>         significant push-back from developers about our two
>         requirements to fall back to Reno-Friendly (which the draft
>         defines as a translation of 'TCP-Friendly' into
>         transport-agnostic language, 'cos TCP isn't the only transport
>         these days).
>
>         Basically, people don't want to have to fall back to something
>         as lame a Reno (apologies if that's disparaging, but I'm just
>         the messenger).
>
>         I was hoping people would interpret 'Reno-Friendly' liberally.
>         But everyone takes Reno-Friendly to mean quite close to Reno
>         behaviour - not surprising really, given the definition of
>         TCP-Friendly in TFRC is roughly within 2x of Reno [RFC5348]
>         (pasted at the end).
>
>         What I'm looking for is a word that means "does not have a
>         congestion control", which

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 9 Mar 2021 23:19:18 +0000

Neal,

On 09/03/2021 02:35, Neal Cardwell wrote:
>     significant push-back from developers about our two requirements
>     to fall back to Reno-Friendly (which the draft defines as a
>     translation of 'TCP-Friendly' into transport-agnostic language,
>     'cos TCP isn't the only transport these days).
>
>     Basically, people don't want to have to fall back to something as
>     lame a Reno (apologies if that's disparaging, but I'm just the
>     messenger).
>
>     everyone takes Reno-Friendly to mean quite close to Reno behaviour
>     - not surprising really, given the definition of TCP-Friendly in
>     TFRC is roughly within 2x of Reno [RFC5348] (pasted at the end).
>
>     significantly negative impact on traffic using standard congestion
>     control", which

This one is getting closer.

Bob

---

From: Ian Swett <[email-masked]>
Date: Tue, 9 Mar 2021 22:45:43 -0500

Thanks Bob, I just wanted to confirm.

I prefer Reno-compatible over considerate or accommodating, but I'm open to
other terms.  Also, I believe Neal used the term Reno-compatible first in
the context of BBRv2 gain cycling, but I could be wrong.

Thanks, Ian

---

From: Sebastian Moeller <[email-masked]>
Date: Wed, 10 Mar 2021 09:27:43 +0100

Dear All,

while I appreciate the attempt to strive for better nomenclature, I think here it is best to stick to the existing terms. Sure add a paragraph that explicitly spells out what it exactly means, but do not muddy the water with slightly different terms. Also, be as accurate and descriptive as possible.

The argument that there are more protocols than TCP is a rather weak one, becauseIMHO " TCP-friendly" really just conveys that all internet-wide congestion response should strive to not harm TCP (still being one of the major traffic types in the net). Also this needs a strict definition of harm, so that congestion responses can be tested against this requirements and simply judged friendly or non-friendly.

Bob later hints at a similar thought with:
"Something that's not as sensitive to single losses as Reno. Which means it could push Reno down (somewhat more than say Cubic in Reno mode would), but not "significantly"."

But IMHO this is a slippery slope (the scare quotes around significantly indicate a non-objective assessment), so please define the amount of harm that is permissible. And also, if that boils down to "do not starve" add an explicit definition of starvation that can be used in a statistical test, the old "I know starvation when I see it" definition is clearly in the eye of the beholder and hence pretty useless for designing and testing CC algorithms against.

With all that said, how about something along the lines of:

New congestion control algorithms, will share the internet with existing CCs for the foreseeable future, and hence need to c o-exist peacefully with existing CCs. Given TCP's importance in the early internet(?) such behaviour has been called TCP-friendly, and boils down to that new CCs do not do more harm to existing CC-flows than such existing flows would do to each other. In addition to the "no more harm" principle new CCs should also avoid driving other TCP-friendly flows into starvation. In this context starvation means a reduction of a flows capacity share, below 1/8 (3 orders of magnitude) its equitable capacity share if no new-CC flows would be present.

IMHO that captures the gist of the issue:
1) do no harm: is a concise phrasing of "does not have a significantly negative impact"
2) giving a definition of clearly acceptable harm (what TCP-friendly CCs already inflict on each other). 
3) tackles the so far under defined starvation issue heads on by giving a definition of starvation that can be empirically confirmed during tests
4) uses a reference rate for the starvation calculation that effortlessly allows for prioritization and selective shaping on each node where the sharing behaviour is explored.
5) by having a numerical definition of starvation and of the reference sharing behaviour, it becomes possible to statistically test whether the new CC significantly harms existing TCP-friendly traffic or not (getting rid of the subjective components of "significantly").

This blurb clearly is not perfect, but IMHO worth discussing.

Best Regards
	Sebastian

> On Mar 9, 2021, at 02:19, Bob Briscoe <[email-masked]> wrote:
> 
> tsvwg-ers,
> 
> RFCRFC2914 (borrowing from RFC2309) defines TCP-compatible to mean the same behaviour as Reno (essentially).
> 
> RFC5348 defines the term TCP-Friendly, which was originally intended for real-time media - to allow the rate to temporarily stray from TCP-compatible because it needed to remain more stable as available capacity varied. But it was also used for regular elastic congestion controls like Cubic. Here's the TFRC definition.
> 
> In RFC5033, Sally Floyd wrote this, which is a useful turn of phrase. I'd just like to find a shorter way of saying it:
>

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 10 Mar 2021 14:05:30 +0000

Sebasitan

> New congestion control algorithms, will share the internet with existing CCs for the foreseeable future, and hence need to c o-exist peacefully with existing CCs. Given TCP's importance in the earl…

[BB] (I assume you mean 'Reno' here, each time you say 'TCP'.)

Whatever, the question was looking for a word that describes more harm 
than none.
We saw in the survey at the last Nov '20 ICCRG that Reno is becoming a 
small minority. I suspect this is because it's over-sensitive to noise 
that often isn't really congestion (accepting that it's hard for any CC 
to know what caused a loss).

We're looking for a way to describe the congestion controls that do 
actually do some harm to such "over-sensitive" congestion controls, but 
not significant harm.

> 1) do no harm: is a concise phrasing of "does not have a significantly negative impact"

[BB] That would be "do no significant harm", as explained above.

> 5) by having a numerical definition of starvation and of the reference sharing behaviour, it becomes possible to statistically test whether the new CC significantly harms existing TCP-friendly traf…

[BB] I'd like to work on this.

I believe the problem is similar to relative poverty. It depends on some 
notion of average (long-running, capacity-seeking) flow rate in a 
deployment environment, not solely the other rates in one bottleneck.

Bob

---

From: Sebastian Moeller <[email-masked]>
Date: Wed, 10 Mar 2021 16:02:42 +0100

Hi Bob,

more below inline, prefixed [SM].

> On Mar 10, 2021, at 15:05, Bob Briscoe <[email-masked]> wrote:
> 
> Sebasitan
> 

	[SM] Yes and no, I argue more that to achieve acceptable levels of sharing all CC's depoyed in the internet need to be compatible towards each other such that none outcompetes the others. Sure, Reno was probably the single TCP variant that left most impression on how TCP-friendly behaviour looks like, but as you experienced, naming it Reno-friendly got immediate opposition, while keeping TCP-friendly would not have done the same (my hypothesis) by virtue of being established nomenclature. 

> 
> Whatever, the question was looking for a word that describes more harm than none.

	[SM] IMHO we need more than a word, we need something that is empirically testable. "None" is easy: if we find no statistical significant* effect of the new CC on existing CC's as compared to the effect of the old CC on itself, we are done, "no significant change automatically means no harm". If we want something else then "none", let's make it explicit and define it by numbers. Once we agree to numbers the words should come easy, like "mild harm", or "some harm" (but without precise definitions these words alone are pretty useless).

*) You still need to define your acceptable false positive and false negative rates...

> We saw in the survey at the last Nov '20 ICCRG that Reno is becoming a small minority. I suspect this is because it's over-sensitive to noise that often isn't really congestion (accepting that it's hard for any CC to know what caused a loss).

	[SM] I am not proposing to "enshrine" Reno's behavior for eternity here, but rather the dominant "TCP's" behaviour. The point is, every new protocol needs to understand what CC reference it needs to be compatible with. The exact definition of the reference behaviour probably can be discussed and might be open to gentle evolution to keep in sync with what is actually deployed in the internet. But as I see it, this evolution needs to be slow and compliance needs to be easily testable, so we want as precise a definition of the desired behavior as we can agree on.

> 
> We're looking for a way to describe the congestion controls that do actually do some harm to such "over-sensitive" congestion controls, but not significant harm.

	[SM] Well, then lay out a) how much harm you deem acceptable (the list will haggle over the numbers, but in the end something verifiable needs to come out) and b) how to assess harm. This needs to be exquisitely clear, because otherwise it is doomed to abuse, no?

> [BB] That would be "do no significant harm", as explained above.

	[SM] That depends on how you interpret/use significant in that sentence. 

> I believe the problem is similar to relative poverty. It depends on some notion of average (long-running, capacity-seeking) flow rate in a deployment environment, not solely the other rates in one bottleneck.

	[SM] Mmmh, not sure I fully understand and/or agree. Congestion only materializes in bottlenecks (or conversely we simply call the location of congestion the bottleneck), so the relative sharing behaviour of different CCs should be assessed exactly at those bottlenecks. But I guess most likely, I did not get the gist of your last point.

Best Regards
	Sebastian

---

From: Sebastian Moeller <[email-masked]>
Date: Tue, 16 Mar 2021 10:39:27 +0100

Dear All,

in the cited response Bob proposes to define TCP Reno as the reference TCP all TCP-friendly protocols need to be compatible with. I had a quick look at what TCP CCs are actually in use, and according to wikipdia, all major operatig systems, Windows10 (since 1709, 2017), MacOs (since Yosemite, 2014), Linux (since 2.6.19, 2006) converged on CUBIC as the default TCP congestion control algorithm.
Given that data, I propose to not enshrine YCP Reno's behavior as the current applicable reference, but instead TCP CUBIC. 
	For the L4S drafts that does not change much, because the dualQ's unfairness towards non-L4S-CCs does not seem to care for the exact way a CC is NOT L4S, (and related, but not totally on topic: TCP Pragues abysmal (self)-fairness in FIFO buffers is also independent of the exact nature of the competing CC). That is to say, L4S fails to meet its promises on both fronts, the network bits and the protocol bits are not fit for purpose (neither in safety nor functionality).

Best Regards
	Sebastian

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 16 Mar 2021 12:14:39 +0000

On 16/03/2021 09:39, Sebastian Moeller wrote:
> 	For the L4S drafts that does not change much, because the dualQ's unfairness towards non-L4S-CCs does not seem to care for the exact way a CC is NOT L4S,
<snip>
> 	Sebastian

This seems an editorial matter that we should simply get correct. The 
IETF has a PS specification for Reno. RFC 8312 is informational, but 
TCPM recently adopted draft-ietf-tcpm-rfc8312bis-00, targeting 
Informational status.

My own (personal) suggestion is that we use text that says a "CC 
specified in a standard's track RFC" and give refs to both Reno and 
Cubic as examples, although I'd be interested in others views also.

Gorry

---

From: Lloyd W <[email-masked]>
Date: Fri, 19 Mar 2021 08:45:48 +1100

What does 'well-behaved' mean in a congestion control context? 
(Hmmm, 3con there for that)

We could write something updatable by later RFCs defining what well-behaved means, describing how it means no significant negative impact, allows
coexistence with Reno and TCP Friendly flows, and we're done. Nuance can be
in the RFC.

Testing has shown that our experimental protocol's performance under
congestion is well-behaved, matching the definition of well-behaved in RFCxxxx

I don't think we should hang Reno or TCP around our necks in the term. (Reno is an
example implementation of TCP, and imo even more specific and not transport
 agnostic)

Lloyd Wood
[email-masked]

> On 10 Mar 2021, at 10:19, Bob Briscoe <[email-masked]> wrote:
> 
>  Neal,
>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 22 Mar 2021 14:51:24 +0000

Gorry,

In my original question on this thread, this wasn't about which TCP to 
compare against (when Sebastian said that, I didn't correct him). My 
original question was about how to describe the fall back behaviour in 
response to a loss. The draft currently says:

       ...a scalable congestion
       control MUST react to packet loss in a way that will coexist
       safely with a TCP Reno congestion control [RFC5681  <https://datatracker.ietf.org/doc/html/rfc5681>] (see
       Section 1.2  <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-14#section-1.2>  on Terminology for definition of Reno-Friendly and
       Appendix A.1.3  <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-14#appendix-A.1.3>  for rationale)

When I wrote that I had no intention of it meaning "Fall back to Reno." 
I had in mind that Cubic is considered Reno-Friendly, so I had figured 
that choice of words would not preclude falling back to something like 
Cubic.

However, a number of survey respondents were concerned that it might 
preclude their favourite congestion response, with less sensitivity to 
loss than Reno. Hence the quest for a clearer form of words.

Bob

On 16/03/2021 12:14, Gorry Fairhurst wrote:
>> in the cited response Bob proposes to define TCP Reno as the 
>> reference TCP all TCP-friendly protocols need to be compatible with. 
>> I had a quick look at what TCP CCs are actually in use, and according 
>> to wikipdia, all major operatig systems, Windows10 (since 1709, 
>> 2017), MacOs (since Yosemite, 2014), Linux (since 2.6.19, 2006) 
>> converged on CUBIC as the default TCP congestion control algorithm.
>> Given that data, I propose to not enshrine YCP Reno's behavior as the 
>> current applicable reference, but instead TCP CUBIC.
>>     For the L4S drafts that does not change much, because the dualQ's 
>> unfairness towards non-L4S-CCs does not seem to care for the exact 
>> way a CC is NOT L4S,
> <snip>
>> Best Regards
>>     Sebastian
>
>

---

From: Martin Duke <[email-masked]>
Date: Fri, 26 Mar 2021 09:44:13 -0700

Gorry,

8312bis is Standards Track.

On Tue, Mar 16, 2021 at 5:15 AM Gorry Fairhurst <[email-masked]>
wrote:

> > in the cited response Bob proposes to define TCP Reno as the reference
> TCP all TCP-friendly protocols need to be compatible with. I had a quick
> look at what TCP CCs are actually in use, and according to wikipdia, all
> major operatig systems, Windows10 (since 1709, 2017), MacOs (since
> Yosemite, 2014), Linux (since 2.6.19, 2006) converged on CUBIC as the
> default TCP congestion control algorithm.
> unfairness towards non-L4S-CCs does not seem to care for the exact way a CC
> is NOT L4S,
> <snip>
> > Best Regards
> >       Sebastian
>
>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 29 Mar 2021 01:43:36 +0100

Martin, Gorry,

The set of CCs that do not have significantly negative impact on traffic 
using standard CC is much broader than the two CCs on the standards track.

For instance, this is needed to describe what an L4S CC is allowed to 
fall-back to in response to loss. We wouldn't want to constrain 
implementers to just the 2 behaviours that happen to have been written 
up as tds track RFCs.

Bob

On 26/03/2021 16:44, Martin Duke wrote:
> On Tue, Mar 16, 2021 at 5:15 AM Gorry Fairhurst <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     reference TCP all TCP-friendly protocols need to be compatible
>     with. I had a quick look at what TCP CCs are actually in use, and
>     according to wikipdia, all major operatig systems, Windows10
>     (since 1709, 2017), MacOs (since Yosemite, 2014), Linux (since
>     2.6.19, 2006) converged on CUBIC as the default TCP congestion
>     control algorithm.
>     > Given that data, I propose to not enshrine YCP Reno's behavior
>     as the current applicable reference, but instead TCP CUBIC.
>     >       For the L4S drafts that does not change much, because the
>     dualQ's unfairness towards non-L4S-CCs does not seem to care for
>     the exact way a CC is NOT L4S,
>     <snip>
>     > Best Regards
>     >       Sebastian
>
>

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 29 Mar 2021 09:33:59 +0200

Bob, list

> On Mar 29, 2021, at 02:43, Bob Briscoe <[email-masked]> wrote:
> 
> Martin, Gorry,
> 
> The set of CCs that do not have significantly negative impact on traffic using standard CC is much broader than the two CCs on the standards track. 
> 
> For instance, this is needed to describe what an L4S CC is allowed to fall-back to in response to loss. We wouldn't want to constrain implementers to just the 2 behaviours that happen to have been written up as tds track RFCs.

	[SM] This is exactly where my argument about the reference TCP becomes relevant. Unless you want to fully enumerate the ever growing set of protocols.CCs that willingly cooperate over the internet, you need are better of with defining a reference behaviour such a CC needs to cooperate/peacefully coexist with. And IMHO taking the dominant TCP's behaviour is a decent starting point, given that TCO is still a very important protocol over the internet. Since this is about coordinating behaviour IMHO the more detailed the description of the reference the better, if a reference implementation exists even better, then one can design against a spec and test against existing implementations.
	And to be clear, this is not an attempt at rephrasing your position, but an attempt to progress the discussion (like the last time around, where just doing it implicitly resulted in you misunderstanding what I was trying to do, sorry for causing that confusion).

Best Regards
	Sebastian

>> On Tue, Mar 16, 2021 at 5:15 AM Gorry Fairhurst <[email-masked]> wrote:

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 29 Mar 2021 10:02:34 +0100

Bob,

Please do propose text - I'd suggest not to solve the problems for the 
non-standards-track CC's: This could be a job for each CC to solve.

Gorry

On 29/03/2021 01:43, Bob Briscoe wrote:
> Martin, Gorry,
>
> The set of CCs that do not have significantly negative impact on 
> traffic using standard CC is much broader than the two CCs on the 
> standards track.
>
> up as stds track RFCs.
> Bob Briscoehttp://bobbriscoe.net/