Subject: [tsvwg] Fwd: Qs on your 5G L4S slides

From: Bob Briscoe <[email-masked]>
Date: Wed, 10 Mar 2021 17:41:20 +0000

tsvwg,

Fwd'ing to list, with permission...
In case anyone else had the same questions

-------- Forwarded Message --------
Subject: 	RE: Qs on your 5G L4S slides
Date: 	Wed, 10 Mar 2021 14:33:42 +0000
From: 	Ingemar Johansson S <[email-masked]>
To: 	Bob Briscoe <[email-masked]>
CC: 	Ingemar Johansson S <[email-masked]>

Hi
Please see inline [IJ]

/Ingemar

> -----Original Message-----
> From: Bob Briscoe <[email-masked]>
> Sent: den 10 mars 2021 14:46
> To: Ingemar Johansson S <[email-masked]>
> Subject: Qs on your 5G L4S slides
>
> Ingemar,
>
> #5 "Dedicated bearer / QoS flow for L4S traffic"
> Is this a per-app microflow or a per-user flow?
[IJ] It is per-user flows, i.e each bearer can handle many flows

>
> And I think you'll need to explain where the UPF is typically located. 
> I believe
> it's close to the edge, isn't i?
> Further into the network (beyond the UPF) these flows just become an
> aggregate of all the users.
[IJ] The UPF is close to the edge somehow, it is hard to say for certain 
where they are located, they can be real close to the base stations or 
 >100km away.

>
> #6 Question:
> Do you have any feel for qDelay & throughput if a "Classic ECN AQM" 
> like PIE
> or CoDel was used?
[IJ] No, it was not studied in the master thesis work.

>
> #6 - #11:
> Is the DBS scheduler between users, or between flows?
[IJ] Per user (bearer)

>
> #12: L4S is meant to greatly reduce the throughput-delay tradeoff, and 
> in our
> results it did.
> Any idea why not here? I guess, with video, it's the 'getting up to 
> speed' fast
> problem (that I'm working on with Joakim).
[IJ] One reason is the large variation in frame sizes that video coders 
generate.
Another is that SCReAM paces out the video frames as 50% higher rate 
than the nominal video target bitrate. This pacing overhead can be 
configured lower but then the video frames (RTP packets) are more likely 
to become queued up in the sender instead. I really believe that it can 
be done better, was hoping to have time to improve SCReAM in this 
respect but the work hours fly in other directions .
With that said. Also a DCTCP flow (with L4S) marking will get a reduced 
throughput compared to e.g a Cubic flow (without L4S) over cellular. The 
reason is that the large buffers with Cubic absorb the fast fading dips 
in LTE and NR. With DCTCP + L4S some extra headroom is needed to avoid 
queue build up.

>
>
> Bob
>
> --
> __________________________________________________________
> ______
> Bob Briscoe https://protect2.fireeye.com/v1/url?k=828d3ddc-
> dd1604f1-828d7d47-8692dc8284cb-1ab58b5eb7943901&q=1&e=b0160f51-
> 6418-41ea-9221-efaca6b7cec8&u=http%3A%2F%2Fbobbriscoe.net%2F

---

From: "Smith, Kevin, Vodafone Group" <[email-masked]>
Date: Fri, 12 Mar 2021 13:56:05 +0000

Hi Ingemar,

Just to ask, was there also a variant of the test with no L4S but with the dedicated bearer? I'd be interested to see that comparison.

@Bob, regarding UPF placement: the ability to virtualise network functions in 5G Core allows easier scaling of UPFs as required.

All best,
Kevin

C2 General
From: tsvwg <[email-masked]> On Behalf Of Bob Briscoe
Sent: 10 March 2021 17:41
To: tsvwg IETF list <[email-masked]>
Subject: [tsvwg] Fwd: Qs on your 5G L4S slides

CYBER SECURITY WARNING: This email is from an external source - be careful of attachments and links. Please follow the Cyber Code and report suspicious emails.
tsvwg,

-------- Forwarded Message --------
Subject:

RE: Qs on your 5G L4S slides

Date:

Wed, 10 Mar 2021 14:33:42 +0000

From:

Ingemar Johansson S <[email-masked]><mailto:[email-masked]>

To:

Bob Briscoe <[email-masked]><mailto:[email-masked]>

CC:

Ingemar Johansson S <[email-masked]><mailto:[email-masked]>

Hi
Please see inline [IJ]

/Ingemar

-----Original Message-----
From: Bob Briscoe <[email-masked]><mailto:[email-masked]>
Sent: den 10 mars 2021 14:46
To: Ingemar Johansson S <[email-masked]><mailto:[email-masked]>
Subject: Qs on your 5G L4S slides

Ingemar,

And I think you'll need to explain where the UPF is typically located. I believe
it's close to the edge, isn't i?
Further into the network (beyond the UPF) these flows just become an
aggregate of all the users.
[IJ] The UPF is close to the edge somehow, it is hard to say for certain where they are located, they can be real close to the base stations or >100km away.

#6 Question:
Do you have any feel for qDelay & throughput if a "Classic ECN AQM" like PIE
or CoDel was used?
[IJ] No, it was not studied in the master thesis work.

#6 - #11:

#12: L4S is meant to greatly reduce the throughput-delay tradeoff, and in our
results it did.
Any idea why not here? I guess, with video, it's the 'getting up to speed' fast
problem (that I'm working on with Joakim).
[IJ] One reason is the large variation in frame sizes that video coders generate.
Another is that SCReAM paces out the video frames as 50% higher rate than the nominal video target bitrate. This pacing overhead can be configured lower but then the video frames (RTP packets) are more likely to become queued up in the sender instead. I really believe that it can be done better, was hoping to have time to improve SCReAM in this respect but the work hours fly in other directions .
With that said. Also a DCTCP flow (with L4S) marking will get a reduced throughput compared to e.g a Cubic flow (without L4S) over cellular. The reason is that the large buffers with Cubic absorb the fast fading dips in LTE and NR. With DCTCP + L4S some extra headroom is needed to avoid queue build up.

Bob

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 15 Mar 2021 09:54:36 +0000

Hi Kevin, Bob + others

CC Davide (thesis author)

Yes, there was a test with the use of the dedicated bearer (DBS) and no-L4S.
This is exemplified in section 5.3.6 in the thesis report. In short the
outcome is that the background traffic will be severely affected. The reason
is that the DBS scheduler (originally devised for e.g. VoLTE) prioritizes a
bearer when the queue delay exceeds a given low threshold (e.g 10ms). And
because SCReAM without L4S targets larger queue delay, the outcome is that
it will hog an unreasonable share of the available resourses. 

What this means is that it is necessary to use some extra guard mechanism
when prioritized bearers are used, but this is of course not only an L4S
problem.

/Ingemar

* http://www.diva-portal.org/smash/record.jsf?pid=diva2%3A1484466
<http://www.diva-portal.org/smash/record.jsf?pid=diva2%3A1484466&dswid=-2512
> &dswid=-2512

From: tsvwg <[email-masked]> On Behalf Of Smith, Kevin, Vodafone
Group
Sent: den 12 mars 2021 14:56
To: Bob Briscoe <[email-masked]>; tsvwg IETF list <[email-masked]>
Subject: Re: [tsvwg] Fwd: Qs on your 5G L4S slides

Hi Ingemar,

Just to ask, was there also a variant of the test with no L4S but with the
dedicated bearer? I'd be interested to see that comparison.

@Bob, regarding UPF placement: the ability to virtualise network functions
in 5G Core allows easier scaling of UPFs as required. 

All best,

Kevin

 

C2 General

From: tsvwg <[email-masked] <mailto:[email-masked]> > On
Behalf Of Bob Briscoe
Sent: 10 March 2021 17:41
To: tsvwg IETF list <[email-masked] <mailto:[email-masked]> >
Subject: [tsvwg] Fwd: Qs on your 5G L4S slides

CYBER SECURITY WARNING: This email is from an external source - be careful
of attachments and links. Please follow the Cyber Code and report suspicious
emails.

tsvwg,

-------- Forwarded Message -------- 

Subject: 

Date: 

From: 

Ingemar Johansson S  <mailto:[email-masked]>
<[email-masked]>

To: 

Bob Briscoe  <mailto:[email-masked]> <[email-masked]>

CC: 

Ingemar Johansson S  <mailto:[email-masked]>
<[email-masked]>

Hi
Please see inline [IJ]

/Ingemar

-----Original Message-----
From: Bob Briscoe  <mailto:[email-masked]>
<[email-masked]>
Sent: den 10 mars 2021 14:46
To: Ingemar Johansson S  <mailto:[email-masked]>
<[email-masked]>
Subject: Qs on your 5G L4S slides

Ingemar,

And I think you'll need to explain where the UPF is typically located. I
believe
it's close to the edge, isn't i?
Further into the network (beyond the UPF) these flows just become an
aggregate of all the users.

#6 Question:

#6 - #11:

[IJ] Per user (bearer)

#12: L4S is meant to greatly reduce the throughput-delay tradeoff, and in
our
results it did.
Any idea why not here? I guess, with video, it's the 'getting up to speed'
fast
problem (that I'm working on with Joakim).

[IJ] One reason is the large variation in frame sizes that video coders
generate.
Another is that SCReAM paces out the video frames as 50% higher rate than
the nominal video target bitrate. This pacing overhead can be configured
lower but then the video frames (RTP packets) are more likely to become
queued up in the sender instead. I really believe that it can be done
better, was hoping to have time to improve SCReAM in this respect but the
work hours fly in other directions .
With that said. Also a DCTCP flow (with L4S) marking will get a reduced
throughput compared to e.g a Cubic flow (without L4S) over cellular. The
reason is that the large buffers with Cubic absorb the fast fading dips in
LTE and NR. With DCTCP + L4S some extra headroom is needed to avoid queue
build up.

Bob

---

From: <[email-masked]>
Date: Mon, 15 Mar 2021 10:47:38 +0000

Hi Ingemar,

That depends. For WiFi, draft-ietf-tsvwg-nqb-05 specifies mapping L4S to a
priority bearer based PHB. Then this stops to be an L4S problem. I’d like to
be clear about that issue and the question is, whether there will be a
recommendation to assign L4S traffic to a 4G or 5G priority bearer. If your
answer is no, why is there a draft specifying a priority bearer for WiFi L4S
traffic?

The underlying question is, to which extend does the end-to-end performance
of L4S depend on suitable radio schedulers coupling two congestion control
algos or queuing behaviours, like L4S standardises for fixed line
schedulers. And how to operate a network, if these are absent.

Regards,

Ruediger

Von: tsvwg <[email-masked]> Im Auftrag von Ingemar Johansson S
Gesendet: Montag, 15. März 2021 10:55
An: Smith, Kevin, Vodafone Group
<Kevin.Smith=[email-masked]>; Bob Briscoe
<[email-masked]>; tsvwg IETF list <[email-masked]>
Betreff: Re: [tsvwg] Fwd: Qs on your 5G L4S slides

Hi Kevin, Bob + others

/Ingemar

 

From: tsvwg <[email-masked] <mailto:[email-masked]> > On
Behalf Of Smith, Kevin, Vodafone Group
Sent: den 12 mars 2021 14:56
To: Bob Briscoe <[email-masked] <mailto:[email-masked]> >; tsvwg
IETF list <[email-masked] <mailto:[email-masked]> >
Subject: Re: [tsvwg] Fwd: Qs on your 5G L4S slides

Hi Ingemar,

Just to ask, was there also a variant of the test with no L4S but with the
dedicated bearer? I’d be interested to see that comparison.

All best,

Kevin

 

C2 General

tsvwg,

-------- Forwarded Message -------- 

Subject: 

Date: 

From: 

To: 

CC: 

Hi
Please see inline [IJ]

/Ingemar

-----Original Message-----

Ingemar,

#6 Question:

#6 - #11:

[IJ] Per user (bearer)

Bob

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 15 Mar 2021 11:08:18 +0000

Hi Ruediger

I can’t really comment on how this is handled for WiFi. But I also notice
that DOCSIS has a mechanism that demotes misbehaving L4S flows into a
classic queue.

For 3GPP access already L4S with default bearers gives quite some
improvement. 

The use of L4S with priority scheduling can enhance performance even more
but poses some additional concerns, where the use of a DBS scheduler is one
extreme in this context. There are other alternatives such as increased
scheduling weight that has a more limited impact on other traffic that runs
on default bearers. 

But this problem is not unique to L4S. You would face the same issue with
e.g., GBR bearers for the cases where an endpoint gets in bad coverage.
Additional methods can be needed here to avoid that one bearer gets unduly
large share of the radio resources.   

/Ingemar

From: [email-masked] <[email-masked]> 
Sent: den 15 mars 2021 11:48
To: Ingemar Johansson S <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: AW: [tsvwg] Fwd: Qs on your 5G L4S slides

Hi Ingemar,

Regards,

Ruediger

Von: tsvwg <[email-masked] <mailto:[email-masked]> > Im
Auftrag von Ingemar Johansson S
Gesendet: Montag, 15. März 2021 10:55
An: Smith, Kevin, Vodafone Group <Kevin.Smith=[email-masked]
<mailto:Kevin.Smith=[email-masked]> >; Bob Briscoe
<[email-masked] <mailto:[email-masked]> >; tsvwg IETF list
<[email-masked] <mailto:[email-masked]> >
Betreff: Re: [tsvwg] Fwd: Qs on your 5G L4S slides

Hi Kevin, Bob + others

/Ingemar

 

Hi Ingemar,

All best,

Kevin

 

C2 General

tsvwg,

-------- Forwarded Message -------- 

Subject: 

Date: 

From: 

To: 

CC: 

Hi
Please see inline [IJ]

/Ingemar

-----Original Message-----

Ingemar,

#6 Question:

#6 - #11:

[IJ] Per user (bearer)

Bob

---

From: <[email-masked]>
Date: Mon, 15 Mar 2021 11:19:06 +0000

Hi Ingemar,

I’m not having trouble with wireless default scheduling. I’d favour the
development of a DiffServ scheduler on packet layer combined with a default
scheduler below. It seems to me that 3 GPP choose different approaches for
4G and 5G.

I wonder which scheduling was recommended for 3GPP access types, if there’s
an RFC recommending a priority bearer for L4S at WiFi interfaces.

Regards,

Ruediger

Von: Ingemar Johansson S <[email-masked]> 
Gesendet: Montag, 15. März 2021 12:08
An: Geib, Rüdiger <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Ingemar
Johansson S <[email-masked]>
Betreff: RE: [tsvwg] Fwd: Qs on your 5G L4S slides

Hi Ruediger

/Ingemar

From: [email-masked] <mailto:[email-masked]>
<[email-masked] <mailto:[email-masked]> > 
Sent: den 15 mars 2021 11:48
To: Ingemar Johansson S <[email-masked]
<mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ;
[email-masked] <mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> 
Subject: AW: [tsvwg] Fwd: Qs on your 5G L4S slides

Hi Ingemar,

Regards,

Ruediger

Hi Kevin, Bob + others

/Ingemar

 

Hi Ingemar,

All best,

Kevin

 

C2 General

tsvwg,

-------- Forwarded Message -------- 

Subject: 

Date: 

From: 

To: 

CC: 

Hi
Please see inline [IJ]

/Ingemar

-----Original Message-----

Ingemar,

#6 Question:

#6 - #11:

[IJ] Per user (bearer)

Bob

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 15 Mar 2021 17:20:02 +0000

Hi

To be honest, L4S has not advanced that far in 3GPP. 

I hope that it well be baked into the same Work Item as 5G_AIS (Advanced
Interactive Services) in SA2. In any case, I believe that the scheduling
details and QoS matters in relation to L4S is something that is best
discussed and resolved in 3GPP, possibly in liaison with TSVWG. 

It has been hard to drive L4S in 3GPP earlier because of almost 2 years
stalemate, in addition the 3GPP schedule has been quite overwhelmed because
additional delays due to the pandemic. But I hope things will move more
smoothly from now on, especially with the updated TSVWG charter and the Oct
2021 timeline of the L4S drafts.

/Ingemar

Sent: den 15 mars 2021 12:19

Hi Ingemar,

Regards,

Ruediger

Von: Ingemar Johansson S <[email-masked]
<mailto:[email-masked]> > 
Gesendet: Montag, 15. März 2021 12:08
An: Geib, Rüdiger <[email-masked]
<mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ;
[email-masked] <mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> ; Ingemar Johansson S
<[email-masked] <mailto:[email-masked]>

Hi Ruediger

/Ingemar

Hi Ingemar,

Regards,

Ruediger

Hi Kevin, Bob + others

/Ingemar

 

Hi Ingemar,

All best,

Kevin

 

C2 General

tsvwg,

-------- Forwarded Message -------- 

Subject: 

Date: 

From: 

To: 

CC: 

Hi
Please see inline [IJ]

/Ingemar

-----Original Message-----

Ingemar,

#6 Question:

#6 - #11:

[IJ] Per user (bearer)

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 15 Mar 2021 18:06:02 +0000

Ruediger,

==DOCSIS==
Whoa! NQB is not L4S traffic. NQB is a Diffserv codepoint. L4S is 
identified by the ECN field. In DOCSIS the NQB Diffserv codepoint 
classifies into the /same queue/ as L4S traffic (renamed the Low Latency 
queue due to its dual role). Allowing in unresponsive traffic was only 
considered in DOCSIS because there was already a sufficient policing 
function in front of the queue (per-flow queue protection).

==Mobile==
If a mobile operator (or in this case a masters student), uses the 
ECT(1) codepoint to classify traffic into a priority bearer, then it's 
not L4S. It's an ECN codepoint intended for L4S but used (abused?) in a 
Diffserv priority scheduler.

The problem that the DualQ Coupled AQM solved was how to isolate low 
latency flows without having to know how much bandwidth to set aside for 
them. So if there are M L4S flows and N Classic flows, M and N can take 
any value, including zero. That's because the coupling makes the two 
queues appear as one - from a bandwidth and congestion control 
perspective (approximately).

So, if you have a Diffserv scheduler and no L4S mechanism, you would 
need to go back to using traditional Diffserv techniques like guessing 
what M and N might be most of the time, to decide how much bandwidth to 
configure for a separate priority queue, then policing it.

To summarize, the answers to your question:
> The underlying question is, to which extend does the end-to-end 
> performance of L4S depend on suitable radio schedulers coupling two 
> congestion control algos or queuing behaviours, like L4S standardises 
> for fixed line schedulers. And how to operate a network, if these are 
> absent.

An operator that wants to support any technology without deploying the 
technology isn't going to get very far! L4S depends on using an L4S 
mechanism (obviously), specifically the DualQ Coupled AQM (or FQ). How 
to operate a network if L4S is absent - well, you go back to what you 
had before. But then you can't support applications that need 
consistently low latency /and/ the full available bandwidth, which is 
the point of L4S.

==WiFi==
You say that the NQB draft "specifies mapping L4S to a priority bearer 
based PHB". This is because NQB is having to cope with the WiFi 
situation as it finds it. It's not ideal, but you'll see below how it 
could evolve to something better.
I understand that the video access category (AC_VI) was the only choice 
that offered decent enough latency without excessive bandwidth priority. 
NQB just needs to be isolated from bursty traffic - it didn't choose 
AC_VI because of any need for /bandwidth/ priority, per se. NQB should 
work with quite weakly weighted priority as long as it's isolated. But 
that wasn't available in current WiFI.

L4S is also walking into the WiFi environment as it finds it. With 
today's non-L4S products, I would also recommend that the L4S-ECN 
codepoints are mapped to the video access category, if possible.
Nokia's latest WiFi products (in the 'Beacon' range) already include an 
L4S DualQ Coupled AQM. And as other L4S WiFi products come out, the 
coupling will introduce the recommended congestion signals that can be 
used as back-pressure against the priority scheduler. Users don't want 
to abuse scheduling priority at the expense of the balance between their 
own applications. But they have no choice until there's a mechanism that 
allows their applications to balance against other apps.

Finally, once there's an L4S queue in WiFi kit, NQB traffic could be 
classified into it, as was done in DOCSIS.

FQ offers an alternative path for WiFi - neither precludes the other.

Does this help explain?

Bob

On 15/03/2021 11:19, [email-masked] wrote:
>
> Hi Ingemar,
>
> I’m not having trouble with wireless default scheduling. I’d favour 
> the development of a DiffServ scheduler on packet layer combined with 
> a default scheduler below. It seems to me that 3 GPP choose different 
> approaches for 4G and 5G.
>
> I wonder which scheduling was recommended for 3GPP access types, if 
> there’s an RFC recommending a priority bearer for L4S at WiFi interfaces.
>
> Regards,
>
> Ruediger
>
> *Von:*Ingemar Johansson S <[email-masked]>
> *Gesendet:* Montag, 15. März 2021 12:08
> *An:* Geib, Rüdiger <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked]; 
> Ingemar Johansson S <[email-masked]>
> *Betreff:* RE: [tsvwg] Fwd: Qs on your 5G L4S slides
>
> Hi Ruediger
>
> I can’t really comment on how this is handled for WiFi. But I also 
> notice that DOCSIS has a mechanism that demotes misbehaving L4S flows 
> into a classic queue.
>
> The use of L4S with priority scheduling can enhance performance even 
> more but poses some additional concerns, where the use of a DBS 
> scheduler is one extreme in this context. There are other alternatives 
> such as increased scheduling weight that has a more limited impact on 
> other traffic that runs on default bearers.
>
> But this problem is not unique to L4S. You would face the same issue 
> with e.g., GBR bearers for the cases where an endpoint gets in bad 
> coverage. Additional methods can be needed here to avoid that one 
> bearer gets unduly large share of the radio resources.
>
> /Ingemar
>
> *From:* [email-masked] <mailto:[email-masked]> 
> <[email-masked] <mailto:[email-masked]>>
> *Sent:* den 15 mars 2021 11:48
> *To:* Ingemar Johansson S <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> *Subject:* AW: [tsvwg] Fwd: Qs on your 5G L4S slides
>
> Hi Ingemar,
>
> That depends. For WiFi, draft-ietf-tsvwg-nqb-05 specifies mapping L4S 
> to a priority bearer based PHB. Then this stops to be an L4S problem. 
> I’d like to be clear about that issue and the question is, whether 
> there will be a recommendation to assign L4S traffic to a 4G or 5G 
> priority bearer. If your answer is no, why is there a draft specifying 
> a priority bearer for WiFi L4S traffic?
>
> The underlying question is, to which extend does the end-to-end 
> performance of L4S depend on suitable radio schedulers coupling two 
> congestion control algos or queuing behaviours, like L4S standardises 
> for fixed line schedulers. And how to operate a network, if these are 
> absent.
>
> Regards,
>
> Ruediger
>
> *Von:*tsvwg <[email-masked] <mailto:[email-masked]>> 
> *Im Auftrag von *Ingemar Johansson S
> *Gesendet:* Montag, 15. März 2021 10:55
> *An:* Smith, Kevin, Vodafone Group 
> <Kevin.Smith=[email-masked] 
> <mailto:Kevin.Smith=[email-masked]>>; Bob Briscoe 
> <[email-masked] <mailto:[email-masked]>>; tsvwg IETF list 
> <[email-masked] <mailto:[email-masked]>>
> *Betreff:* Re: [tsvwg] Fwd: Qs on your 5G L4S slides
>
> Hi Kevin, Bob + others
>
> Yes, there was a test with the use of the dedicated bearer (DBS) and 
> no-L4S. This is exemplified in section 5.3.6 in the thesis report. In 
> short the outcome is that the background traffic will be severely 
> affected. The reason is that the DBS scheduler (originally devised for 
> e.g. VoLTE) prioritizes a bearer when the queue delay exceeds a given 
> low threshold (e.g 10ms). And because SCReAM without L4S targets 
> larger queue delay, the outcome is that it will hog an unreasonable 
> share of the available resourses.
>
> What this means is that it is necessary to use some extra guard 
> mechanism when prioritized bearers are used, but this is of course not 
> only an L4S problem.
>
> /Ingemar
>
> * 
> http://www.diva-portal.org/smash/record.jsf?pid=diva2%3A1484466&dswid=-2512 
> <http://www.diva-portal.org/smash/record.jsf?pid=diva2%3A1484466&dswid=-2512>
>
> *From:* tsvwg <[email-masked] <mailto:[email-masked]>> 
> *On Behalf Of *Smith, Kevin, Vodafone Group
> *Sent:* den 12 mars 2021 14:56
> *To:* Bob Briscoe <[email-masked] <mailto:[email-masked]>>; 
> tsvwg IETF list <[email-masked] <mailto:[email-masked]>>
> *Subject:* Re: [tsvwg] Fwd: Qs on your 5G L4S slides
>
> Hi Ingemar,
>
> Just to ask, was there also a variant of the test with no L4S but with 
> the dedicated bearer? I’d be interested to see that comparison.
>
> @Bob, regarding UPF placement: the ability to virtualise network 
> functions in 5G Core allows easier scaling of UPFs as required.
>
> All best,
>
> Kevin
>
> C2 General
>
> *From:* tsvwg <[email-masked] <mailto:[email-masked]>> 
> *On Behalf Of *Bob Briscoe
> *Sent:* 10 March 2021 17:41
> *To:* tsvwg IETF list <[email-masked] <mailto:[email-masked]>>
> *Subject:* [tsvwg] Fwd: Qs on your 5G L4S slides
>
> *CYBER SECURITY WARNING:*This email is from an external source - be 
> careful of attachments and links. Please follow the Cyber Code and 
> report suspicious emails.
>
> tsvwg,
>
> *Subject: *
> *Date: *
> *From: *
> Ingemar Johansson S <[email-masked]> 
> <mailto:[email-masked]>
>
> *To: *
>
> 	
>
> Bob Briscoe <[email-masked]> <mailto:[email-masked]>
>
> *CC: *
>
> 	
>
> Ingemar Johansson S <[email-masked]> 
> <mailto:[email-masked]>
>
>
>
> Hi
> Please see inline [IJ]
>
> /Ingemar
>
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>
> [IJ] The UPF is close to the edge somehow, it is hard to say for 
> certain where they are located, they can be real close to the base 
> stations or >100km away.
>
>
>     #6 Question:
> configured lower but then the video frames (RTP packets) are more 
> likely to become queued up in the sender instead. I really believe 
> that it can be done better, was hoping to have time to improve SCReAM 
> in this respect but the work hours fly in other directions .
> With that said. Also a DCTCP flow (with L4S) marking will get a 
> reduced throughput compared to e.g a Cubic flow (without L4S) over 
> cellular. The reason is that the large buffers with Cubic absorb the 
> fast fading dips in LTE and NR. With DCTCP + L4S some extra headroom 
> is needed to avoid queue build up.
>
>
>
>     Bob
>
>     --
>     Bob Briscoe https://protect2.fireeye.com/v1/url?k=828d3ddc
>     <https://protect2.fireeye.com/v1/url?k=828d3ddc>-

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: Greg White <[email-masked]>
Date: Mon, 15 Mar 2021 21:57:52 +0000

Inline [GW].

From: tsvwg <[email-masked]> on behalf of Bob Briscoe <[email-masked]>
Date: Monday, March 15, 2021 at 12:06 PM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [tsvwg] Fwd: Qs on your 5G L4S slides

Ruediger,

==DOCSIS==
Whoa! NQB is not L4S traffic. NQB is a Diffserv codepoint. L4S is identified by the ECN field. In DOCSIS the NQB Diffserv codepoint classifies into the /same queue/ as L4S traffic (renamed the Low Latency queue due to its dual role). Allowing in unresponsive traffic was only considered in DOCSIS because there was already a sufficient policing function in front of the queue (per-flow queue protection).

==Mobile==
If a mobile operator (or in this case a masters student), uses the ECT(1) codepoint to classify traffic into a priority bearer, then it's not L4S. It's an ECN codepoint intended for L4S but used (abused?) in a Diffserv priority scheduler.

The problem that the DualQ Coupled AQM solved was how to isolate low latency flows without having to know how much bandwidth to set aside for them. So if there are M L4S flows and N Classic flows, M and N can take any value, including zero. That's because the coupling makes the two queues appear as one - from a bandwidth and congestion control perspective (approximately).

So, if you have a Diffserv scheduler and no L4S mechanism, you would need to go back to using traditional Diffserv techniques like guessing what M and N might be most of the time, to decide how much bandwidth to configure for a separate priority queue, then policing it.

The underlying question is, to which extend does the end-to-end performance of L4S depend on suitable radio schedulers coupling two congestion control algos or queuing behaviours, like L4S standardises for fixed line schedulers. And how to operate a network, if these are absent.

An operator that wants to support any technology without deploying the technology isn't going to get very far! L4S depends on using an L4S mechanism (obviously), specifically the DualQ Coupled AQM (or FQ). How to operate a network if L4S is absent - well, you go back to what you had before. But then you can't support applications that need consistently low latency /and/ the full available bandwidth, which is the point of L4S.

==WiFi==
You say that the NQB draft "specifies mapping L4S to a priority bearer based PHB". This is because NQB is having to cope with the WiFi situation as it finds it. It's not ideal, but you'll see below how it could evolve to something better.
I understand that the video access category (AC_VI) was the only choice that offered decent enough latency without excessive bandwidth priority. NQB just needs to be isolated from bursty traffic - it didn't choose AC_VI because of any need for /bandwidth/ priority, per se. NQB should work with quite weakly weighted priority as long as it's isolated. But that wasn't available in current WiFI.

[GW] The NQB draft does NOT make any recommendations on treatment of L4S-ECN marked traffic.  In addition, for NQB traffic it recommends to map it into a separate queue in the best effort access category (AC_BE).  It only utilizes the video access category as a way to interoperate with existing WiFi gear (including RFC8325 gear*), and in that case it recommends that the EDCA parameters be configured so that AC_VI gets the same bandwidth priority as AC_BE.
*this has gotten me thinking that it would be worth further discussion on NQB recommendations for RFC8325 gear.  Since the recommendation in the NQB draft would amount to a change to the implementation, perhaps the draft should recommend that 8325 gear (if possible) maps NQB to a separate queue in AC_BE, and only provides the AC_VI option as a backstop in case the implementation can’t provide a separate queue.

L4S is also walking into the WiFi environment as it finds it. With today's non-L4S products, I would also recommend that the L4S-ECN codepoints are mapped to the video access category, if possible.
Nokia's latest WiFi products (in the 'Beacon' range) already include an L4S DualQ Coupled AQM. And as other L4S WiFi products come out, the coupling will introduce the recommended congestion signals that can be used as back-pressure against the priority scheduler. Users don't want to abuse scheduling priority at the expense of the balance between their own applications. But they have no choice until there's a mechanism that allows their applications to balance against other apps.

[GW] In my view the preferred option is for the dual-queue coupled AQM to be implemented within a single access category (e.g. AC_BE).  Utilizing AC_VI for L4S-ECN traffic would eliminate the ability to provide backpressure, since the BE queue in one STA can’t easily be coupled to the VI queue in another.

Finally, once there's an L4S queue in WiFi kit, NQB traffic could be classified into it, as was done in DOCSIS.

Does this help explain?

Bob
On 15/03/2021 11:19, [email-masked]<mailto:[email-masked]> wrote:
Hi Ingemar,

I’m not having trouble with wireless default scheduling. I’d favour the development of a DiffServ scheduler on packet layer combined with a default scheduler below. It seems to me that 3 GPP choose different approaches for 4G and 5G.

I wonder which scheduling was recommended for 3GPP access types, if there’s an RFC recommending a priority bearer for L4S at WiFi interfaces.

Regards,

Ruediger

Von: Ingemar Johansson S <[email-masked]><mailto:[email-masked]>
Gesendet: Montag, 15. März 2021 12:08
An: Geib, Rüdiger <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Ingemar Johansson S <[email-masked]><mailto:[email-masked]>
Betreff: RE: [tsvwg] Fwd: Qs on your 5G L4S slides

Hi Ruediger

I can’t really comment on how this is handled for WiFi. But I also notice that DOCSIS has a mechanism that demotes misbehaving L4S flows into a classic queue.

For 3GPP access already L4S with default bearers gives quite some improvement.
The use of L4S with priority scheduling can enhance performance even more but poses some additional concerns, where the use of a DBS scheduler is one extreme in this context. There are other alternatives such as increased scheduling weight that has a more limited impact on other traffic that runs on default bearers.
But this problem is not unique to L4S. You would face the same issue with e.g., GBR bearers for the cases where an endpoint gets in bad coverage. Additional methods can be needed here to avoid that one bearer gets unduly large share of the radio resources.

/Ingemar

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: den 15 mars 2021 11:48
To: Ingemar Johansson S <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: AW: [tsvwg] Fwd: Qs on your 5G L4S slides

Hi Ingemar,

That depends. For WiFi, draft-ietf-tsvwg-nqb-05 specifies mapping L4S to a priority bearer based PHB. Then this stops to be an L4S problem. I’d like to be clear about that issue and the question is, whether there will be a recommendation to assign L4S traffic to a 4G or 5G priority bearer. If your answer is no, why is there a draft specifying a priority bearer for WiFi L4S traffic?

The underlying question is, to which extend does the end-to-end performance of L4S depend on suitable radio schedulers coupling two congestion control algos or queuing behaviours, like L4S standardises for fixed line schedulers. And how to operate a network, if these are absent.

Regards,

Ruediger

Von: tsvwg <[email-masked]<mailto:[email-masked]>> Im Auftrag von Ingemar Johansson S
Gesendet: Montag, 15. März 2021 10:55
An: Smith, Kevin, Vodafone Group <Kevin.Smith=[email-masked]<mailto:Kevin.Smith=[email-masked]>>; Bob Briscoe <[email-masked]<mailto:[email-masked]>>; tsvwg IETF list <[email-masked]<mailto:[email-masked]>>
Betreff: Re: [tsvwg] Fwd: Qs on your 5G L4S slides

Hi Kevin, Bob + others

Yes, there was a test with the use of the dedicated bearer (DBS) and no-L4S. This is exemplified in section 5.3.6 in the thesis report. In short the outcome is that the background traffic will be severely affected. The reason is that the DBS scheduler (originally devised for e.g. VoLTE) prioritizes a bearer when the queue delay exceeds a given low threshold (e.g 10ms). And because SCReAM without L4S targets larger queue delay, the outcome is that it will hog an unreasonable share of the available resourses.
What this means is that it is necessary to use some extra guard mechanism when prioritized bearers are used, but this is of course not only an L4S problem.

/Ingemar

* http://www.diva-portal.org/smash/record.jsf?pid=diva2%3A1484466&dswid=-2512

From: tsvwg <[email-masked]<mailto:[email-masked]>> On Behalf Of Smith, Kevin, Vodafone Group
Sent: den 12 mars 2021 14:56
To: Bob Briscoe <[email-masked]<mailto:[email-masked]>>; tsvwg IETF list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tsvwg] Fwd: Qs on your 5G L4S slides

Hi Ingemar,

Just to ask, was there also a variant of the test with no L4S but with the dedicated bearer? I’d be interested to see that comparison.

All best,
Kevin

C2 General
From: tsvwg <[email-masked]<mailto:[email-masked]>> On Behalf Of Bob Briscoe
Sent: 10 March 2021 17:41
To: tsvwg IETF list <[email-masked]<mailto:[email-masked]>>
Subject: [tsvwg] Fwd: Qs on your 5G L4S slides

-------- Forwarded Message --------
Subject:
RE: Qs on your 5G L4S slides
Date:

Hi
Please see inline [IJ]

/Ingemar
-----Original Message-----
From: Bob Briscoe <[email-masked]><mailto:[email-masked]>
Sent: den 10 mars 2021 14:46
To: Ingemar Johansson S <[email-masked]><mailto:[email-masked]>
Subject: Qs on your 5G L4S slides

Ingemar,

#6 Question:

#6 - #11:

Bob

--

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 15 Mar 2021 22:28:20 +0000

Greg,
See quick clarification inline [BB]

On 15/03/2021 21:57, Greg White wrote:
>
> Inline [GW].
>
> *From: *tsvwg <[email-masked]> on behalf of Bob Briscoe 
> <[email-masked]>
> *Date: *Monday, March 15, 2021 at 12:06 PM
> *To: *"[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [tsvwg] Fwd: Qs on your 5G L4S slides
>
> Ruediger,
>
> ==DOCSIS==
> classifies into the /same queue/ as L4S traffic (renamed the Low 
> Latency queue due to its dual role). Allowing in unresponsive traffic 
> was only considered in DOCSIS because there was already a sufficient 
> policing function in front of the queue (per-flow queue protection).
>
> ==Mobile==
> not L4S. It's an ECN codepoint intended for L4S but used (abused?) in 
> a Diffserv priority scheduler.
>
> latency flows without having to know how much bandwidth to set aside 
> for them. So if there are M L4S flows and N Classic flows, M and N can 
> take any value, including zero. That's because the coupling makes the 
> two queues appear as one - from a bandwidth and congestion control 
> what M and N might be most of the time, to decide how much bandwidth 
> to configure for a separate priority queue, then policing it.
>
>     performance of L4S depend on suitable radio schedulers coupling
>     two congestion control algos or queuing behaviours, like L4S
>     standardises for fixed line schedulers. And how to operate a
>     network, if these are absent.
>
>
> I understand that the video access category (AC_VI) was the only 
> choice that offered decent enough latency without excessive bandwidth 
> priority. NQB just needs to be isolated from bursty traffic - it 
> didn't choose AC_VI because of any need for /bandwidth/ priority, per 
> se. NQB should work with quite weakly weighted priority as long as 
> it's isolated. But that wasn't available in current WiFI.
>
> [GW] The NQB draft does NOT make any recommendations on treatment of 
> L4S-ECN marked traffic.  In addition, for NQB traffic it recommends to 
> map it into a separate queue in the best effort access category 
> (AC_BE).  It only utilizes the video access category as a way to 
> interoperate with existing WiFi gear (including RFC8325 gear*), and in 
> that case it recommends that the EDCA parameters be configured so that 
> AC_VI gets the same bandwidth priority as AC_BE.
>
> *this has gotten me thinking that it would be worth further discussion 
> on NQB recommendations for RFC8325 gear.  Since the recommendation in 
> the NQB draft would amount to a change to the implementation, perhaps 
> the draft should recommend that 8325 gear (if possible) maps NQB to a 
> separate queue in AC_BE, and only provides the AC_VI option as a 
> backstop in case the implementation can’t provide a separate queue.
>
>
>
> Nokia's latest WiFi products (in the 'Beacon' range) already include 
> an L4S DualQ Coupled AQM. And as other L4S WiFi products come out, the 
> to abuse scheduling priority at the expense of the balance between 
> their own applications. But they have no choice until there's a 
> mechanism that allows their applications to balance against other apps.
>
> [GW] In my view the preferred option is for the dual-queue coupled AQM 
> to be implemented within a single access category (e.g. AC_BE). 
> Utilizing AC_VI for L4S-ECN traffic would eliminate the ability to 
> provide backpressure, since the BE queue in one STA can’t easily be 
> coupled to the VI queue in another.
>

[BB] I agree.
To be clear, when I said "I would also recommend that the L4S-ECN 
codepoints are mapped to the video access category, if possible." I 
meant, in the absence of an L4S AQM capability in the WiFI node (i.e. 
for dealing with today).

Bob

>     I’m not having trouble with wireless default scheduling. I’d
>     favour the development of a DiffServ scheduler on packet layer
>     combined with a default scheduler below. It seems to me that 3 GPP
>     choose different approaches for 4G and 5G.
>
>     I wonder which scheduling was recommended for 3GPP access types,
>     if there’s an RFC recommending a priority bearer for L4S at WiFi
>     interfaces.
>
>     Regards,
>
>     Ruediger
>
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>; Ingemar Johansson S
>     notice that DOCSIS has a mechanism that demotes misbehaving L4S
>     flows into a classic queue.
>
>     The use of L4S with priority scheduling can enhance performance
>     even more but poses some additional concerns, where the use of a
>     DBS scheduler is one extreme in this context. There are other
>     alternatives such as increased scheduling weight that has a more
>     limited impact on other traffic that runs on default bearers.
>
>     But this problem is not unique to L4S. You would face the same
>     issue with e.g., GBR bearers for the cases where an endpoint gets
>     in bad coverage. Additional methods can be needed here to avoid
>     that one bearer gets unduly large share of the radio resources.
>
>     /Ingemar
>
>     That depends. For WiFi, draft-ietf-tsvwg-nqb-05 specifies mapping
>     L4S to a priority bearer based PHB. Then this stops to be an L4S
>     problem. I’d like to be clear about that issue and the question
>     is, whether there will be a recommendation to assign L4S traffic
>     to a 4G or 5G priority bearer. If your answer is no, why is there
>     a draft specifying a priority bearer for WiFi L4S traffic?
>
>     performance of L4S depend on suitable radio schedulers coupling
>     two congestion control algos or queuing behaviours, like L4S
>     standardises for fixed line schedulers. And how to operate a
>     network, if these are absent.
>
>     Regards,
>
>     Ruediger
>
>     *Von:*tsvwg <[email-masked]
>     <mailto:[email-masked]>> *Im Auftrag von *Ingemar Johansson S
>     <[email-masked] <mailto:[email-masked]>>; tsvwg IETF
>     list <[email-masked] <mailto:[email-masked]>>
>     Yes, there was a test with the use of the dedicated bearer (DBS)
>     and no-L4S. This is exemplified in section 5.3.6 in the thesis
>     report. In short the outcome is that the background traffic will
>     be severely affected. The reason is that the DBS scheduler
>     (originally devised for e.g. VoLTE) prioritizes a bearer when the
>     queue delay exceeds a given low threshold (e.g 10ms). And because
>     SCReAM without L4S targets larger queue delay, the outcome is that
>     mechanism when prioritized bearers are used, but this is of course
>     not only an L4S problem.
>
>     /Ingemar
>
>     *
>     *From:* tsvwg <[email-masked]
>     <mailto:[email-masked]>> *On Behalf Of *Smith, Kevin,
>     Vodafone Group
>     *To:* Bob Briscoe <[email-masked]
>     <mailto:[email-masked]>>; tsvwg IETF list <[email-masked]
>     <mailto:[email-masked]>>
>     Just to ask, was there also a variant of the test with no L4S but
>     with the dedicated bearer? I’d be interested to see that comparison.
>
>     *From:* tsvwg <[email-masked]
>     <mailto:[email-masked]>> *On Behalf Of *Bob Briscoe
>     *CYBER SECURITY WARNING:*This email is from an external source -
>     be careful of attachments and links. Please follow the Cyber Code
>     and report suspicious emails.
>
>     tsvwg,
>
>     Another is that SCReAM paces out the video frames as 50% higher
>     rate than the nominal video target bitrate. This pacing overhead
>     can be configured lower but then the video frames (RTP packets)
>     are more likely to become queued up in the sender instead. I
>     really believe that it can be done better, was hoping to have time
>     to improve SCReAM in this respect but the work hours fly in other
>     directions .
>     cellular. The reason is that the large buffers with Cubic absorb
>     the fast fading dips in LTE and NR. With DCTCP + L4S some extra
>     headroom is needed to avoid queue build up.
>
>
>
>         Bob
>
>         --
> Bob Briscoehttp://bobbriscoe.net/  <http://bobbriscoe.net/>

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 15 Mar 2021 23:28:45 +0100

Hi Bob,

more below prefixed with [SM]

> On Mar 15, 2021, at 19:06, Bob Briscoe <[email-masked]> wrote:
> 
> Ruediger,
> 
> ==DOCSIS==
> The problem that the DualQ Coupled AQM solved was how to isolate low latency flows without having to know how much bandwidth to set aside for them.

	[SM] Except it does not doe so robustly and reliably, at ist core it is a ~1:16 classic/LL priority scheduler that gives a massive rate advantage to LL traffic that is ameliorated by a few heuristics that under some conditions result in more equitable sharing, but under different not less realistic conditions it just behaves like the 1:16 scheduler it is at its core.

> So if there are M L4S flows and N Classic flows, M and N can take any value, including zero. That's because the coupling makes the two queues appear as one - from a bandwidth and congestion control perspective (approximately). 
> 

[SM] Again, coupling does not solve that problem robustly and reliably either... you just keep focussing on those sets of conditions where it does and ignore the cases when it fails.

> An operator that wants to support any technology without deploying the technology isn't going to get very far! L4S depends on using an L4S mechanism (obviously), specifically the DualQ Coupled AQM…

[SM] Might be L54S point, but so far the proof is missing that L4S can actually deliver that over the existing wider internet. I keep asking for data supporting that claim for a few years now. At this point in time I interpret the lack of data as indication that the claim is not achievable.

> I understand that the video access category (AC_VI) was the only choice that offered decent enough latency without excessive bandwidth priority.

	[SM] Erm, AC_VI will wipe the floor with AC_BE and AC_BK, since it has a considerably higher probability to gain airtime than these lower ACs... For NQB that might be acceptable IFF the ISP polices the rate of NQB ingress and egress traffic to sane levels. Assuming there are one-size-fits-all sane levels for WiFi.

> NQB just needs to be isolated from bursty traffic - it didn't choose AC_VI because of any need for /bandwidth/ priority, per se. NQB should work with quite weakly weighted priority as long as it's isolated. But that wasn't available in current WiFI.
> 
> 

	[SM] since the L4S LL queue is not admission controlled that is going to be a misdesign, that makes DualQ's 1:16 priority scheduler look benign, AC_VI can not only almost starve AC_BE and AC_BK from the same station, but also all other WiFi packet on the same channel...
	I wonder whether you have actually tested your assertions about WiFi?

> FQ offers an alternative path for WiFi - neither precludes the other.

[SM] The good thing is that a) airtime fairness goes a long way to fix wifi (and without L4S), and b) WiFi introduces ~4ms aggregates making the difference between L4S' 1ms target and fq-codels weaker 5ms target pretty immaterial. That is if one accepts WiFis increased worst case RTT (with lower lever retransmits RTTs can increase by 100s of ms) there is exactly zero reason to continue waiting for Godot^W L4S, just get a linux AP with airtime fairness and you solved 95% of the issue with 0% of L4S side-effects.

Best Regards
	Sebastian

>> Cc: [email-masked]; [email-masked]; [email-masked]; Ingemar Johansson S <[email-masked]>
>> An: Smith, Kevin, Vodafone Group <Kevin.Smith=[email-masked]>; Bob Briscoe <[email-masked]>; tsvwg IETF list <[email-masked]>
>> From: tsvwg <[email-masked]> On Behalf Of Smith, Kevin, Vodafone Group
>> Bob Briscoe <[email-masked]>
>> CC:

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 15 Mar 2021 23:37:36 +0100

Hi Greg,

see [SM] below.

> On Mar 15, 2021, at 22:57, Greg White <[email-masked]> wrote:
> 
> Inline [GW].
>  
> [GW] The NQB draft does NOT make any recommendations on treatment of L4S-ECN marked traffic.  In addition, for NQB traffic it recommends to map it into a separate queue in the best effort access category (AC_BE).

	[SM] Which is sweet, but for almost 100% of deployed APs that is not going to happen, not eve the tinker friendly opensource OpenWrt APs allow to change the weights of the ACs.

>  It only utilizes the video access category as a way to interoperate with existing WiFi gear (including RFC8325 gear*), and in that case it recommends that the EDCA parameters be configured so that AC_VI gets the same bandwidth priority as AC_BE.

	[SM] But we all know that this recommendation will not actually to changes in a noticeable number of already deployed APs. Let's not kid ourselves that the update problem magically disappears just because it would be nic; this does not work for safety fixes, why should it work any better for new features?

> *this has gotten me thinking that it would be worth further discussion on NQB recommendations for RFC8325 gear.  Since the recommendation in the NQB draft would amount to a change to the implementa…

	[SM] Again sounds sane, unless we look at the deployed base.

> [GW] In my view the preferred option is for the dual-queue coupled AQM to be implemented within a single access category (e.g. AC_BE).  Utilizing AC_VI for L4S-ECN traffic would eliminate the abili…

[SM] Not that I want to defend ab-using AC_VI for L4S (as I said NQB with its aim for low rate flows has some justification for using AC_VI, assuming sufficiently strict admission control), but back-pessure in WiFI between all entities only happens via airtime access and that means you mainly compete with senders using the same AC, no?

---

From: <[email-masked]>
Date: Tue, 16 Mar 2021 08:12:01 +0000

Bob, Greg

Thanks Bob, I'm having a clear perception. I appreciate that work is being done to implement an L4S WiFi scheduler by one vendor. An L4S scheduler is a requirement for all kinds of wireless access, I think.

I'm also having a clear perception about the fairness resulting if a classic transport flow scheduled default on a WiFi access competes with L4S being scheduled priority. While I understand that L4S won't perform as desired, if scheduled default on WiFi under adverse operational conditions, it's not a good idea to solve that issue by scheduling L4S by priority on WiFi. I however note that NQB PHB can support also non-L4S traffic and L4S and NQB don't have to be linked.

Having read also Greg's response, I'd like to add that the Home-Gateway market in Germany is deregulated and any WiFi scheduler configuration which isn't implemented by all vendors serving this market will best be expected absent. That is to say, no IETF standard should specify an undesired behaviour. Deutsche Telekom is able to control BNG policies and L4S might be relevant there, but as WiFi is customer premises, an IETF standardized NQB DSCP shouldn't result in a fair chance to busy the hotline. Looking at this market environment, Bob's statement applies in general, L4S requires appropriately adapted scheduling from BNG to Terminating Equipment, and prior art won't do. That's a long way to go.

Regards,

Ruediger

Von: Bob Briscoe <[email-masked]>
Gesendet: Montag, 15. März 2021 19:06
An: Geib, Rüdiger <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Betreff: Re: AW: [tsvwg] Fwd: Qs on your 5G L4S slides

Ruediger,

==DOCSIS==

==Mobile==

==WiFi==

Does this help explain?

Bob

I'm not having trouble with wireless default scheduling. I'd favour the development of a DiffServ scheduler on packet layer combined with a default scheduler below. It seems to me that 3 GPP choose different approaches for 4G and 5G.

I wonder which scheduling was recommended for 3GPP access types, if there's an RFC recommending a priority bearer for L4S at WiFi interfaces.

Regards,

Ruediger

Hi Ruediger

I can't really comment on how this is handled for WiFi. But I also notice that DOCSIS has a mechanism that demotes misbehaving L4S flows into a classic queue.

/Ingemar

Hi Ingemar,

That depends. For WiFi, draft-ietf-tsvwg-nqb-05 specifies mapping L4S to a priority bearer based PHB. Then this stops to be an L4S problem. I'd like to be clear about that issue and the question is, whether there will be a recommendation to assign L4S traffic to a 4G or 5G priority bearer. If your answer is no, why is there a draft specifying a priority bearer for WiFi L4S traffic?

Regards,

Ruediger

Hi Kevin, Bob + others

/Ingemar

Hi Ingemar,

All best,
Kevin

C2 General

-------- Forwarded Message --------
Subject:
RE: Qs on your 5G L4S slides
Date:

Hi
Please see inline [IJ]

/Ingemar
-----Original Message-----
From: Bob Briscoe <[email-masked]><mailto:[email-masked]>
Sent: den 10 mars 2021 14:46
To: Ingemar Johansson S <[email-masked]><mailto:[email-masked]>
Subject: Qs on your 5G L4S slides

Ingemar,

#6 Question:

#6 - #11:

Bob

--

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 16 Mar 2021 10:48:42 +0000

Ruediger,

On 16/03/2021 08:12, [email-masked] wrote:
>
> Bob, Greg
>
> Thanks Bob, I’m having a clear perception. I appreciate that work is 
> being done to implement an L4S WiFi scheduler by one vendor. An L4S 
> scheduler is a requirement for all kinds of wireless access, I think.
>
> I’m also having a clear perception about the fairness resulting if a 
> classic transport flow scheduled default on a WiFi access competes 
> with L4S being scheduled priority. While I understand that L4S won’t 
> perform as desired, if scheduled default on WiFi under adverse 
> operational conditions, it’s not a good idea to solve that issue by 
> scheduling L4S by priority on WiFi.
>

[BB] My point was that the world is the other way up. Choosing a DSCP or 
ECN codepoint is not where the scheduling decision is made. The 'blame' 
for a scheduling decision is where a DSCP or ECN codepoint is mapped to 
a PHB. WiFi access points are being produced that map blocks of DSCPs by 
default to different access categories with different priority 
scheduling. That is where you need to direct your concerns. It's only 
because of those default mappings that everyone (including L4S and NQB) 
is then choosing the most appropriate DSCP to make best use of the 
scheduling (from their point of view).

This might look like dodging blame, but it's not - it's a genuine 
dilemma due to having to cope with the imperfect world we find.

Bob

> I however note that NQB PHB can support also non-L4S traffic and L4S 
> and NQB don’t have to be linked.
>
> Having read also Greg’s response, I’d like to add that the 
> Home-Gateway market in Germany is deregulated and any WiFi scheduler 
> configuration which isn’t implemented by all vendors serving this 
> market will best be expected absent. That is to say, no IETF standard 
> should specify an undesired behaviour. Deutsche Telekom is able to 
> control BNG policies and L4S might be relevant there, but as WiFi is 
> customer premises, an IETF standardized NQB DSCP shouldn’t result in a 
> fair chance to busy the hotline. Looking at this market environment, 
> Bob’s statement applies in general, L4S requires appropriately adapted 
> scheduling from BNG to Terminating Equipment, and prior art won’t do. 
> That’s a long way to go.
>
> Regards,
>
> Ruediger
>
> *Von:*Bob Briscoe <[email-masked]>
> *Gesendet:* Montag, 15. März 2021 19:06
> *An:* Geib, Rüdiger <[email-masked]>; 
> [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Betreff:* Re: AW: [tsvwg] Fwd: Qs on your 5G L4S slides
>
> Ruediger,
>
> ==DOCSIS==

---

From: Sebastian Moeller <[email-masked]>
Date: Tue, 16 Mar 2021 12:01:00 +0100

Bob,

more below prefixed [SM].

> On Mar 16, 2021, at 11:48, Bob Briscoe <[email-masked]> wrote:
> 
> Ruediger,
> 
>> Thanks Bob, I’m having a clear perception. I appreciate that work is being done to implement an L4S WiFi scheduler by one vendor. An L4S scheduler is a requirement for all kinds of wireless access, I think.
>>  
>> I’m also having a clear perception about the fairness resulting if a classic transport flow scheduled default on a WiFi access competes with L4S being scheduled priority. While I understand that L4S won’t perform as desired, if scheduled default on WiFi under adverse operational conditions, it’s not a good idea to solve that issue by scheduling L4S by priority on WiFi.
> 
> [BB] My point was that the world is the other way up. Choosing a DSCP or ECN codepoint is not where the scheduling decision is made. The 'blame' for a scheduling decision is where a DSCP or ECN codepoint is mapped to a PHB. WiFi access points are being produced that map blocks of DSCPs by default to different access categories with different priority scheduling. That is where you need to direct your concerns. It's only because of those default mappings that everyone (including L4S and NQB) is then choosing the most appropriate DSCP to make best use of the scheduling (from their point of view). 
> 
> This might look like dodging blame, but it's not - it's a genuine dilemma due to having to cope with the imperfect world we find.

	[SM] Sorry, that is no excuse for advertizing the use of AC_VI as it exists today for capacity searching traffic. Really go test it. I have flent runs that show that a macosx client using AC_VO and AC_VI will almost completely starve reverse traffic from the AP that also uses AC_VO and AC_VI. Once you start exercising these ACs > BE with more than sparse low-rate traffic you will unearth such behaviour all over the place. The question then is who is going to be holding the bag in the end... All my concerns about safety and functionality of L4S from the wired world carry over into the WiFi space, except there the fall-out range is even larger, all users with sufficient band-overlap with an AP over-exercising higher ACs is going to suffer from air time shortage... You really need to fully accept the shared-medium property without central arbiter nature of deployed WiFi when proposing to use something else that AC_BE for the bulk of the WiFi traffic.

All this is going to lead to is a war of ACs.. if e.g. my DOCSIS neighbors will start to hog all airtime by over-use of AC_VO/AC _VI, I will accept that challenge and increase my AP's and clients default AC to the same AC_VI/VO that the offenders use, this is an arms race nobody can win (but I am not playing for win, I am just playing to stay in the game). Thinking this over, it might be time to implement that feature "adaptive airtime access arbitration" inside of OpenWrt soon.

Best Regards
	Sebastian

> 
> 
> Bob
> 
>> I however note that NQB PHB can support also non-L4S traffic and L4S and NQB don’t have to be linked.
>>  
>> Having read also Greg’s response, I’d like to add that the Home-Gateway market in Germany is deregulated and any WiFi scheduler configuration which isn’t implemented by all vendors serving this market will best be expected absent. That is to say, no IETF standard should specify an undesired behaviour. Deutsche Telekom is able to control BNG policies and L4S might be relevant there, but as WiFi is customer premises, an IETF standardized NQB DSCP shouldn’t result in a fair chance to busy the hotline. Looking at this market environment, Bob’s statement applies in general, L4S requires appropriately adapted scheduling from BNG to Terminating Equipment, and prior art won’t do. That’s a long way to go.
>>  
>> Regards,
>>  
>> Ruediger
>>

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 16 Mar 2021 14:00:25 +0000

And.. for the record. 
I hope that it is obvious for everybody that, even though the title says "5G", the discussion here has left that particular topic a couple of round trips ago 😊

/Ingemar

> From: tsvwg <[email-masked]> On Behalf Of Sebastian Moeller
> Sent: den 16 mars 2021 12:01
> To: Bob Briscoe <[email-masked]>
> Cc: [email-masked]
> >> Thanks Bob, I’m having a clear perception. I appreciate that work is being
> done to implement an L4S WiFi scheduler by one vendor. An L4S scheduler is
> a requirement for all kinds of wireless access, I think.
> >>
> >> I’m also having a clear perception about the fairness resulting if a classic
> transport flow scheduled default on a WiFi access competes with L4S being
> scheduled priority. While I understand that L4S won’t perform as desired, if
> scheduled default on WiFi under adverse operational conditions, it’s not a
> good idea to solve that issue by scheduling L4S by priority on WiFi.
> >
> ECN codepoint is not where the scheduling decision is made. The 'blame' for
> a scheduling decision is where a DSCP or ECN codepoint is mapped to a PHB.
> WiFi access points are being produced that map blocks of DSCPs by default to
> different access categories with different priority scheduling. That is where
> you need to direct your concerns. It's only because of those default
> mappings that everyone (including L4S and NQB) is then choosing the most
> appropriate DSCP to make best use of the scheduling (from their point of
> view).
> >
> > This might look like dodging blame, but it's not - it's a genuine dilemma due
> to having to cope with the imperfect world we find.
> 
> 	[SM] Sorry, that is no excuse for advertizing the use of AC_VI as it
> exists today for capacity searching traffic. Really go test it. I have flent runs
> that show that a macosx client using AC_VO and AC_VI will almost
> completely starve reverse traffic from the AP that also uses AC_VO and
> AC_VI. Once you start exercising these ACs > BE with more than sparse low-
> rate traffic you will unearth such behaviour all over the place. The question
> then is who is going to be holding the bag in the end... All my concerns about
> safety and functionality of L4S from the wired world carry over into the WiFi
> space, except there the fall-out range is even larger, all users with sufficient
> band-overlap with an AP over-exercising higher ACs is going to suffer from air
> time shortage... You really need to fully accept the shared-medium property
> without central arbiter nature of deployed WiFi when proposing to use
> something else that AC_BE for the bulk of the WiFi traffic.
> 
> All this is going to lead to is a war of ACs.. if e.g. my DOCSIS neighbors will
> start to hog all airtime by over-use of AC_VO/AC _VI, I will accept that
> challenge and increase my AP's and clients default AC to the same AC_VI/VO
> that the offenders use, this is an arms race nobody can win (but I am not
> playing for win, I am just playing to stay in the game). Thinking this over, it
> might be time to implement that feature "adaptive airtime access
> arbitration" inside of OpenWrt soon.
> 
> Best Regards
> 	Sebastian
> 
> 
> >
> >
> > Bob
> >
> >> Having read also Greg’s response, I’d like to add that the Home-Gateway
> market in Germany is deregulated and any WiFi scheduler configuration
> which isn’t implemented by all vendors serving this market will best be
> expected absent. That is to say, no IETF standard should specify an undesired
> behaviour. Deutsche Telekom is able to control BNG policies and L4S might
> be relevant there, but as WiFi is customer premises, an IETF standardized
> NQB DSCP shouldn’t result in a fair chance to busy the hotline. Looking at this
> market environment, Bob’s statement applies in general, L4S requires
> appropriately adapted scheduling from BNG to Terminating Equipment, and
> prior art won’t do. That’s a long way to go.
> >>
> >> Regards,
> >>
> >> Ruediger
> >>
> >> Whoa! NQB is not L4S traffic. NQB is a Diffserv codepoint. L4S is identified
> by the ECN field. In DOCSIS the NQB Diffserv codepoint classifies into the
> /same queue/ as L4S traffic (renamed the Low Latency queue due to its dual
> role). Allowing in unresponsive traffic was only considered in DOCSIS because
> there was already a sufficient policing function in front of the queue (per-
> flow queue protection).
> >>
> >> ==Mobile==
> >> If a mobile operator (or in this case a masters student), uses the ECT(1)
> codepoint to classify traffic into a priority bearer, then it's not L4S. It's an ECN
> codepoint intended for L4S but used (abused?) in a Diffserv priority
> scheduler.
> >>
> them. So if there are M L4S flows and N Classic flows, M and N can take any
> value, including zero. That's because the coupling makes the two queues
> appear as one - from a bandwidth and congestion control perspective
> (approximately).
> >>
> need to go back to using traditional Diffserv techniques like guessing what M
> and N might be most of the time, to decide how much bandwidth to
> congestion control algos or queuing behaviours, like L4S standardises for
> fixed line schedulers. And how to operate a network, if these are absent.
> >>
> mechanism (obviously), specifically the DualQ Coupled AQM (or FQ). How to
> operate a network if L4S is absent - well, you go back to what you had
> before. But then you can't support applications that need consistently low
> latency /and/ the full available bandwidth, which is the point of L4S.
> >>
> >>
> >> ==WiFi==
> based PHB". This is because NQB is having to cope with the WiFi situation as it
> finds it. It's not ideal, but you'll see below how it could evolve to something
> better.
> NQB just needs to be isolated from bursty traffic - it didn't choose AC_VI
> because of any need for /bandwidth/ priority, per se. NQB should work with
> quite weakly weighted priority as long as it's isolated. But that wasn't
> available in current WiFI.
> >>
> >>
> >> L4S is also walking into the WiFi environment as it finds it. With today's
> non-L4S products, I would also recommend that the L4S-ECN codepoints are
> mapped to the video access category, if possible.
> >> Nokia's latest WiFi products (in the 'Beacon' range) already include an L4S
> DualQ Coupled AQM. And as other L4S WiFi products come out, the coupling
> will introduce the recommended congestion signals that can be used as back-
> pressure against the priority scheduler. Users don't want to abuse scheduling
> priority at the expense of the balance between their own applications. But
> they have no choice until there's a mechanism that allows their applications
> to balance against other apps.
> >>
> development of a DiffServ scheduler on packet layer combined with a
> default scheduler below. It seems to me that 3 GPP choose different
> >> Cc: [email-masked]; [email-masked]; [email-masked];
> more but poses some additional concerns, where the use of a DBS scheduler
> is one extreme in this context. There are other alternatives such as increased
> scheduling weight that has a more limited impact on other traffic that runs on
> default bearers.
> Additional methods can be needed here to avoid that one bearer gets
> unduly large share of the radio resources.
> >>
> >> /Ingemar
> >>
> >> That depends. For WiFi, draft-ietf-tsvwg-nqb-05 specifies mapping L4S to
> a priority bearer based PHB. Then this stops to be an L4S problem. I’d like to
> congestion control algos or queuing behaviours, like L4S standardises for
> fixed line schedulers. And how to operate a network, if these are absent.
> >>
> >> Regards,
> >>
> >> Ruediger
> >>
> >> Von: tsvwg <[email-masked]> Im Auftrag von Ingemar
> Johansson
> >> S
> >> Yes, there was a test with the use of the dedicated bearer (DBS) and no-
> L4S. This is exemplified in section 5.3.6 in the thesis report. In short the
> mechanism when prioritized bearers are used, but this is of course not only
> an L4S problem.
> >>
> >> /Ingemar
> >>
> >> *
> >> http://www.diva-
> portal.org/smash/record.jsf?pid=diva2%3A1484466&dswid
> >> =-2512
> >>
> >>
> >> CYBER SECURITY WARNING: This email is from an external source - be
> careful of attachments and links. Please follow the Cyber Code and report
> suspicious emails.
> >> tsvwg,
> >>
> >> And I think you'll need to explain where the UPF is typically
> >> located. I believe it's close to the edge, isn't i?
> where they are located, they can be real close to the base stations or >100km
> away.
> >>
> >>
> >> #6 Question:
> >> like PIE or CoDel was used?
> >> #12: L4S is meant to greatly reduce the throughput-delay tradeoff,
> >> and in our results it did.
> >> speed' fast problem (that I'm working on with Joakim).
> configured lower but then the video frames (RTP packets) are more likely to
> become queued up in the sender instead. I really believe that it can be done
> reason is that the large buffers with Cubic absorb the fast fading dips in LTE
> and NR. With DCTCP + L4S some extra headroom is needed to avoid queue
> build up.
> >>
> >>
> >>
> >> Bob
> >>
> >> --
> >>
> >> Bob Briscoe
> https://protect2.fireeye.com/v1/url?k=0cc72809-535c124c-0cc76892-
> 867b36d1634c-7a8fce5d5cf6c799&q=1&e=fc65dd24-5896-4c96-b5bb-
> 53165a19839c&u=http%3A%2F%2Fbobbriscoe.net%2F
> >
> > --
> >
> > Bob Briscoe
> > https://protect2.fireeye.com/v1/url?k=87b7b840-d82c8205-87b7f8db-
> 867b3
> > 6d1634c-2d566c73105d61db&q=1&e=fc65dd24-5896-4c96-b5bb-
> 53165a19839c&u=http%3A%2F%2Fbobbriscoe.net%2F