Subject: [LOOPS] Charter github issue #4: ECN-Only

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Jun 2020 08:46:52 +0200

In charter github issue #4 <https://github.com/loops-wg/charter/issues/4>,
larseggert writes:

»

The current charter says (in the third bullet):

> Initially, LOOPS will focus on the use of ECN for this and therefore only supports ECN-enabled end-to-end flows.

It's not clear if this restriction of LOOPS to ECN-enabled flows only applies to this third bullet (i.e., to the interaction with E2E CC) or whether it applies to all LOOPS work items.

If it's the former, maybe the text could be clarified?

If it's the latter, that restriction of LOOPS to ECN-enabled flows would IMO need to be highlighted more strongly. (And I would wonder if LOOPS is feasible at all, given the deployment realities of ECN.)

«

I think this is mostly an editorial comment; when I wrote that sentence I was thinking that saying something once would be enough, but maybe our choice is indeed too surprising.
There was a clear decision among the proponents to initially support only

— ECN-enabled end-to-end flows, on
- fully ECN-enabled path segments.

Apart from the editorial issue, we also might want to reconfirm this decision in the light of this Github issue.

I think we all agree that this is a bit on the side of skating to where the puck will be.

There is some assumption of end-host cooperation to the level of needing to switch on ECN in order to get the benefits of LOOPS.  Today that is usually a decision that can be taken on the client-side, as servers often are already ECN-enabled; this decision will often be available in enterprise style use cases.  Is this enough to support initial deployment?  I personally think so; after all, LOOPS is not supposed to take over the Internet whole-sale, but to be a tool in the toolkit of a network operator that can be selectively employed.

This focus on ECN is a risky choice.  Now, if it is weaponized as an argument that LOOPS will not be deployable in its initial form, we may have to reconsider that choice.
Also, we don’t know how much the work on accurate ECN (L4S etc.) will remove the impetus to remove the last obstacles to ECN classic.

Grüße, Carsten

---

From: Michael Welzl <[email-masked]>
Date: Thu, 25 Jun 2020 09:25:31 +0200

Hi,

> On Jun 25, 2020, at 8:46 AM, Carsten Bormann <[email-masked]> wrote:
> 
> There is some assumption of end-host cooperation to the level of needing to switch on ECN in order to get the benefits of LOOPS.  Today that is usually a decision that can be taken on the client-side, as servers often are already ECN-enabled; this decision will often be available in enterprise style use cases.  Is this enough to support initial deployment?  I personally think so;

+1; ECN use can mostly be negotiated, and is done so by many clients today. The problem is that hardly any routers set the bit.
Combining the two has the side benefit that LOOPS can also perhaps create an incentive to enable ECN.

> after all, LOOPS is not supposed to take over the Internet whole-sale, but to be a tool in the toolkit of a network operator that can be selectively employed.
> 

We should have a strict policy to never debate ECT(1) on this list.

Cheers,
Michael

---

From: Lars Eggert <[email-masked]>
Date: Thu, 25 Jun 2020 10:36:46 +0300

Hi,

> Combining the two has the side benefit that LOOPS can also perhaps create an incentive to enable ECN.

so maybe I am biased, because I'm in a prolonged discussion with a local ISP (Telia) to convince them to stop bleaching/remarking the ECN bits in their network. (They do the same for the DSCP, but interestingly at different hops... Anyone got a clueful Telia contact?)

It seems that depending on ECN deployment - esp. in the network but even only at the edges - creates a very narrow area of applicability for LOOPS, and one that is unlikely to grow rapidly in the foreseeable future.

(Regarding the edges, the situation for ECN with TCP may be OK, but none of the QUIC stacks that are likely going to see large deployments in the near future unfortunately negotiate ECN, although it is has been part of the spec. So the fraction of ECN-enabled flows may actually decrease with QUIC.)

> We should have a strict policy to never debate ECT(1) on this list.

We should have this policy for ANY list.

Lars

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 30 Jun 2020 10:39:57 +0200

> It seems that depending on ECN deployment - esp. in the network but even only at the edges - creates a very narrow area of applicability for LOOPS, and one that is unlikely to grow rapidly in the f…

Right.  It seems we have missed one use case here: Using LOOPS to convert a drop-based segment to an ECN-marking segment (every loss becomes a CE-marked packet, but the packet is actually there and not being dropped).  The benefits here (if the segment is relatively short) are in lower latency for the detection and recovery.  (There is also a meta-benefit in providing more ECN-marking.)

So this would argue for defining LOOPS for the non-marking segment case as well, maybe specifically ignoring any benefits coming from detecting non-congestive losses as such.

> (Regarding the edges, the situation for ECN with TCP may be OK, but none of the QUIC stacks that are likely going to see large deployments in the near future unfortunately negotiate ECN, although i…

That is indeed rather bad news.  Maybe L4S will change this, but it is not something we will be able to target for a couple of years.

Grüße, Carsten

---

From: Lars Eggert <[email-masked]>
Date: Tue, 30 Jun 2020 11:49:08 +0300

Hi,

> Right.  It seems we have missed one use case here: Using LOOPS to convert a drop-based segment to an ECN-marking segment (every loss becomes a CE-marked packet, but the packet is actually there and…

sorry, I don't get this use case, could you elaborate a bit?

I thought the benefit of LOOPS was to hide any loss on the LOOPS segment from the endpoints, either by local RTX or recovery via FEC. I don't understand where a similar benefit would come from if you just mark (and then strip?) ECN?

> So this would argue for defining LOOPS for the non-marking segment case as well, maybe specifically ignoring any benefits coming from detecting non-congestive losses as such.

I don't get this either, sorry.

Lars

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 30 Jun 2020 10:57:38 +0200

> On 2020-06-30, at 10:49, Lars Eggert <[email-masked]> wrote:
> 
> Signed PGP part
> Hi,
> 

The benefit would be actually getting the packet, fast.
The benefit would not be hiding the loss from the congestion control.

Grüße, Carsten

---

From: Michael Welzl <[email-masked]>
Date: Tue, 30 Jun 2020 11:47:18 +0200

> On Jun 30, 2020, at 10:57 AM, Carsten Bormann <[email-masked]> wrote:
> 
> 
> 

I think that’s a great idea!  E.g., this can reduce head-of-line blocking  (see RFC 8087 for more).

>> I don't get this either, sorry.

+1, this sentence is hard to parse. I do get the first half of it though, and I agree with it: if (and only if) the “real" sender and receiver speak ECN, then (even if the LOOPS segment doesn’t support ECN), a loss + retransmit on the LOOPS segment can be turned into a successfully forwarded packet carrying CE=1 by the LOOPS egress (well, in fact, maybe the ingress would do the CE=1 marking; whatever is more efficient to implement).

Cheers,
Michael