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

[Bob Briscoe <[e-mail]>]

Greg,
See quick clarification inline [BB]

On 15/03/2021 21:57, Greg White wrote:
>
> Inline [GW].
>
> *From: *tsvwg <[e-mail]> on behalf of Bob Briscoe 
> <[e-mail]>
> *Date: *Monday, March 15, 2021 at 12:06 PM
> *To: *"[e-mail]" <[e-mail]>, 
> "[e-mail]" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *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.
>
> 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.
>
> [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.
>

[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

>
> 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, [e-mail] 
> <mailto:[e-mail]> 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 <[e-mail]>
>     <mailto:[e-mail]>
>     *Gesendet:* Montag, 15. März 2021 12:08
>     *An:* Geib, Rüdiger <[e-mail]>
>     <mailto:[e-mail]>
>     *Cc:* [e-mail] <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>; Ingemar Johansson S
>     <[e-mail]>
>     <mailto:[e-mail]>
>     *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:* [e-mail] <mailto:[e-mail]>
>     <[e-mail] <mailto:[e-mail]>>
>     *Sent:* den 15 mars 2021 11:48
>     *To:* Ingemar Johansson S <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc:* [e-mail] <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>; [e-mail]
>     <mailto:[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&dswid=-2512
>     <http://www.diva-portal.org/smash/record.jsf?pid=diva2%3A1484466&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 <[e-mail]>
>     <mailto:[e-mail]>
>
>     *To: *
>
>     	
>
>     Bob Briscoe <[e-mail]> <mailto:[e-mail]>
>
>     *CC: *
>
>     	
>
>     Ingemar Johansson S <[e-mail]>
>     <mailto:[e-mail]>
>
>
>
>     Hi
>     Please see inline [IJ]
>
>     /Ingemar
>
>         -----Original Message-----
>         From: Bob Briscoe <[e-mail]>
>         <mailto:[e-mail]>
>         Sent: den 10 mars 2021 14:46
>         To: Ingemar Johansson S <[e-mail]>
>         <mailto:[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
>         <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
>
>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/  <http://bobbriscoe.net/>

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