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

From: Liyizhou <[email-masked]>
Date: Wed, 1 Jul 2020 07:51:12 +0000

Hi,

RFC 8087 is great source to know. Thank you, Michael.

The proposed charter says:

"(which typically requires all routes on the path segment to be ECN-enabled)"

From my understanding on the discussion, 
would replacing "typically" with "preferably" reasonable?

For non-fully ECN segment, a simple strategy of converting loss signal to ECN can be used (ingress or egress TBD).
For fully ECN segment, more strategic CE marking could be used.

Regards,
Yizhou

-----Original Message-----
From: LOOPS [mailto:[email-masked]] On Behalf Of Michael Welzl
Sent: Tuesday, June 30, 2020 5:47 PM
To: Carsten Bormann <[email-masked]>
Cc: Lars Eggert <[email-masked]>; loops <[email-masked]>
Subject: Re: [LOOPS] Charter github issue #4: ECN-Only

> On Jun 30, 2020, at 10:57 AM, Carsten Bormann <[email-masked]> wrote:
> 
> 
> 
>> On 2020-06-30, at 10:49, Lars Eggert <[email-masked]> wrote:
>> 
>> Signed PGP part
>> Hi,
>> 
>> On 2020-6-30, at 11:39, Carsten Bormann <[email-masked]> wrote:
>>> 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.)
>> 
>> 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?
> 
> The benefit would be actually getting the packet, fast.
> The benefit would not be hiding the loss from the congestion control.

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

> 
> Grüße, Carsten
> 
> 
>>> 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.

+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

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

---

From: Michael Welzl <[email-masked]>
Date: Wed, 1 Jul 2020 09:58:49 +0200

Hi!

> On Jul 1, 2020, at 9:51 AM, Liyizhou <[email-masked]> wrote:
> 
> Hi,
> 

No, I think we should replace:

***
Initially, LOOPS will focus on path segments that do not include either end host, and where the primary congestion signaling method is ECN (which typically requires all routes on the path segment to be ECN-enabled). 
***

with:

***
Initially, LOOPS will focus on path segments that do not include either end host.
***

I am getting quite excited about this “loss to ECN conversion” idea. Right now, the lack of routers that really do apply ECN marking is the missing piece in ECN deployment - so this opens a new option for gradual deployment of ECN, where path segments containing non-ECN-enabled routers can be changed into actually providing that signal without even touching the routers in that segment.

> For non-fully ECN segment, a simple strategy of converting loss signal to ECN can be used (ingress or egress TBD).

Yes.

> For fully ECN segment, more strategic CE marking could be used.

I don’t understand this; what would such “more strategic CE marking” be?

Cheers,
Michael

---

From: Liyizhou <[email-masked]>
Date: Wed, 1 Jul 2020 08:19:03 +0000

Please see [yz] inline.

-----Original Message-----
From: Michael Welzl [mailto:[email-masked]] 
Sent: Wednesday, July 1, 2020 3:59 PM
To: Liyizhou <[email-masked]>
Cc: Carsten Bormann <[email-masked]>; Lars Eggert <[email-masked]>; loops <[email-masked]>
Subject: Re: [LOOPS] Charter github issue #4: ECN-Only

Hi!

> From my understanding on the discussion, would replacing "typically" 
> with "preferably" reasonable?

***

with:

***

[yz] Agreed.

Yes.

[yz] If we know all routers are ECN-enabled along the path segment, we know that they won’t use packet dropping as a congestion signal, except in heavy overload situations (in which we already should have plenty CE-marked packets).  So we have a simple heuristic for distinguishing non-congestion from congestion losses. LOOPS egress need not set CE for non-congestion loss.

Cheers,
Michael

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 1 Jul 2020 11:14:41 +0200

On 2020-07-01, at 09:58, Michael Welzl <[email-masked]> wrote:
> 
> I am getting quite excited about this “loss to ECN conversion” idea.

I call it “drop-to-mark” conversion...

> Right now, the lack of routers that really do apply ECN marking is the missing piece in ECN deployment - so this opens a new option for gradual deployment of ECN, where path segments containing non-ECN-enabled routers can be changed into actually providing that signal without even touching the routers in that segment.
> 
> 

I was thinking in terms of separate use cases (fully ECN-enabled segment vs. drop-to-mark conversion), but indeed, this is a continuum.

> I don’t understand this; what would such “more strategic CE marking” be?

Example: Instead of exporting exactly the marks that we see (or recover from loss and then mark), the egress could run a equation-based congestion control scheme for the segment and the inverse of that for marking at egress.

This is the “unilateral” part that I was referring to in a previous message.
As with any equation-based scheme, this slows down the end-to-end congestion response, but then it runs on a faster timescale (the segment RTT), so that effect could be limited.  Lars would rightly ask for some research on this, first, but if that pans out, I think this will be a likely way to run a LOOPS segment.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 1 Jul 2020 11:18:25 +0200

On 2020-06-30, at 11:47, Michael Welzl <[email-masked]> wrote:
> 
> maybe the ingress would do the CE=1 marking

It could, but it would forgo the additional information that it would get from an ECT marking.

(This brings up the question how to translate the N+R measurements you get from sending N original packets and R retransmissions down to N packets forwarded from the egress.  The conservative approach is to CE-mark everything that was retransmitted, as apparently congestion was experienced; this throws away the ECN information received in the retransmitted packets.  But that is intended to be locked down to a small percentage, so maybe it is OK to ignore it.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 5 Jul 2020 18:49:12 +0200

> Initially, LOOPS will focus on path segments that do not include either end host.

This is now PR #7, https://github.com/loops-wg/charter/pull/7 :

Based on the discussion on the list, I removed the restriction to ECN-enabled (all routers) path segments.

This puts us clearly on the "drop-to-mark" use case — ECN marks on the segment will be forwarded, but we also convert drops into marks by marking recovered packets.
This means end-to-end flows will not benefit from fewer congestion events (which would enhance their throughput), but will benefit from quick recovery (which will help reduce latency).

Grüße, Carsten

---

From: wangjl50 <[email-masked]>
Date: Mon, 6 Jul 2020 16:38:41 +0800

Based on the discussion, I think it is reasonable. Thank you

Best regards
Jianglong

From: Carsten Bormann
Date: 2020-07-06 00:49
To: loops

 
 
Grüße, Carsten

---

From: "qinfengwei" <[email-masked]>
Date: Tue, 7 Jul 2020 10:57:56 +0800

Hi all,
	I agree with this idea.

Thanks,
Fengwei Qin

-----邮件原件-----
发件人: LOOPS [mailto:[email-masked]] 代表 Carsten Bormann
发送时间: 2020年7月6日 00:49
收件人: loops
主题: Re: [LOOPS] Charter github issue #4: ECN-Only

Grüße, Carsten