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

[Ingemar Johansson S <[e-mail]>]

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: [e-mail] <[e-mail]> 
Sent: den 15 mars 2021 11:48
To: Ingemar Johansson S <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
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 <[e-mail] <mailto:[e-mail]> > Im
Auftrag von Ingemar Johansson S
Gesendet: Montag, 15. März 2021 10:55
An: Smith, Kevin, Vodafone Group <Kevin.Smith=[e-mail]
<mailto:Kevin.Smith=[e-mail]> >; Bob Briscoe
<[e-mail] <mailto:[e-mail]> >; tsvwg IETF list
<[e-mail] <mailto:[e-mail]> >
Betreff: Re: [tsvwg] Fwd: Qs on your 5G L4S slides

 

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 <[e-mail] <mailto:[e-mail]> > On
Behalf Of Smith, Kevin, Vodafone Group
Sent: den 12 mars 2021 14:56
To: Bob Briscoe <[e-mail] <mailto:[e-mail]> >; tsvwg
IETF list <[e-mail] <mailto:[e-mail]> >
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 <[e-mail] <mailto:[e-mail]> > On
Behalf Of Bob Briscoe
Sent: 10 March 2021 17:41
To: tsvwg IETF list <[e-mail] <mailto:[e-mail]> >
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,

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  <mailto:[e-mail]>
<[e-mail]>


To: 

Bob Briscoe  <mailto:[e-mail]> <[e-mail]>


CC: 

Ingemar Johansson S  <mailto:[e-mail]>
<[e-mail]>



Hi
Please see inline [IJ]

/Ingemar

-----Original Message-----
From: Bob Briscoe  <mailto:[e-mail]>
<[e-mail]>
Sent: den 10 mars 2021 14:46
To: Ingemar Johansson S  <mailto:[e-mail]>
<[e-mail]>
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