Subject: [tsvwg] Kevin Smith's position on ECT(1)

From: "Smith, Kevin, Vodafone Group" <[email-masked]>
Date: Mon, 27 Apr 2020 14:01:10 +0000

Hi all,

I support ECT(1) as network input (L4S), for the reasons given by Ingemar in his position statement. I have also participated in the work to promote support for L4S in 3GPP (Vodafone already support L4S for fixed network DOCSIS 3.1)

I'd add that the volatility of cellular radio signal strength - which can vary by orders of magnitude in under a second - lends itself better to a network input, since an output risks being stale by the time it is reacted to.

All best,
Kevin

Kevin Smith, Vodafone Group Networks

C2 General
From: tsvwg <[email-masked]> On Behalf Of Ingemar Johansson S
Sent: 27 April 2020 13:06
To: [email-masked]
Cc: Ingemar Johansson S <[email-masked]>
Subject: [tsvwg] Ingemar Johansson's position on ECT(1)

Hi

I support ECT(1) as network input (L4S).

I have followed L4S with great interest since the early days when it was first named Immediate ECN. I (and others) have also done studies on the topic with very promising results and I have also participated in work to promote the use of L4S in 3GPP access. Use cases that can benefit from L4S range from online gaming to AR/VR and remote control.

Given that L4S is a network input signal, it allows us to implement the DualQ approach with the existing bearer framework. , i.e. ECT(1) and CE traffic is mapped to a dedicated bearer, meaning we have a dedicated queue for that traffic.

The ECT(1) as network output (SCE) becomes more problematic. The use of ECT(1) as a network output makes it hard for me to understand how the packets with different ECN bits markings should be allocated to different bearers.

To take one example realization in a 5G RAN:

* Not-ECT flows : go into one bearer, all clear, no problem

* Packets marked ECT(0), ECT(1), CE go into the other ECN capable

   bearer that has the ability to remark ECT(0) to ECT(1) at "Some congestion

   experienced"   and remark ECT(0) or ECT(1) to CE at "much congestion"

Now suppose that two flows run in the ECN capable bearer, one understands SCE while the other only understands RFC3168. The RFC3168 flow will mercilessly drive the queue up to the point where CE marking happens, which means that the SCE flow

will experience the same queue delay, and likely starve. To solve this problem it will become necessary to allocate the SCE flow to a

separate bearer but then one need additional flow classification based on 5-tuples or something else.

With the network input alternative (L4S) it is not a must to have this additional flow classification. It is of course an option if one want it but not necessary.

And then two other discussion topics:

Firstly, there is talk about using separate DSCPs for L4S traffic, and while that is of course a possibility and likely for instance for premium services and industrial use cases, I don't want to see that as a MUST. L4S is technology is beneficial for OTT traffic as well. Mandating separate DSCP for L4S will limit the use to confined domains.

Secondly, network jitter is brought forward as a problem for L4S, fair enough. But we must see L4S as a tool to meet todays and especially tomorrows demands on network capabilities. It is a mistake to devise tomorrows technology based on snapshots of today's network artifacts. I cannot speak for other access technology, but 3GPP access, especially NR, has a whole smorgasbord of network features that can be used to reduce network jitter, and implementation and tuning of these should happen in parallel with features like L4S that seek to

reduce queue delay jitter. Delays in networks is a not a one shoe fits all problem.

Regards

Ingemar

================================
Ingemar Johansson  M.Sc.
Master Researcher

Ericsson Research
RESEARCHER
GFTL ER NAP NCM Netw Proto & E2E Perf
Labratoriegränd 11
977 53, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]<mailto:[email-masked]>
www.ericsson.com<http://www.ericsson.com>

  Isn't it nice to think that tomorrow is a
    new day with no mistakes in it yet?
                   L.M. Montgomery
=================================

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 27 Apr 2020 16:10:31 +0200

Hi Kevin,

> On Apr 27, 2020, at 16:01, Smith, Kevin, Vodafone Group <[email-masked]> wrote:
> 
> Hi all,
>  
> I’d add that the volatility of cellular radio signal strength – which can vary by orders of magnitude in under a second – lends itself better to a network input, since an output risks being stale by the time it is reacted to.

	[SM] Is that not an argument against high fidelity congestion feedback in general? In the end ECT(1) is input will still be used to generate CE-outputs...

Best 
	Sebastian

> Firstly, there is talk about using separate DSCPs for L4S traffic, and while that is of course a possibility and likely for instance for premium services and industrial use cases, I don’t want to see that as a MUST. L4S is technology is beneficial for OTT traffic as well. Mandating separate DSCP for L4S will limit the use to confined domains.
>  
> [email-masked]
> www.ericsson.com
>