Subject: [LOOPS] How important is congestion detection

From: Carsten Bormann <[email-masked]>
Date: Mon, 22 Jul 2019 17:11:07 -0400

After the BOF, I had an interesting hallway conversation with Bob Briscoe on congestion feedback signaling, and about congestion detection (i.e., grouping losses into non-congestive and congestive).

One assumption behind the solutions strawman draft was that it is a valid approach to signal loss events that occur inside the path segment, as CE markings to the end hosts.  Bob pointed out that some end host implementations today interpret CE as definite congestion events, while applying congestion detection to loss signals, so this conversion might be counterproductive.  Congestion detection is then a necessary component of a LOOPS implementation, in order not to be worse than the congestion detection employed by the end hosts.

Congestion detection does not need to be standardized (we probably do want to have a BCP or two at some point, though), so that would not be a theoretical roadblock.

But would it be, in a practical sense?  Do we expect congestion detection along a full path (as Stuart Card said today, against the composition of the statistical behaviors of multiple segments) to be better than in a LOOPS implementation looking at a single path segment?

Grüße, Carsten

---

From: Michael Welzl <[email-masked]>
Date: Mon, 22 Jul 2019 17:34:08 -0400

Hi,

I can’t parse this:

> On Jul 22, 2019, at 5:11 PM, Carsten Bormann <[email-masked]> wrote:
> 
> One assumption behind the solutions strawman draft was that it is a valid approach to signal loss events that occur inside the path segment, as CE markings to the end hosts.  Bob pointed out that some end host implementations today interpret CE as definite congestion events, while applying congestion detection to loss signals, so this conversion might be counterproductive.

The last sentence - I don't understand it (“interpret CE as definite… while applying detection to loss” - huh?). What does it mean? Or, maybe: what’s the issue here?
Trying to guess: is it that this would incur a double-reaction?  That would be a strange implementation indeed, if that would happen within the same RTT - but: I thought the whole point is to signal CE *as a replacement* for the loss that LOOPS repairs. So, then… ?

Cheers,
Michael

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 22 Jul 2019 18:17:06 -0400

Sorry for typing a message from a heated BOF where I was representing a WG that needs a specific outcome…

>>  Bob pointed out that some end host implementations today interpret CE as definite congestion events, while applying congestion detection to loss signals, so this conversion might be counterproductive.
> 

What I think Bob meant: An end-host noticing a loss might make its own determination (a.k.a. congestion detection) whether that is a reason to slow down or not.
An end-host getting a CE might simply assume this is indeed congestion, and always slow down.  So, CE > loss, and a simple replacement of loss by CE worsens throughput.

>  I thought the whole point is to signal CE *as a replacement* for the loss that LOOPS repairs. So, then… ?

If CE > loss, replacing loss by CE is not enough, we need to vet the losses via a LOOPS-side congestion detection that is as good as the one as the end-host would do, or (preferably) better.

Grüße, Carsten

---

From: Michael Welzl <[email-masked]>
Date: Mon, 22 Jul 2019 18:51:39 -0400

> On Jul 22, 2019, at 6:17 PM, Carsten Bormann <[email-masked]> wrote:
> 

> If CE > loss, replacing loss by CE is not enough, we need to vet the losses via a LOOPS-side congestion detection that is as good as the one as the end-host would do, or (preferably) better.

RFC 3168 says CE = loss. RFC 8311 finally allows us to diverge from this rule, which we used in RFC to state: “CE < loss”.
L4S of course also does “CE < loss”, albeit in much more elaborate ways.

However: "CE > loss” is truly weird to me - perhaps this IS now allowed by RFC 8311  :-D    but if it’s spec’ed then it must be an April 1 RFC.

What am I missing, Bob?

Cheers,
Michael

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 23 Jul 2019 10:45:11 -0400

FWIW,

On Mon, Jul 22, 2019 at 6:51 PM Michael Welzl <[email-masked]> wrote:

> >>> Bob pointed out that some end host implementations today interpret CE
> as definite congestion events, while applying congestion detection to loss
> signals, so this conversion might be counterproductive.
> >>
> >> The last sentence - I don't understand it (“interpret CE as definite…
> while applying detection to loss” - huh?). What does it mean? Or, maybe:
> what’s the issue here?
> >
> > What I think Bob meant: An end-host noticing a loss might make its own
> determination (a.k.a. congestion detection) whether that is a reason to
> slow down or not.
> > An end-host getting a CE might simply assume this is indeed congestion,
> and always slow down.  So, CE > loss, and a simple replacement of loss by
> CE worsens throughput.
>
> Ok, thanks!  now I understand that the statement is indeed what I thought,
> but it still makes zero sense to me. See below:
>
>
> > If CE > loss, replacing loss by CE is not enough, we need to vet the
> losses via a LOOPS-side congestion detection that is as good as the one as
> the end-host would do, or (preferably) better.
>
> RFC 3168 says CE = loss. RFC 8311 finally allows us to diverge from this
> rule, which we used in RFC to state: “CE < loss”.
> However: "CE > loss” is truly weird to me - perhaps this IS now allowed by
> RFC 8311  :-D    but if it’s spec’ed then it must be an April 1 RFC.
>
> What am I missing, Bob?
>

I was hoping CE > loss was a typo, myself.

Spencer

>
> Cheers,
> Michael
>
> --
> LOOPS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/loops
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 30 Jul 2019 12:14:38 +0200

BRR is ignoring loss (up to some % of loss rate) while it will always react to CE.

> On 23. Jul 2019, at 16:45, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> FWIW, 
>

---

From: Michael Welzl <[email-masked]>
Date: Tue, 30 Jul 2019 22:29:11 +0200

Yes, and I hope less so with every version.
I also hope that we don’t have to design the Internet around BBR now.

Sent from my iPhone

> On 30 Jul 2019, at 12:14, Mirja Kuehlewind <[email-masked]> wrote:
>