From nobody Tue Mar 16 04:02:00 2021 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0298B3A21BE for ; Tue, 16 Mar 2021 04:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mMeKZp3Lvu1 for ; Tue, 16 Mar 2021 04:01:55 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5E43A21BC for ; Tue, 16 Mar 2021 04:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1615892463; bh=k1pO1GA3p4cYTRiJ45J4aqpZ2fJiGcdT3SseyhTpmuI=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=iY56tEKGt9+XOWC7KFvnYVNKoE+yUjtwhF+Rrgmz9t+ED+rkPHa+JDzLdihKholOR nM9wT5Fd+juZktFiaPs4ECHIgfmmGD33drilEakthf6W2P2VlVqZJs5zmZO2vChu00 mE1MFJPJRM4nk4axhSEWu4px/W4BRDlcAZ/5OFow= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.250.106] ([134.76.241.253]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M7sHo-1lIHhF0wPS-0050NK; Tue, 16 Mar 2021 12:01:03 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Sebastian Moeller In-Reply-To: <45800ec4-da57-5172-2b9b-c87e82d0b891@bobbriscoe.net> Date: Tue, 16 Mar 2021 12:01:00 +0100 Cc: Ruediger.Geib@telekom.de, "g.white@cablelabs.com" , tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <691D1916-2CB1-467B-A5AA-9DC34B6F5682@gmx.de> References: <4cf84500-756f-9da9-81d2-b29e1aebad4a@bobbriscoe.net> <2a79bd1d-dae9-6e91-55ee-0af586527fbd@bobbriscoe.net> <45800ec4-da57-5172-2b9b-c87e82d0b891@bobbriscoe.net> To: Bob Briscoe X-Mailer: Apple Mail (2.3445.104.17) X-Provags-ID: V03:K1:YY0o4972Tvsa09DH3Jl4e7wwwTwdXvjp/FdO68ngs2Aolfw7AWm YXYKtrZs96rg6dJDHM09lcS4i+HFVKfqmuUWlGG4Fj/E9vevNzLBdEYykbvvvv505nnSTlo xCrHATbDHMsv/SqjcC+TW5h5fhHm8NE3J/1shZsc1ySdPFiRqOM07nxJdXX+f19Ota24RU2 JlZmCMRIx8pbXEzrMfvfA== X-UI-Out-Filterresults: notjunk:1;V03:K0:veBBtkb572E=:vMk3UhzBTH2lo4wGb6PAIU 6hOVDPgY7hONUO/5xJOjP/1zqsONj/g2gDkgkppwNFULoEUrIFed3yIApNUhelXSiKdsVuW+t 8kuE/xAMEZqiB6f4y7wRgvZHYbr3c2+RT4DFaWuC8CjeoZ57QhfRTsE6yiMbBkszk8XBua9mD 6WzfF71Gwktq5ESYlLRDIQ80htxbDgCBTFtOeVLbc00vDzeUEuKYKcnGy50T4DTwvA1fCPyoK CfehYaxuy+wzKY8zXes/qQ8Xc29pdWzhZQuBS7zqp+Fbqcz+zRwGlVvn/r2yHZcP9fQimjeMG l258RMUxOHRw6YBpta3Dv41iyOP6CWbV/Me/PNpBCjI/C7VXbRjLRqbzrexRzYC+RbwkBygzx sKNedxMoCfHUoDuZUCtnDVdswpGHAGkH0deXR4op9pb6pg7Fv2MP2VVEfrbaw5JOl74/fedct 4Uyx3q87MmotSdRk/PLyzhG4DJvpGII62smMh1jhUROceQZnoVE4KGMhwjJ3/sMR6C9LuhvkM 9E/yu6K7H0kxYTYObhtiF+xdfhZKGlqDMxzJs9Ar0aw0uguJzwvwKQhfPCBAn3hO93wZ0/QRi /KEuj+nciIKGDHrac8+67wdegCLyvRiZQvXJrMlqV600uw3+lg6684D3W9MRJVnL8eld1e9d6 XleMubI8/YSjNXVzNMnNYn/VKbeba2SvmOfC9xtMcswI23U5A2mZfz9IaRc5hXNmp1NwL6mSL 5FlYfWzTEH1s8gpDbFSa1auV8pPqn4UmNdxhy1jYs/y4J+IJKFnb22qKfTihLZAnpUT+QGaB8 MVA/V/cdBPFTxOGRdQJdmm21R+iflXyT3T2A4+QI9gleD5afO+lr/wWTQ4rsAkE3arzMt8p4U +XYG79jL83wtrHM1nF1Q== Archived-At: Subject: Re: [tsvwg] Fwd: Qs on your 5G L4S slides X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 11:01:58 -0000 Bob, more below prefixed [SM]. > On Mar 16, 2021, at 11:48, Bob Briscoe wrote: >=20 > Ruediger, >=20 > On 16/03/2021 08:12, Ruediger.Geib@telekom.de wrote: >> Bob, Greg >> =20 >> Thanks Bob, I=E2=80=99m 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. >> =20 >> I=E2=80=99m 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=E2=80=99t perform as desired, if scheduled default on WiFi under = adverse operational conditions, it=E2=80=99s not a good idea to solve = that issue by scheduling L4S by priority on WiFi. >=20 > [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).=20 >=20 > 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 >=20 >=20 > Bob >=20 >> I however note that NQB PHB can support also non-L4S traffic and L4S = and NQB don=E2=80=99t have to be linked. >> =20 >> Having read also Greg=E2=80=99s response, I=E2=80=99d like to add = that the Home-Gateway market in Germany is deregulated and any WiFi = scheduler configuration which isn=E2=80=99t 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=E2=80=99t= result in a fair chance to busy the hotline. Looking at this market = environment, Bob=E2=80=99s statement applies in general, L4S requires = appropriately adapted scheduling from BNG to Terminating Equipment, and = prior art won=E2=80=99t do. That=E2=80=99s a long way to go. >> =20 >> Regards, >> =20 >> Ruediger >> =20 >> Von: Bob Briscoe =20 >> Gesendet: Montag, 15. M=C3=A4rz 2021 19:06 >> An: Geib, R=C3=BCdiger ; = ingemar.s.johansson@ericsson.com >> Cc: Kevin.Smith@vodafone.com; tsvwg@ietf.org >> Betreff: Re: AW: [tsvwg] Fwd: Qs on your 5G L4S slides >> =20 >> Ruediger, >>=20 >> =3D=3DDOCSIS=3D=3D >> 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). >>=20 >> =3D=3DMobile=3D=3D >> 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.=20 >>=20 >> 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).=20 >>=20 >> 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.=20 >>=20 >> To summarize, the answers to your question: >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >> =3D=3DWiFi=3D=3D >> 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. >>=20 >>=20 >> 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.=20 >> 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. >>=20 >> Finally, once there's an L4S queue in WiFi kit, NQB traffic could be = classified into it, as was done in DOCSIS. >>=20 >> FQ offers an alternative path for WiFi - neither precludes the other. >>=20 >> Does this help explain? >>=20 >>=20 >> Bob >>=20 >> On 15/03/2021 11:19, Ruediger.Geib@telekom.de wrote: >> Hi Ingemar, >> =20 >> I=E2=80=99m not having trouble with wireless default scheduling. = I=E2=80=99d 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. >> =20 >> I wonder which scheduling was recommended for 3GPP access types, if = there=E2=80=99s an RFC recommending a priority bearer for L4S at WiFi = interfaces. >> =20 >> Regards, >> =20 >> Ruediger >> =20 >> Von: Ingemar Johansson S =20 >> Gesendet: Montag, 15. M=C3=A4rz 2021 12:08 >> An: Geib, R=C3=BCdiger >> Cc: Kevin.Smith@vodafone.com; ietf@bobbriscoe.net; tsvwg@ietf.org; = Ingemar Johansson S >> Betreff: RE: [tsvwg] Fwd: Qs on your 5G L4S slides >> =20 >> Hi Ruediger >> =20 >> I can=E2=80=99t 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. >> =20 >> 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.=20 >> 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. =20 >> =20 >> /Ingemar >> =20 >> From: Ruediger.Geib@telekom.de =20 >> Sent: den 15 mars 2021 11:48 >> To: Ingemar Johansson S >> Cc: Kevin.Smith@vodafone.com; ietf@bobbriscoe.net; tsvwg@ietf.org >> Subject: AW: [tsvwg] Fwd: Qs on your 5G L4S slides >> =20 >> Hi Ingemar, >> =20 >> 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=E2=80=99d 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? >> =20 >> 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. >> =20 >> Regards, >> =20 >> Ruediger >> =20 >> Von: tsvwg Im Auftrag von Ingemar Johansson = S >> Gesendet: Montag, 15. M=C3=A4rz 2021 10:55 >> An: Smith, Kevin, Vodafone Group = ; Bob Briscoe = ; tsvwg IETF list >> Betreff: Re: [tsvwg] Fwd: Qs on your 5G L4S slides >> =20 >> Hi Kevin, Bob + others >> CC Davide (thesis author) >> =20 >> 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.=20 >> 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. >> =20 >> /Ingemar >> =20 >> * = http://www.diva-portal.org/smash/record.jsf?pid=3Ddiva2%3A1484466&dswid=3D= -2512 >> =20 >> =20 >> From: tsvwg On Behalf Of Smith, Kevin, = Vodafone Group >> Sent: den 12 mars 2021 14:56 >> To: Bob Briscoe ; tsvwg IETF list = >> Subject: Re: [tsvwg] Fwd: Qs on your 5G L4S slides >> =20 >> Hi Ingemar, >> =20 >> Just to ask, was there also a variant of the test with no L4S but = with the dedicated bearer? I=E2=80=99d be interested to see that = comparison. >> =20 >> @Bob, regarding UPF placement: the ability to virtualise network = functions in 5G Core allows easier scaling of UPFs as required. >> =20 >> All best, >> Kevin >> =20 >> =20 >> =20 >> =20 >> C2 General >> From: tsvwg On Behalf Of Bob Briscoe >> Sent: 10 March 2021 17:41 >> To: tsvwg IETF list >> Subject: [tsvwg] Fwd: Qs on your 5G L4S slides >> =20 >> 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, >>=20 >> Fwd'ing to list, with permission... >> In case anyone else had the same questions=20 >>=20 >>=20 >> -------- Forwarded Message --------=20 >> Subject:=20 >> RE: Qs on your 5G L4S slides >> Date:=20 >> Wed, 10 Mar 2021 14:33:42 +0000 >> From:=20 >> Ingemar Johansson S >> To:=20 >> Bob Briscoe >> CC:=20 >> Ingemar Johansson S >>=20 >>=20 >> Hi >> Please see inline [IJ] >>=20 >> /Ingemar >>=20 >> -----Original Message----- >> From: Bob Briscoe >> Sent: den 10 mars 2021 14:46 >> To: Ingemar Johansson S >> Subject: Qs on your 5G L4S slides >>=20 >> Ingemar, >>=20 >> #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 >>=20 >>=20 >> 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. >>=20 >>=20 >> #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. >>=20 >>=20 >> #6 - #11: >> Is the DBS scheduler between users, or between flows? >> [IJ] Per user (bearer) >>=20 >>=20 >> #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. >>=20 >>=20 >>=20 >> Bob >>=20 >> -- >> __________________________________________________________ >> ______ >> Bob Briscoe https://protect2.fireeye.com/v1/url?k=3D828d3ddc- >> dd1604f1-828d7d47-8692dc8284cb-1ab58b5eb7943901&q=3D1&e=3Db0160f51- >> 6418-41ea-9221-efaca6b7cec8&u=3Dhttp%3A%2F%2Fbobbriscoe.net%2F >> =20 >>=20 >>=20 >> --=20 >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >=20 > --=20 > ________________________________________________________________ > Bob Briscoe =20 > http://bobbriscoe.net/