Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)

Sebastian Moeller <moeller0@gmx.de> Wed, 24 March 2021 16:31 UTC

Return-Path: <moeller0@gmx.de>
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 AAF843A303C for <tsvwg@ietfa.amsl.com>; Wed, 24 Mar 2021 09:31:46 -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, 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 ohfUwB0ClCjH for <tsvwg@ietfa.amsl.com>; Wed, 24 Mar 2021 09:31:42 -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 0D3213A3037 for <tsvwg@ietf.org>; Wed, 24 Mar 2021 09:31:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1616603498; bh=Im5iJJSA2OxtbAnv8uJ9mS8ApxOtLuDLfoAd9xZq4B0=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Z05N9JUJ/CbqxzozkNvHW5yEnBuI/BWLc82vT4jx2zepnslBr7WsZGVibRkhFKpzI Uj+EAV6VSgBwaHCeKaueQSCj0wumvRKiMFssmyVDalwe1mOB51vcm7++y93YPHTacB n+ShQ5bO1uLN+6daXVwRJfv9pMM77xMwDIFQzYgo=
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 1N3siA-1lpXFi2Cyu-00zpe5; Wed, 24 Mar 2021 17:31:38 +0100
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <FRYP281MB0112089D36315C1B870D27279C639@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM>
Date: Wed, 24 Mar 2021 17:31:37 +0100
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsvwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <AFEB34B2-707F-49A8-94BF-DCEB29DC02DA@gmx.de>
References: <HE1PR0701MB2299CB5A933F0C4BCB121F70C2639@HE1PR0701MB2299.eurprd07.prod.outlook.com> <8C9A54B1-8ACF-461E-B8F1-A6ED240870B5@erg.abdn.ac.uk> <145B3C2A-86CC-40ED-9F3B-7DE80D64D150@gmail.com> <f1ad733bde4cbc8da6bccac7a7535b805fff86e9.camel@heistp.net> <6cfad69b-dba8-609a-7f65-b24afcf17df1@erg.abdn.ac.uk> <MN2PR19MB404550070C30B6B314B5A2C083639@MN2PR19MB4045.namprd19.prod.outlook.com> <5832d95c-454d-3bb3-3b25-adf47747ef45@erg.abdn.ac.uk> <FRYP281MB01127FA1395F5CD82E3B76E79C639@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM> <c350d7e2-3fce-81c6-6e01-1f90eaf22e56@erg.abdn.ac.uk> <FRYP281MB0112089D36315C1B870D27279C639@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM>
To: Ruediger.Geib@telekom.de
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:ulaMebujSdhes5Rc13RMniZiFWhuq/iN+zPn9CN+cDZUJuUVURo RIpHRyqJbkCjNtOPWPAN7kd/9ocbdQ1AT8e/UXFZeZ3Bp3hW+8k6265Y5OlHlsyuFj4I05u yW0np0SrMTSZeGWQqvhXjo2ZZPDMC72wkoE/jsorHP7/NNigi+Z5CZNLKHFbTmMMyIKzkbW wYrQVVDqvkNINCCn2hN2Q==
X-UI-Out-Filterresults: notjunk:1;V03:K0:zu4LHqncO54=:x+7tj9pc9pvcXlPIqhQNsb nNeUpE05412kgYjpYbcJhc+3sZInn363u2aj6ycjCIXPVXlXMGQjV5XmSnzqez4s/RlSslENl y9ARHoQq4ueUcJhGDEsucmsCqbGTqEWom7k1CyvQkGjLP7U5FuetoE+GPUPDhIbjK0SLjTLPp euHPmbjbcJl7iLkNdI306O6AFIsz8qEeCyMepfgER/4g2ZuB9zDy6whEWsSHZMAfaaf5xknMl g4dpTpdVVmvOMkP01Er3SGll6UD8jlK0nmLMS7trlZYYq0UREW1ziBlb0E9ZdWsITf2sXoo5/ 0mMNY55KJAdYNoKGxc7jY7sjp9ixwzdISxd0JS/HJv6Aaqbb3qBl3d9IxHTWodR1FRJGbjCZR V1z2NYpWHHE1SeOm/vHuGyB5bn1rAXfkDb55rh6Fphv4zPe/8MBlRFPRDahVfP/SH9tOUg/rU ccenFOpDRhz+mZyaeOdzAvAWkfpyKUtbsrNoM3zA5pxWzZLlKzCNztzHpQh58B37s1CdCtccG 54zrZBOJ0/2ySnMne33D8ap61Riz363/bkgsNDt9/h7WBb+eJPueHtOKo97iVpNH7UFmdnE6c /UUMAOxqvsAMcNmf8iA/x616YITduISqorDVGH9qJ03/nXDhTj6j/tpFivMiUb1CPhatVLzvi lt14v5Pfp5VnnF5U10wLfu8JsYIlSXLS9lYiW+HWBCzLKTJfkU0/z/3DCf8AOyWFZfCofAXk4 E9A/Cn0WfoBPtS77qKL55nIQPsrWoKtthihozqkGC8HtoE7svBi+AjvE9HqsJgXzf0Y3ZdaXi JL/HMR+xrHDCxcYFqWMnsnPvFoT65rNUpfCWk8tS3zZSyozc2/SwMr5y9psHuuIEu5EvcQlDd ui8CrBPX5b6B98677ZSQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/vjwu0um-FY8mXkaTdEgxJfWSsu4>
Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)
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: Wed, 24 Mar 2021 16:31:47 -0000

Hi Ruediger,


> On Mar 24, 2021, at 17:05, <Ruediger.Geib@telekom.de> <Ruediger.Geib@telekom.de> wrote:
> 
> Hi Gorry,
> 
> One detail only, otherwise we are in line otherwise, I think
> 
>> Then innocent bystanders may get hit and a specified DSCP might allow for protection.
> 
> [GF] The bystanders are those impacted by a "CE-marking from a non-L4S router" that is congested, but where the other traffic responds using L4S.
> 
> [GF] Is this any different to the first operator not forwarding the ECT(1) codepoint?
> 
> [GF] I do wonder if this proves a real problem whether the community might deprecate CE-marking of ECT(0) in non-L4S devices, I wonder in future how much hardship this would cause, especially if L4S were to be widely deployed.
> 
> [RG] In the case of an operator sending L4S traffic, the source of a "CE-marking from a non-L4S router" must be upstream of the terminal. That is likely a policy point of the operator or an external network. The former doesn't apply and I doubt that the latter is to be expected. I'd expect the terminals to be deployed for some experiment (and users are either operator employees or friendly volunteers), so the contact with external networks sending "CE-marking from a non-L4S router" might be rare (I'd wonder about that - where's the bottleneck, a peering interface?).


	[SM] Almost, CableLabs has made L4S style signaling and AQM mandatory as part of Low Latency DOCSIS 3.1, the mandate seems to cover both the CPE as well as the CMTS. If the L4S experimental RFCs will be released it is very likely that DOCSIS ISPs will enable these features pretty quickly. After all, marketing for low latency docsis started years ago. IMHO this will en-roll quite a number of users into the experiment that are neither "operator employees or friendly volunteers". In that case A DSCP can do wonders to restrict the reach of L4S signaling to participating / L4S aware networks, as SLAs/TCAs are likely required to make sure that tose DSCP are passed on.

	As I have been told, the experiment in the 4S experimental drafts is not about safety or functionality, but about deployment, I expect mass deployment pretty soon. A DSCP during the experiment to reduce the "blast radius" seems like a cautious engineering approach to me, but then I am not an engineer. Also it will be considerably easier, in case I was too pessimistic, to remove the guarding DSCP requirement if L4S is successful and should be elevated to proposed standard status, than introducing one at that point, when mass deployment is already in process or even mostly finished.

Best Regards
	Sebastian


> 
> Regards,
> 
> Ruediger
> 
> 
> 
>