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

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

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