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

[Bob Briscoe <[e-mail]>]

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 <[e-mail]>
To: 	Bob Briscoe <[e-mail]>
CC: 	Ingemar Johansson S <[e-mail]>



Hi
Please see inline [IJ]

/Ingemar

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