From nobody Mon Mar 15 15:38:32 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 84C373A116A for ; Mon, 15 Mar 2021 15:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 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, 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 V2Arrh3vBT5t for ; Mon, 15 Mar 2021 15:38:29 -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 C19923A1167 for ; Mon, 15 Mar 2021 15:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1615847858; bh=80r9c5d25vaHqV6V92XBsPlLJJlqsKXPm/7FqeIHqKY=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=cnSq9zXRttqY/iw/9atZk6mOWBsyz+hu36j+7NoBbvUMly3CUcKu4AJ5NyO/NTuSn Jo8gZr+G7JEMVeJK7LxX/Qi4+H2rze096bW9lBI+HLylOKk1h3XB1CdEScXAGFlcqs 0t2dEpbAMbJwMlWCD7RnHRLX6PslLa0tsNUs7GgY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.42.229] ([77.3.26.131]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MD9X9-1lUQ9Q348v-009AG4; Mon, 15 Mar 2021 23:37:37 +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: Date: Mon, 15 Mar 2021 23:37:36 +0100 Cc: Bob Briscoe , "Ruediger.Geib@telekom.de" , "ingemar.s.johansson@ericsson.com" , "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <4cf84500-756f-9da9-81d2-b29e1aebad4a@bobbriscoe.net> <2a79bd1d-dae9-6e91-55ee-0af586527fbd@bobbriscoe.net> To: Greg White X-Mailer: Apple Mail (2.3445.104.17) X-Provags-ID: V03:K1:YAySgih55mxeEOWoIT0wQZ3to0SpC8XvlD9iymiDFirfo472+AX xnpaA/txrzN0+BnicnsCfvBjNXHqRl6zqUQTwvxv8Hsq0i+ifPygjftGHNcEZ+Od5Ikx6DI cy4naHH92zzKkEQ2w89MTy+2YbPYGbQorL3ZZFHs4NFi1X1HEvhRszSzaTXko6MOEb6ApVc R4yPrLhAQK1aPDbApHvlw== X-UI-Out-Filterresults: notjunk:1;V03:K0:Z3hjdS9Mlww=:glPFhgL7pMKFGoSummvaJL BE0ed0vejXGZG9jj1r72QHaHqPMgzc9HOQWBo3VtsnRpMzUofKLHKyDacJ9JZfeN6ZU+96TOO vRfjKsGFcF1DXLIClHA8uSQqcKPsvPWBM0qwv9mVYudit3HZq8oH3V9jyhnJD6QUsjJjNdmct 3l+0POhuA98JaJ0J0be5qBkkHHTliotklPpwrUU4Z6k79Srg+ysfPB8euzmA0A+f3oEvwJ1XH HkVyfJF5Ekq97Q1m/ORDoYc6nrQINKhLWUVZc0L1oWCanCk7PEleSBoimT4MFCdzzq/DoaBj8 5ES5Z/XvP1vkaTHUum4X7A2jPNHNdd9LF3z6buKxmwxuAvvW1d4SDd84mmLJ8AHHnwBv0k16N kRcNJZRafIJir/d392iashmryzgobqKxTi3Z25u/FunUUYJpl1EteWLFTI39DnS4vphFYxQ73 jkSQM2oi/jF6zq/Ltyjzp+hqY03HzApDO+My3ZbQiHv0iNbnva+3DXDugyDOxVFiR9ZN8oGvf iFswZjETUAm0nrNTNUf+bBIUAhzIAOszNcNFYklhxx0VJK3eyJeyXqhX+EAeGVErPwXdMVPJ9 0cfy2786R6YOXDGwiO/f7lRrPktAQ43mYDJoSmS9bkW4pjtUH1P1ynvpKE33HSuOwlQwTcdxk 5TTp0rDtozNvzvYHFswtvoOJ5f7xCcvr9cxEOpMzOZmNASkyC0mkwgtKQ1h7jdKx8VI2DmwRE GNQQsoV8mMwzOBT88pc18YQWlBPrL0SAdkaBYcUbG4puG8q+reQC/coBpFiYggqSHObTLBBwi 1nQ7j8Agfag5R9XarX2nGbPXnFb0EH5BAWpTagnl1BzPbQRka6mvu+xeTlZtCGv2AwSbGiuav CAfOFp8M9aU1ViP+oBDA== 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: Mon, 15 Mar 2021 22:38:31 -0000 Hi Greg, see [SM] below. > On Mar 15, 2021, at 22:57, Greg White wrote: >=20 > Inline [GW]. > =20 > From: tsvwg on behalf of Bob Briscoe = > Date: Monday, March 15, 2021 at 12:06 PM > To: "Ruediger.Geib@telekom.de" , = "ingemar.s.johansson@ericsson.com" > Cc: "tsvwg@ietf.org" > Subject: Re: [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 > [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). [SM] Which is sweet, but for almost 100% of deployed APs that is = not going to happen, not eve the tinker friendly opensource OpenWrt APs = allow to change the weights of the ACs. > 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. [SM] But we all know that this recommendation will not actually = to changes in a noticeable number of already deployed APs. Let's not kid = ourselves that the update problem magically disappears just because it = would be nic; this does not work for safety fixes, why should it work = any better for new features? >=20 > *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=E2=80=99t provide a separate = queue. [SM] Again sounds sane, unless we look at the deployed base. >=20 >=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 >=20 > [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=E2=80=99t easily = be coupled to the VI queue in another. [SM] Not that I want to defend ab-using AC_VI for L4S (as I said NQB = with its aim for low rate flows has some justification for using AC_VI, = assuming sufficiently strict admission control), but back-pessure in = WiFI between all entities only happens via airtime access and that means = you mainly compete with senders using the same AC, no? >=20 >=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. >> 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/