Re: [tsvwg] L4S, DSCP, and RFC-4774 Option 2

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Wed, 24 March 2021 13:07 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 8EF8C3A2C5E for <tsvwg@ietfa.amsl.com>; Wed, 24 Mar 2021 06:07:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.352
X-Spam-Level:
X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.251, 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 54eOzuZ2O8Pb for <tsvwg@ietfa.amsl.com>; Wed, 24 Mar 2021 06:07:02 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40085.outbound.protection.outlook.com [40.107.4.85]) (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 1DDB43A1186 for <tsvwg@ietf.org>; Wed, 24 Mar 2021 06:07:01 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OYlG3OhS5L3bAyCKABtr9xow0q5626CDrS/bF2HXhSdiDbLWeTYLAK5CTtcHZSnogZp1HxNrcmBIjUF7VaubUP19dcLSgqenGxXexMAYkMCwTvRduE1W2iiFGWEl6rfKFulClrTkzXSj5XPSEWyUIp8QCmPGWFAvpc0Xo88O4yudUuZyR1ORcsSAcS+GHFhBDeT6EGjN4XjSV629TU/yXiSYwJSubsmW35YV1OlFkWvVx0jAPlTj84Bi1oHSfubTqrkSDGnNEK4J2dz9k0J0UXyLNX3MlCDUROleVkoaQQTmzJEEEomMkaDw+o3iJVe/sCx+IIsyJ7NRKl2cjEzpCA==
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=X/bDpJfGh2Z/ENT+c8uezX5eaHdhNyIfCo9MF3sPkBg=; b=YBt49RhWKHWXu30dIXKGVJyGUWFQblQQAxQxAVJi7AqMOQ0vjTF5jviJFtiozUVp/qaqcP3HBJiu0RLclxTAVCsdZcbR6ZfbmgwQsXQYkcCm+UyAghXc0BxeU61G1Vym5zc39FIUK3pRiyfGiw/llvFBdZqNdnQgtJH3m7psyuLL/2jWoFMWMjlX10HjIqKoqOhxjvdvQhAowmRrnUnWMwxKrCGIPNshjnJENWeQteSgbWLag6oVowtDFIXFmdcAIG9A4rN7vW0eMA9LX8G9/sBrQMrN5NknXcj0Cp5I9ui2WSJa+imWbX2f5JFMrNtqQ5fpTZMAOyu00AshSL0zAw==
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=X/bDpJfGh2Z/ENT+c8uezX5eaHdhNyIfCo9MF3sPkBg=; b=YxqopxBwMcF+g3cLyivmPmmeVWF2eajkajfYqZ6BXbJiKcp3KWxE6qX2yvtvREe5hWcU4COQaB/B9j48m3eOFXMppRzL+Hx+blJDPNY4jQwM1bxmeDriBYQTZuqdIn5axAjAB+cy7aCmQgA33NAAsdFGtWdWIZGip5VDvmv59RQ=
Received: from DB6PR0701MB2295.eurprd07.prod.outlook.com (2603:10a6:4:5d::14) by DB6PR07MB4279.eurprd07.prod.outlook.com (2603:10a6:6:49::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.15; Wed, 24 Mar 2021 13:06:59 +0000
Received: from DB6PR0701MB2295.eurprd07.prod.outlook.com ([fe80::3d41:4cb1:62ea:7af1]) by DB6PR0701MB2295.eurprd07.prod.outlook.com ([fe80::3d41:4cb1:62ea:7af1%9]) with mapi id 15.20.3977.026; Wed, 24 Mar 2021 13:06:59 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Jonathan Morton <chromatix99@gmail.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] L4S, DSCP, and RFC-4774 Option 2
Thread-Index: AQHXIJ/of45C66UkVUuqAEYPYy37w6qTGX9w
Date: Wed, 24 Mar 2021 13:06:59 +0000
Message-ID: <DB6PR0701MB22952A49E4D5A4966C52D366C2639@DB6PR0701MB2295.eurprd07.prod.outlook.com>
References: <HE1PR0701MB22994B98780E358D78207D40C2639@HE1PR0701MB2299.eurprd07.prod.outlook.com> <E2B178B1-906B-42FC-A96E-A02D63BCE94B@gmail.com>
In-Reply-To: <E2B178B1-906B-42FC-A96E-A02D63BCE94B@gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; 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: c2db89be-0d1a-4c0b-c5df-08d8eec5b592
x-ms-traffictypediagnostic: DB6PR07MB4279:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DB6PR07MB42794B78B1D0B26BE93392DFC2639@DB6PR07MB4279.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:3383;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Lq+bVEM7vwzHFay7ApV8CtseFSiXGKA6a2m9O1DuqCHZo13Dac+8wG+u+voP4yhOYQASX3+YMonfhXYOj0tnRlFLoAo52uq2AALdlKW4S2/F8rg35jFuGacv/4U7lgmBI38d5DDiH9ro31+ntm8CZP0gBm1SFQeArQCCb0Wj3RDudQUyCM6BAMENhJpEBVsxWBM/shDp0Pdx0UgbL4ILnAKOTbH8u67PeAdIL2yHeEOA6pwJ8PhI/zPGPS8QCXMAzc+4ktmTVQL+SPaem908FONXdecW+xmA3T0K1KDkPxDKpQm8cuMxyaylaKHWibN1juPlrY7uUYapRjuJBzKSeb3YhMZTUJt9YV6c/8JnK9SCFQIVzAT7zKXdSEGk0LowwMJwx5ItNbkqLfc+E+gOKrBOBO6koXGYBFW90JdpI52SepLHpeiaPucRT2wlLR+MFsz63chpOpL4YNPvgwuqYi6arpiBugdVzQupMyTlLCg6xuWua5G8thW2ooseDCe4oQxbWL/PkCZ7ni3OG9m3k1TAoi6WgGv08Lhf6QpTxe7GzP+Fn0xoJgheJ9gJMFRSM8lxGOichp3UCHNARlO46gkg/SRUVn2gSC/8jVmn4vZZxGGrul2wbd0CV02yScrRRg3ipm+2VZR7aRyRXm/xA1gDtApAJkB30jO5vYMQzc4rLUvGFRodoPr0H7kkhokLvnQ3PVaIy0CG25Ot07LOEo5JgwNwarCTGtsgAzIXeHOybtv96/3cTd1b/Nm6jLDt
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0701MB2295.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(39860400002)(346002)(366004)(376002)(99936003)(66946007)(7696005)(4326008)(76116006)(8936002)(55016002)(66556008)(966005)(66476007)(5660300002)(478600001)(38100700001)(66616009)(64756008)(2906002)(66446008)(9686003)(186003)(53546011)(83380400001)(33656002)(8676002)(52536014)(26005)(71200400001)(107886003)(86362001)(6506007)(110136005)(316002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: zMiECR6N3AV+mN/0Ol5wVZ3gA8gJBUF1J4d0OWDtNkI8oz0QIcpUrPJBtQzwYMdcKjZco1UHmqOWFr8LzYAqZwCb42cty7xSlPbJhxLTfUPpvIN0me/XPilcwu/0KrvYk5He7DiUdRYIKANWfJmfCDI82L3lxmm2d2oVQr4CXds1analfVV5DIb/JydaULP3ZIynpCKCNSNIOb69H/vnbBrKP0wUx+OqO+1sb21Y/iVGBfZ7gnrmAZ1kdlmMnh5IVFLtLJcjUR/97i3Cow7UY7OcOROf/0D513/5yJl8xOgKfi3iXEnrxu8HCjSER/tMuoOPfkROha3f8QzFeKekAV4Wv4Zwj4rRAzpyif4aFQ45g8zKka4arDxtBIL0/XZjCx5ojMrCJAXMJ5UEUkM8arfYo6E9lwnHaPnZQTQanFSOS7yns88QLdndhXJY7WGHajX+Gvx6QtofEZuxCe0ziRRSyX8nMPJzexObLsY8REE0tBPlEJ4YAIosnCFbxHSJRtF1B0LfpCMsFzCiBCjvIQnUH0+3pjTs3cRWyvtdD0IXNZuDlvVEuxvx3zoPcb79iG7/w8LfHF9odisTFzPzcAAzcUuxjLkCZSfOaUUvEfoHNJXhw+lL11/0dkJlB236YqbYkAphFPA2oExwySVjvXjd6kfkFRFdMIFrXL/Kbm3AWVLzRjvvTo80+eUAYTO7blLZqizWZ6b5OuL9hqVwmHZiyQWxyu7JadBFrbpuzRYDC8c49aJyAAr6CjPBFxSZ4kp874k8NdL+puIze09Dde0bZavbg/iucLwb6OSAH30lRgRJ6ZnhuvW3Lkj/SoSv39oQnESU4+c/VvDaBuMCVhVX78LIU3MEhzOR7vqjD2xLCI95TNUQYUvM/WoLavJ1WewfxkxSWcI29dfQna6LUfOSaIfl9WzRo0PmSiDI9uvXjF0RjTlPw1iFGKY1sHUhDthZQ8cC6Z8xD+6CxuAc4aGTcOJfvkP0nCbBg7jJcRMSe/1YmMlj4Y4rCzny0B7KiTegMfpeu0Z1eq+J1mLmuTJrm936eBNDdh6yokgkRAMdPUwZORUt9Ftlx7LdNrS6IQ9WdmFVqF2RlqhI9LosbIG3rSfBwuT5pc3Oq11bib/nbCRID8cbAaYbwE4c1A1ljkaHi3CKwf7tmOE2dJFD272gCG4NOHs6vs49GVuHm/R0INhEoCo9CKM/2kEpG1WJrm/wQ52Z8IPMhu//I70IbVYhKmmG/2cnk8W7JCnybo4jz/RkSGh+cGc4snubd8srYQ4Z1NUQr03wX6Tm4tc+0cyioFKI9x2XaAqdrq+IRSUMGWmPvV1uuCY8v7mf+Y6J
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0197_01D720B6.F3DEA370"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB6PR0701MB2295.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c2db89be-0d1a-4c0b-c5df-08d8eec5b592
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2021 13:06:59.4238 (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: GEWTEeJxykKnc2Ls9+CnuzgrzG9nJv4Sq//hH9nQVo03hPMVyXL0hRPTB8Xo2aTqBkBbXOilzWKEYHI5m3TdS/drySZzklnlyZ2DFFuaIIDpbeqBKMRPDszs3+D9DOlt
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB4279
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ISAcad-u2Df288VyYQPsN2nAEy0>
Subject: Re: [tsvwg] L4S, DSCP, and RFC-4774 Option 2
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 13:07:08 -0000

Hi Jonathan. 

I believe that it is best that I refer to the L4S DSCP thread and Gorry's input before jumping to conclusions
https://mailarchive.ietf.org/arch/msg/tsvwg/U5CfgEVZKgLNnspPMwmaeKxd_Zs/
I have for instance completely forgotten draft-briscoe-tsvwg-l4s-diffserv-00

/Ingemar
 

> -----Original Message-----
> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Jonathan Morton
> Sent: den 24 mars 2021 12:22
> To: tsvwg@ietf.org
> Subject: [tsvwg] L4S, DSCP, and RFC-4774 Option 2
> 
> > On 24 Mar, 2021, at 9:49 am, Ingemar Johansson S
> <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org> wrote:
> >
> > There are entire email threads started by a few opponents around all
> things that can go in the shitter when the L4S experiment starts, but so far I
> have seen nothing, nada, zero…. discussion by the opponents around “what
> can _we_, the opponents do to remedy these potential issues on our side?”.
> 
> Okay, Ingemar, let's remedy that straight away.  Here is a concrete proposal,
> from the SCE side of the aisle, for how L4S can:
> 
> 1: Identify L4S traffic to the network in a fail-safe manner, without consuming
> the ECT(1) codepoint.
> 
> 2: Contain traffic with L4S semantics to participating networks, which can be
> adequately prepared for it - thereby minimising the likelihood of affecting
> "innocent bystanders".
> 
> 3: Provide a positive signal to L4S endpoints that the path is (at least partially)
> L4S-compliant, so can reasonably be presumed to lie wholly within a
> participating network.  This would satisfy the "fallback to Classic ECN"
> requirement in both RFC-4774 Option 2 and the so-called "Prague
> Requirements".
> 
> I think this might be sufficient to promote L4S to satisfying Option 2 within
> RFC-4774 - which was the original goal, was it not?  It has the side benefit of
> freeing up ECT(1) for other experiments, without impairing L4S' own
> performance.
> 
> 
> The details:
> 
> 0: Select two DSCPs from the experimental pool, X and Y, for use by L4S on a
> time-limited basis.  With kill dates embedded in experimental
> implementations, there is an obvious route to un-deployment in finite time
> at the end of the experiment.  If the experiment is deemed successful,
> permanent DSCPs can be allocated to replace them.
> 
> 1: L4S sender sets DSCP X at origin on participating connections (both data
> and control segments).  This acts as positive identification to the network
> (but not the receiver) that the traffic expects L4S semantics in place of RFC-
> 3168.
> 
> 2: L4S middleboxes accept DSCPs X and Y as L4S traffic (regardless of ECN
> codepoint), and re-mark those carrying X with the Y DSCP.  This acts as
> positive identification to the receiver endpoint that at least one node on the
> path understands L4S semantics.
> 
> 3: Gateways at the border of the participating network either blackhole or
> bleach both the X and Y DSCPs, in both directions.  This is the containment
> mechanism.  Bleaching permits connectivity across the boundary with
> conventional semantics, as below.
> 
> 4: L4S receivers treat only traffic marked Y as having L4S semantics, all else as
> RFC-3168, and convey this distinction to the sender by setting a non-L4S DSCP
> (eg. CS0) on acknowledgement packets requiring RFC-3168 semantics, and
> the X DSCP on those requiring L4S semantics.  Since this is a path-specific
> rather than packet-specific distinction, it should be fairly stable over a
> connection's lifetime.
> 
> 5: L4S senders respond to notifications of CE marks according to L4S
> semantics if and only if the notification arrived in a packet carrying the Y DSCP
> (so, it passed through an L4S middlebox on the return path as well).
> Otherwise they respond according to RFC-8511.
> 
> 6: L4S endpoints should, upon observing a path that doesn't generate Y
> marks in either direction, revert the affected connection permanently to a
> non-L4S mode and cease to emit the X DSCP at origin.  If this occurs during
> the 3-way handshake, they should negotiate an RFC-3168 feedback mode
> instead of AccECN if possible.  Otherwise, CE marks indicated by AccECN
> should be interpreted as requiring a Multiplicative Decrease.
> 
> 
> The effects:
> 
> Receipt of packets carrying DSCP Y implies all of the following:
> 
> 1: The sender emitted DSCP X and asserts L4S compliance.
> 
> 2: Some middlebox on the path supports L4S and is presumably part of a
> participating network.
> 
> 3: The path did not cross the border of a participating network.  Given 2
> above, that implies the path did not cross any part of an "innocent
> bystander" network.
> 
> This means that packets carrying both DSCP Y and CE can safely be treated as
> indicating marks applied by an L4S AQM. Packets carrying DSCP Y but not CE
> can be treated as permitting the connection to remain in L4S mode.
> 
> By contrast, receipt of packets carrying DSCP X implies all of the following:
> 
> 4: The sender emitted DSCP X and asserts L4S compliance.
> 
> 5: There was *no* middlebox supporting L4S on the path.
> 
> 6: The path did not cross the border of a participating network.  Given 5
> above, that implies the path is *wholly* within an "innocent bystander"
> network.
> 
> This means that packets carrying both DSCP X and CE *must* receive a
> Multiplicative Decrease response, and the connection *should* switch to
> Classic mode.
> 
> And receipt of packets carrying any other DSCP implies at least one of the
> following:
> 
> 7: The sender did not emit DSCP X, and does not assert L4S compliance, OR
> 
> 8: The path crossed the border of a participating network, so lies at least
> partly in an "innocent bystander" context.
> 
> This means that, as with receiving DSCP X and CE, receiving any other DSCP
> and CE *must* provoke a Multiplicative Decrease response, and the
> connection *should* switch to Classic mode.
> 
> By sending DSCP X and expecting DSCP Y in both directions, we can ensure
> that both endpoints of the connection share knowledge of what mode the
> connection is in.  A receiver noticing that the path has changed to lose L4S
> support informs the sender of that fact by omitting DSCP X from its acks, and
> the sender responds by switching mode and omitting DSCP X henceforth.
> 
> 
> This is a potential path forward for both experiments - that is, both L4S and
> SCE simultaneously.  Is that good enough?
> 
>  - Jonathan Morton