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

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Tue, 16 March 2021 14:00 UTC

Return-Path: <ingemar.s.johansson@ericsson.com>
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 4609E3A0E91 for <tsvwg@ietfa.amsl.com>; Tue, 16 Mar 2021 07:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 N9VGvp2UF57D for <tsvwg@ietfa.amsl.com>; Tue, 16 Mar 2021 07:00:30 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150089.outbound.protection.outlook.com [40.107.15.89]) (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 AC07B3A0E93 for <tsvwg@ietf.org>; Tue, 16 Mar 2021 07:00:29 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KKeO0wLFyXRXQk/lxcokjbbOYYPWDNvqqGTz6/u8jQLqe8dwkg2+ZpAH5K4efq37dnJqEnUOh9xKv3NVcw6UjgrdLpe1+vz9N+3Eh5OAJdhz8kq1JWyi6rzRQspACgN8lkQxHnUrQnn5k58UHI58VDYRiBcqfvHMCcvwxMYy436wOfluMwBMSV0C+Yv2dN5QZVb1VBErMBmiXyxDT7GolPWnDnO21WlORwYaD6HpM3FfJysw+3U4kmwp5LSB9dC7x8aAitXUT1gi9DxljOv5IN/ED1DIC5CaopyD5DeK8F7Tx/DjpYdJUz/D++UlCQm/JDSohsXj00CYqTeEtMFsZw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IvHubqDVt5MIQ9kgf9KIHKLZIdma9ZfhMoj0D379fyM=; b=QyJ8LZZ+T6eYQSLlwuMcmcB81xYQJQK26ZWf8Y9MAA9fl+vDRVnb+YLq53TtgmDR40sBJV8cEMvvxh+9IYfpjzC6fi6GjQWg4vhwnoVYhXym/vSUtcoWANA1+YBlGF7PF22SKnHYK4MtzE7j4lu8Ia4P6OfLWhqn8+SF86AgMfEseP2oW7Hk055Iop9u8kNiTfLdo24KillUY2E2VzzM0fMBBjWsL/74G3+8y69Ptm5OQ44FJpQ7k7/SrKen7el1ghEPSOD3B4HS9pOs2/HVH4IHcQltD74fUIEtwGGCiJA1s8VFt0XqbXMHUX7xGGkGIbZKIjU+fBA//HY7yjk5wQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IvHubqDVt5MIQ9kgf9KIHKLZIdma9ZfhMoj0D379fyM=; b=AqCDgO+r9MY6PIzK6C/IjqlkQNdiLAvszoWnQOxvirBdimSBxTUR5GZsFIAO6dIkuoFewDaJjVCESOYJ8XibflaUA6oS9cmWZO6un1EUsHowamRZcQ2PIxXBRMM3obNooI+lKCO8az63+EugQaKN8saOq6yV31DHpZCYPtKDxco=
Received: from HE1PR0701MB2299.eurprd07.prod.outlook.com (2603:10a6:3:6c::8) by HE1PR0701MB2747.eurprd07.prod.outlook.com (2603:10a6:3:99::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.11; Tue, 16 Mar 2021 14:00:25 +0000
Received: from HE1PR0701MB2299.eurprd07.prod.outlook.com ([fe80::a087:95cb:e76b:d57]) by HE1PR0701MB2299.eurprd07.prod.outlook.com ([fe80::a087:95cb:e76b:d57%10]) with mapi id 15.20.3955.010; Tue, 16 Mar 2021 14:00:25 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Sebastian Moeller <moeller0@gmx.de>, Bob Briscoe <ietf@bobbriscoe.net>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Thread-Topic: [tsvwg] Fwd: Qs on your 5G L4S slides
Thread-Index: AQHXGlPa3XlquYVbFkqEKveo0JAYaaqGo+/Q
Date: Tue, 16 Mar 2021 14:00:25 +0000
Message-ID: <HE1PR0701MB2299D38DA209B4415A7AA68BC26B9@HE1PR0701MB2299.eurprd07.prod.outlook.com>
References: <HE1PR0701MB22994BB36811BDAB98F464B9C2919@HE1PR0701MB2299.eurprd07.prod.outlook.com> <4cf84500-756f-9da9-81d2-b29e1aebad4a@bobbriscoe.net> <AM7PR05MB7090AB2C98F6EA6328DCFB75916F9@AM7PR05MB7090.eurprd05.prod.outlook.com> <HE1PR0701MB2299229839CFE56847FCAD2FC26C9@HE1PR0701MB2299.eurprd07.prod.outlook.com> <FRYP281MB0112A5CDAEFD57D3E935904C9C6C9@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM> <HE1PR0701MB2299F09181D3D4C9E150E3C5C26C9@HE1PR0701MB2299.eurprd07.prod.outlook.com> <FRYP281MB0112291B8CF0E0745660D8D59C6C9@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM> <2a79bd1d-dae9-6e91-55ee-0af586527fbd@bobbriscoe.net> <FRYP281MB011207C06C3E2B1013CBAA8E9C6B9@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM> <45800ec4-da57-5172-2b9b-c87e82d0b891@bobbriscoe.net> <691D1916-2CB1-467B-A5AA-9DC34B6F5682@gmx.de>
In-Reply-To: <691D1916-2CB1-467B-A5AA-9DC34B6F5682@gmx.de>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: gmx.de; dkim=none (message not signed) header.d=none;gmx.de; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [83.227.122.88]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 355114f0-737e-4d16-0963-08d8e883d931
x-ms-traffictypediagnostic: HE1PR0701MB2747:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR0701MB2747C41DE71DA4C9F43A12C2C26B9@HE1PR0701MB2747.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:1284;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6/1I0FtirzXt/nVSdHkMls1vZmLCOhbmFttnX9plWnCFB3RHk0EjAX2tOrYL08otQRHVS7hE00DMRD9CDz3yGKrwt8rc6ijx0eW/5xWX1phdeGjjwfkX8Wyi1V2wHAvR1QMaTV9nyN/+J8ca+GoNsFn8vzO0vE3jjK6FbqtRiEOHDeP/e+eZ5CiFpl5CSK5vNsrd00eRGwX6qWoH9Yqv53SOa6LyiI7CdshdY9NF1ifqyqsH0/vh/J0lljgZCBldEXSVE3l/Havj/Oey66Sos21JLH1pxJaCyhxTPP7PQ2BJkr8F1P16E/uOgHDSlW1rgOAELe1lThFjZm1cniP2G48kOYb69lYwK823dm5RHBfNykPywzCRh5t74YiImYNHuhEnpy07CUc38FtJCO/gY32B9m0N8zFZCZUs5TsGxEzmj+TANswp5W+1hXElvUpeoPUJmPyTEDjL+NC11SBnEVxDYVwMOH94Uk5cJIAtp+3mUyQkPfH9C/RtvyERinoMIrnCOCC7TVnU5nFJSJuJ2noHHavvgSQoN7/FOlPN/ZqPb6hSDjtL/0TqV3cIUgGKPTT7SJUVcsq8tbdHXybr/yAmoWNuB5TaBjw1g8MF0NPXbrTzwfWSK4c/Z3CLlfH/fuMpW4RG0S1/OK20y7Exsw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2299.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(136003)(346002)(366004)(396003)(316002)(52536014)(26005)(5660300002)(99936003)(53546011)(66574015)(4326008)(66556008)(64756008)(54906003)(6506007)(8936002)(66446008)(186003)(8676002)(71200400001)(7696005)(2906002)(966005)(9686003)(86362001)(55016002)(110136005)(66616009)(76116006)(66476007)(33656002)(478600001)(83380400001)(30864003)(66946007)(107886003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?Sk5TOFBpYjJ0VTdhdVloblk1cXZ2eTVmWG9IcVVtUktiT3Q1c0tRWlNJREhP?= =?utf-8?B?QWJUdFhQVWRZcVBLZHl1YSs4cjM4bTgxOWNvZ05EczVPWG1MSHdaVWNwZ3gy?= =?utf-8?B?N1lSc3RVSy9pamQ4bC94WDFqUFp1TklVQXVZNEVEOEtHQ3U2bkwrWmJYWXV5?= =?utf-8?B?QUxHTXhrQXF3dlEzdS9WY09oNnhIaU9hOVhrTmY3MUI1N2NDaUdoOXd5NnFt?= =?utf-8?B?WUpKUHRjUzNtRUwyTDRwVmY2bTlnK21iY25ITU96L2dtbWNJaWQvaitPY0Ey?= =?utf-8?B?bkhJMWl3dFhmQndQK3RSZkExU3JTVms2YnFmREVFRGtXT0xaYUx0bGc1Yytz?= =?utf-8?B?K3dkQWx4K2hKKzQrOG9KVlIyUUlhcUswbzdnM2htbDZFSElRaC9FM05Sb3FY?= =?utf-8?B?WlQwSEk1TkpGa1hwQnZtK3BxaTRMejFuRUl2VVAzeTBJT2dYbVgyc3BPK0Fk?= =?utf-8?B?S1BlbTZQMUYxOHZGYkF2MWo3ZEpHdGwyK0dXMDZ2OE5LcmxzOGxhZHVpT2tQ?= =?utf-8?B?UjgrNEdOcE5sb2M2MTNZWHJMMGlWNGhoMXhiNWZINFJSVjlYT25jeTkrNm9N?= =?utf-8?B?aWNJRUhMSEVyNis5TFlWME5Cbm0wQ0tNaWNYQ3VaOGFsVU5rNG9KYU05NVR0?= =?utf-8?B?b0lIN0xzL3Boa1NVbHE3STR3STJ0VFEwc2wwYitVLzdvYm1ncWlTK0NwdDRZ?= =?utf-8?B?WE9NK015TVBHOEt4QlV4TWZRUWF6K0E5RkVjT2NRMzc5S3NzM3UvbGZpQzds?= =?utf-8?B?a0tZanNLL0tCQ1Z4b1pIU3Y4TVFBZERoWm5PaGo2WjJ4WVk4VU53My81TU9x?= =?utf-8?B?cnR2bmNCSzA1MTNiVnY3dVlyL3c2Y3dzeWR4STBwZ1NuZCtOai9SL0oxdktw?= =?utf-8?B?SGYrRDcyU29GY0FJY1ZhZjVHdUpBK3J2T2VvU1BaRW1uZnRaTUVtaU1CTzNC?= =?utf-8?B?WmJnbW5hTnhpMW1TYjlXTUJweXJwUElQK093OGkxODNrRHJ5bHFWaGJWNDVB?= =?utf-8?B?YVFKYjZFN0tiM0duZ2Fockk4c3lsTENINXF1Z0VsYW4xQ002M1FWa2EwaWFL?= =?utf-8?B?QTlySkZXbHR4bDlHNjZQTEh6eFgyM05xN2FEOTFzTnJmZEc0TGNNemlveDVl?= =?utf-8?B?TGh2NUVpaGpCOWtVc0pjN0xlYU0vY1JuMUZUL3ZpUU53L0tUSDZVbUFJaUlv?= =?utf-8?B?dGhjNXpPRXhyMGE2ZXVhbVlENTFNV3RTV2tHMExxajRIeFNjdFo3YlB5aDYv?= =?utf-8?B?c2Q4Q1ViV3FNM3JGT0dZUHcyY1ZwRGZIVmdtbWp5ZTFsL1d3dUZEcWM1S0tK?= =?utf-8?B?L3hydjkrZG1RN3NtTEJpYkFpdlBlUlZnMDcvZmpKMDRWeFROeCtIZ2ZRWTh4?= =?utf-8?B?allnZ04zU1Erd0hmeGJjUnc0ekg0TGhRcGo0RkNqekYxbjEwNkVLSXM0d3J1?= =?utf-8?B?aHQwMFpMUDA5ektkQUdhSVJveStpSWRTdjVRTEhCNUhKRTZwT0V5L2o2b3dZ?= =?utf-8?B?V1FuWkt4MTlscnVTTndlVUgyeFkwRjgyQkhubmRDUHM3OVBQeEl5Z3k2R1ZZ?= =?utf-8?B?T0RyVmRxNWY4QkJJaDlCcjVUNDFNZ0xGendRck5XcERYRXZWMUJwT1ptZ0sy?= =?utf-8?B?WnZ0RXBHa2txb3UxSGtnTWUrSTFhKzBCQ2I2cjdTME5HZHZza21aUmsyeUE1?= =?utf-8?B?Z3MraWVCckVDdjBuSlhCWjdidG1vMmk2cGpma2NIL29HZGpvcUJJWUJXUVla?= =?utf-8?Q?kwEQPwvia8boJw4xW59Ifa0lueJax4IgbYyzn+6?=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0689_01D71A75.17659CB0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB2299.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 355114f0-737e-4d16-0963-08d8e883d931
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2021 14:00:25.3645 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: znI2s2JcnQTcip490/XFabfSas1hhQZrlHNVC4YSsVDkdi0E5VDZbXYQt1+37+1UrTmOVyYB7fLEHTPyD14h4NOCvoi2BFIXgFe4C6r+OUPObi9JY3I/aiOXKJUCI31n
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2747
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/dOGjimj31kaP5WRsyH87xRLyAvc>
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 <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Mar 2021 14:00:33 -0000

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 <tsvwg-bounces@ietf.org> On Behalf Of Sebastian Moeller
> Sent: den 16 mars 2021 12:01
> To: Bob Briscoe <ietf@bobbriscoe.net>
> Cc: tsvwg@ietf.org
> Subject: Re: [tsvwg] Fwd: Qs on your 5G L4S slides
> 
> Bob,
> 
> more below prefixed [SM].
> 
> > On Mar 16, 2021, at 11:48, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> >
> > Ruediger,
> >
> > On 16/03/2021 08:12, Ruediger.Geib@telekom.de 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 <ietf@bobbriscoe.net>
> >> Gesendet: Montag, 15. März 2021 19:06
> >> An: Geib, Rüdiger <Ruediger.Geib@telekom.de>;
> >> ingemar.s.johansson@ericsson.com
> >> Cc: Kevin.Smith@vodafone.com; tsvwg@ietf.org
> >> 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, Ruediger.Geib@telekom.de 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 <ingemar.s.johansson@ericsson.com>
> >> Gesendet: Montag, 15. März 2021 12:08
> >> An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
> >> Cc: Kevin.Smith@vodafone.com; ietf@bobbriscoe.net; tsvwg@ietf.org;
> >> Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
> >> 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: Ruediger.Geib@telekom.de <Ruediger.Geib@telekom.de>
> >> Sent: den 15 mars 2021 11:48
> >> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
> >> Cc: Kevin.Smith@vodafone.com; ietf@bobbriscoe.net; tsvwg@ietf.org
> >> 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 <tsvwg-bounces@ietf.org> Im Auftrag von Ingemar
> Johansson
> >> S
> >> Gesendet: Montag, 15. März 2021 10:55
> >> An: Smith, Kevin, Vodafone Group
> >> <Kevin.Smith=40vodafone.com@dmarc.ietf.org>; Bob Briscoe
> >> <ietf@bobbriscoe.net>; tsvwg IETF list <tsvwg@ietf.org>
> >> 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 <tsvwg-bounces@ietf.org> On Behalf Of Smith, Kevin,
> >> Vodafone Group
> >> Sent: den 12 mars 2021 14:56
> >> To: Bob Briscoe <ietf@bobbriscoe.net>; tsvwg IETF list
> >> <tsvwg@ietf.org>
> >> 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 <tsvwg-bounces@ietf.org> On Behalf Of Bob Briscoe
> >> Sent: 10 March 2021 17:41
> >> To: tsvwg IETF list <tsvwg@ietf.org>
> >> 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 <ingemar.s.johansson@ericsson.com>
> >> To:
> >> Bob Briscoe <research@bobbriscoe.net>
> >> CC:
> >> Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
> >>
> >>
> >> Hi
> >> Please see inline [IJ]
> >>
> >> /Ingemar
> >>
> >> -----Original Message-----
> >> From: Bob Briscoe <research@bobbriscoe.net>
> >> Sent: den 10 mars 2021 14:46
> >> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
> >> 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