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

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

And.. for the record. 
I hope that it is obvious for everybody that, even though the title says "5G", the discussion here has left that particular topic a couple of round trips ago 😊

/Ingemar

> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Sebastian Moeller
> Sent: den 16 mars 2021 12:01
> To: Bob Briscoe <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [tsvwg] Fwd: Qs on your 5G L4S slides
> 
> Bob,
> 
> more below prefixed [SM].
> 
> > On Mar 16, 2021, at 11:48, Bob Briscoe <[e-mail]> wrote:
> >
> > 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.
> 
> 	[SM] Sorry, that is no excuse for advertizing the use of AC_VI as it
> exists today for capacity searching traffic. Really go test it. I have flent runs
> that show that a macosx client using AC_VO and AC_VI will almost
> completely starve reverse traffic from the AP that also uses AC_VO and
> AC_VI. Once you start exercising these ACs > BE with more than sparse low-
> rate traffic you will unearth such behaviour all over the place. The question
> then is who is going to be holding the bag in the end... All my concerns about
> safety and functionality of L4S from the wired world carry over into the WiFi
> space, except there the fall-out range is even larger, all users with sufficient
> band-overlap with an AP over-exercising higher ACs is going to suffer from air
> time shortage... You really need to fully accept the shared-medium property
> without central arbiter nature of deployed WiFi when proposing to use
> something else that AC_BE for the bulk of the WiFi traffic.
> 
> All this is going to lead to is a war of ACs.. if e.g. my DOCSIS neighbors will
> start to hog all airtime by over-use of AC_VO/AC _VI, I will accept that
> challenge and increase my AP's and clients default AC to the same AC_VI/VO
> that the offenders use, this is an arms race nobody can win (but I am not
> playing for win, I am just playing to stay in the game). Thinking this over, it
> might be time to implement that feature "adaptive airtime access
> arbitration" inside of OpenWrt soon.
> 
> Best Regards
> 	Sebastian
> 
> 
> >
> >
> > 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] 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]>
> >> Gesendet: Montag, 15. März 2021 12:08
> >> An: Geib, Rüdiger <[e-mail]>
> >> Cc: [e-mail]; [e-mail]; [e-mail];
> >> Ingemar Johansson S <[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] <[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]> Im Auftrag von Ingemar
> Johansson
> >> S
> >> Gesendet: Montag, 15. März 2021 10:55
> >> An: Smith, Kevin, Vodafone Group
> >> <Kevin.Smith=[e-mail]>; Bob Briscoe
> >> <[e-mail]>; tsvwg IETF list <[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
> >>
> >>
> >> 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]> On Behalf Of Bob Briscoe
> >> Sent: 10 March 2021 17:41
> >> To: tsvwg IETF list <[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]>
> >> 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
> >>
> >>
> >>
> >> --
> >>
> __________________________________________________________
> ______
> >> Bob Briscoe
> https://protect2.fireeye.com/v1/url?k=0cc72809-535c124c-0cc76892-
> 867b36d1634c-7a8fce5d5cf6c799&q=1&e=fc65dd24-5896-4c96-b5bb-
> 53165a19839c&u=http%3A%2F%2Fbobbriscoe.net%2F
> >
> > --
> >
> __________________________________________________________
> ______
> > Bob Briscoe
> > https://protect2.fireeye.com/v1/url?k=87b7b840-d82c8205-87b7f8db-
> 867b3
> > 6d1634c-2d566c73105d61db&q=1&e=fc65dd24-5896-4c96-b5bb-
> 53165a19839c&u=http%3A%2F%2Fbobbriscoe.net%2F