Subject: [tsvwg] Ingemar Johansson's position on ECT(1)

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 27 Apr 2020 12:05:39 +0000

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]

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

=================================