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

[Bob Briscoe <[e-mail]>]

Ruediger,

On 16/03/2021 08:12, [e-mail] 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 <[e-mail]>
> *Gesendet:* Montag, 15. März 2021 19:06
> *An:* Geib, Rüdiger <[e-mail]>; 
> [e-mail]
> *Cc:* [e-mail]; [e-mail]
> *Betreff:* Re: AW: [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.
>
>
> 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, [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/