Re: [tsvwg] draft-white-tsvwg-l4sops-02.txt proposa for additional sections
Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Sat, 17 April 2021 14:21 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 1E48E3A244A for <tsvwg@ietfa.amsl.com>; Sat, 17 Apr 2021 07:21:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 eXTtaoKPdeXk for <tsvwg@ietfa.amsl.com>; Sat, 17 Apr 2021 07:21:50 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30073.outbound.protection.outlook.com [40.107.3.73]) (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 C25743A2447 for <tsvwg@ietf.org>; Sat, 17 Apr 2021 07:21:49 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ajiHfYTcUF2bA1+BcCVmnK/ebO/awtsw6QansGuJ3EvKFneVkUbOUvcXghawIdoJemruCAbjnJWNCKRNcfst+dpVfl44/YsMR5i1DQvDJ1Hn9DhkGYxRU//hW+rZx2sJmaR3+7BwWmzDvkXDJ5Usyhd13sHY1mthj1kEIFjhf20mMZv4VDB+cCSeUDkN+VZUDvuAEr2PQ71qzH3yXIdPVPG4Mzy5b+8p3OeI20/Dmuy58SYkR5++MphMfjs3FfOfsIKHiuQ/18z2193ZXbuORSqeRGQbHMmLlbYqNHdFXr7O7tjUycLpYOpeO66vCVEb+9NR+ctopvjmS/21W8AkJw==
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=kKx9VfT4Sle49GEgEliAusUVoiEglZMzcI26R3R3DLU=; b=bcN41X+Ibay6PSIBGpd4WFuoE47x2+4r0J4aJuf3dhIjXZaDw9vu0W2gjXuKbxj6MWYjzQYHw9vQCb2giJ/lE+qpXycEni/et9DKFwxDYZ6ZjXQYggjZvN9LO+Wqht/Q+YW70cWDPcUDBGBDgjLPJ6wkNXh7i/s9+gjNbGCdaMyZiQwtA8RYx2CGdKgajoXLyJVdDGkeWStjQOSxTZwDh1ZoLQeCa6If1tQc2RJISra+rMj9y7OKAjiyTRjSpI3af2ghS8dDnaVpp8Rt/eYXOorDM5ZdwMBd+aYSuwh0LKS2hjdqDndIqHeUDujLb0LBCHxSI+3lpE66Ow3C8yeYJQ==
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=kKx9VfT4Sle49GEgEliAusUVoiEglZMzcI26R3R3DLU=; b=aJundvYvEf5+aQRleTu2OpGxjOIqY8hGsO6VwzKAuFMISlcXq3uRfILrZxLBjJVMdUcieq7au4xq4Q3glNJLyOntiBY23ATxXBRvcHgTpDWDzVBzOVMGK3rQqbxSXDp/9zawGeWquLqa8uUreE4ZszWXjd5fNjtRIVHec8CkWSc=
Received: from HE1PR0701MB2299.eurprd07.prod.outlook.com (2603:10a6:3:6c::8) by HE1PR0702MB3578.eurprd07.prod.outlook.com (2603:10a6:7:86::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.6; Sat, 17 Apr 2021 14:21:45 +0000
Received: from HE1PR0701MB2299.eurprd07.prod.outlook.com ([fe80::78cb:103b:9ddd:1850]) by HE1PR0701MB2299.eurprd07.prod.outlook.com ([fe80::78cb:103b:9ddd:1850%7]) with mapi id 15.20.4065.011; Sat, 17 Apr 2021 14:21:45 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Sebastian Moeller <moeller0@gmx.de>, tsvwg IETF list <tsvwg@ietf.org>, Greg White <g.white@cablelabs.com>
Thread-Topic: [tsvwg] draft-white-tsvwg-l4sops-02.txt proposa for additional sections
Thread-Index: AQHXMwMxAto9RhVF8UyG/eZgwdvoMKq4v3Cg
Date: Sat, 17 Apr 2021 14:21:45 +0000
Message-ID: <HE1PR0701MB2299CEAEED3FB9C1CCEA5385C24B9@HE1PR0701MB2299.eurprd07.prod.outlook.com>
References: <C2BD1FC5-673F-4C29-8FFE-16CA367F388A@gmx.de>
In-Reply-To: <C2BD1FC5-673F-4C29-8FFE-16CA367F388A@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: a3cea9d9-1697-4ec8-24d2-08d901ac2157
x-ms-traffictypediagnostic: HE1PR0702MB3578:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR0702MB357893F5F3BEAA763CAAEA5BC24B9@HE1PR0702MB3578.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: +YvLE7bLF1ySAXDUHAgPB3waBA80ZcS1CNbumZ0V9L/ekWi7FrqDK5aOd/ZlaNT5vrUJekLSJPKJVfuYLqyE2OrRaYfIyS41yYdkvA0kcJyVKBpaYCRAws0CF1j2RuoxSwbZrypCypba3kuNhiED6gvSaJh8OfRWVOXxQNId5qqs42zpNP35OFPF3j2IXuKcsWXeLaFjbIqj2FLjUzBIZTK+4TpWSOBMilQhWKqR+kFT7/dKBuPX06fIAcZm/1qvm9kUBw3EnkWBjUKJTRXY5RQDFJGlLD8kt+GknRR5vusmjBiO3d0+ec5zSpaKS5WNUqDWKJCPepjjkdTnAI85zR4rW3Ju+laqMYeBRN2wv21Xh9MCuZR9fdsCdH0z3m7OYCivZaqB6JsLtVVu2/6Nld/PINJfHUoL4sDEnGTQ87u7nngGX3czjxa2CIhLMyDg7CKedM9HX7gRNCZEKex7jUQBS/qe1VcpQYI7pPWv0d2pNP2hc/p2g9J3Wf4LQeok5wETrmNyiA8hCMsfR1lcoTtsCLw2c8wHY1ZwtOFJWfNkuOKnoZ5faoM6JEEqZ10QOqqt1x0jCt5Mc8oBhyfRer9RgpO/pybl6hfATKceHZvY5N+29Lo7chMujAc+TCtXEEwQlry7JgJaakNwSyL0lTcmgTQCYxF8naxBROuWoWzJrtaoBJkuD0JZxLv/t6o4
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)(396003)(376002)(346002)(366004)(136003)(9686003)(7696005)(5660300002)(2906002)(55016002)(316002)(66616009)(122000001)(64756008)(66446008)(86362001)(66556008)(66476007)(99936003)(33656002)(966005)(76116006)(186003)(38100700002)(71200400001)(26005)(52536014)(4326008)(107886003)(66946007)(110136005)(8676002)(53546011)(478600001)(83380400001)(8936002)(6506007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: G3Am5FsU+oxkV0JiwjwqX1wkF5LHGXbvClcl+P3wXwP24gbnYS754IFSi6ranIki0V6x0JDPaDGeCMBX9avHeMZHl2Zuu3pSpmwt1kM3VOsYClDTFxDQuWflfbyAnm+u0dM1fGCBXu75iTU3kCkbVom7dXqcvDtB3dtbLKe3hN9hr9cVa365Q3VW6VD1gVjEi2wAIcC/cAfdd7pPSonMKeM56xqPRKgWfPW0PCpy7seG5lVf8zwsETOYEjzNRZCKr64kBoRlCLzCNSnCzEl/1wzsMC2lq7rO5vK8eXLQxDqkQVQ83iiy0ZY23uLu920PaTIgyoIiJ0/2udp1PCI1mKIM0c+rstxmjK0Jfx9RHuBw+GLz4b5TCtLo9nGYGA5PdrHxAKqCdWw4HwhhpCO3Lx1TjBB+f3riJe3inn37TF54X0fdCkiMHb15QW8LU6OGmounEQ9nobMSwb88ZxE5wCJbhklQVF90rkpgnGU1b91jb73S2n/f07P97AWd2x3ONfVXCFGVAdW6RN+uAhXeRsEC7m8+6pipSwlcw7qKeiBVIRzQOgFcc8BsXUXuNP+roN/+tf+qjER2k9v3SY+cQ7rQ1ZarYd/lXl8wBDy7KD+kkr70kPtSLxtX9yHJto7IrGYtdPAyIq5a96ONH3HuANRHmQu9ZZhOv8VBYtCQwVK6D2hcdaQ/NSySNzbop5lEelajJ9fSY86cuInfpXmmvFTr9mc0bETXarMBf69LjQn45X6l35QafRz0Y7wczk46clLt4tA7DT6o2B8jZ+CBOPhddkbRr9WKGjsAJkOWLgPPFsC+ukerJl5lychEMdtImD7yCUa8mXJIbweBQclZAnAUWxge+Dg3VAP34dfZE+jo0sPC/E8cVxhh6h7+CtF9QhKn30X9/mKAHnC784IuM3XLuB0n3m0V87wWy51KIGiUPgd5QrYHudCyntUDD67/bg1kOv0rt3fHaWiMpo0yD5OBIpgevzaAfr8FVVGl3Ph/kM/DdlqqzK6umA2Fig6/n9Le7JYawv7hMt0b9qKK55wqENRI4R4/ZB3P/ZJf4wSXNASW7G/EAY/bGenxALZD3KyAWR/IgIJvAx8lvI9xaQ3YLZ/NiGy6pJFBYsFQI9z10fEhYaH0ItwVgI1X9JZYpVhqOpTWw+zovTjrxLflFfIJ64/ItiRFNKvM/NxHZfLVHhPeQMqq4dxYbw1BZiK4UAOIyi+jwpAi4Dgcp4i5Ld9NkBRV1V/DnIaN+NDq4saD2OUN+ycB63XAt1o2CDvevVnsXUbiarhp65GdACsftVV8FqqN2yw9vQSFBev+QpBU5jR1KmfEAr5sn9vmDmD4
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0059_01D733A5.C05475A0"
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: a3cea9d9-1697-4ec8-24d2-08d901ac2157
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2021 14:21:45.2088 (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: iYbFIY/7LmsBKu+l+iqeKatiUCwkIb5C6FCpltiVGRBQgMY1cRSxi1zd/GU5eto5ddS05Bc11i3YnKg+IEo4sVZ1Giamg/e6vj6ej/61vaQwdTlkzvWMj6mPlJ8k1p9e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3578
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/SrbjPIKFSkzMo50LzSGkx7fWRjM>
Subject: Re: [tsvwg] draft-white-tsvwg-l4sops-02.txt proposa for additional sections
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: Sat, 17 Apr 2021 14:21:55 -0000
Hi Sebastian.. Unfortunately the proposed section 6.2 sounds a lot like the famous Mission Impossible one-liner "This tape will self-destruct in five seconds. Good luck, Jim." The ECN Nonce was experimental and was recently declared historic a few years ago, literary speaking RFC3540 did not self destruct, it just faded away. I don't see anywhere in RFC3540 about what end hosts and networks should do when RFC3540 is declared historic. And I guess that the way forward, in case the whole L4S experiment falls flat, is that the L4S ID RFC is declared historic, I guess this should be enough. But lets imagine that detailed information is needed to address the case that L4S fails. This leads to the question. Are there any other examples in IETF's history where an experimental RFC has been accompanied with a detailed instruction on how to clean up after the experiment ? /Ingemar > -----Original Message----- > From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Sebastian Moeller > Sent: den 16 april 2021 22:57 > To: tsvwg IETF list <tsvwg@ietf.org>; Greg White <g.white@cablelabs.com> > Subject: [tsvwg] draft-white-tsvwg-l4sops-02.txt proposa for additional > sections > > Hi Greg, hi list, > > I think that the L4S ops draft could be improved by saying something explicit > about the end of the L4S experiment and what differential actions are > recommended for participants at that point in time. I made this argument > already at the end of > https://mailarchive.ietf.org/arch/msg/tsvwg/NXEACkPX1pFriOtqsoifPzoI8Sk/ > but I believe that it might have been overlooked there at the end of a long > email. > > So, here is my proposal to that regard as a new section 6: > > > 6. What L4S-deploying networks should to do at the end of the L4S > experiment > > This section gives guidance how L4S-deploying networks should respond to > any of the two possible outcomes of the IETF-supported L4S experiment. > > [COMMENT: I believe that there needs to be a proper definition how the L4S > experiment is supposed to be evaluated at the end to decide between > success and failure, but the L4S-ops document seems to be the wrong place > for that, so I propose to add this to one of the L4S core IDs, preferably to > section 6 of https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/ > which already contains discussion about what the experiment is supposed to > figure out, so adding a section how to evaluate the outcome there seems a > natural fit; IMHO the deciding factor here could be whether L4S is promoted > to proposed standard status after the experiment, if and only if that happens > L4S should be considered a success... I base this on the already known > problematic side-effects of L4S and the fact that L4S will consume a rather > scarce resource in an IP-level code-point the exists in both IPv4 and IPv6, > which IMHO should be released ASAP if L4S fails to succeed] > > 6.1 Successful termination of the L4S experiment > > If the L4S experiment is deemed successful, participating networks are > encouraged to continue deploying L4S-aware nodes and if possible replace all > non-L4S-aware rfc3168 AQM already deployed as far as feasible, or at least > restrict rfc3168 AQM to interpret ECT(1) equal to NotECT. Participants are also > expected to track the evolution of the L4S standards and adapt their > implementations accordingly (e.g. if as part of switching from experimental > to standards track, changes in the L4S RFCs become necessary). > > > 6.2 Unsuccesful termination of the L4S experiment > > If the L4S experiment is deemed unsuccessful, it might need to be > terminated: L4S network nodes should be un-deployed and the ECT(1) > codepoint usage should be released/recycled quickly. > To achieve the former, participants of the L4S experiment are > expected to configure their L4S-aware network nodes such that either the > LL-queue of a dual queue AQM gets completely disabled, or that the LL- > queue is switched from issuing CE-marks to pure drops; thereby removing > L4S-signaling from the network. To achieve the latter, all endpoint hosts > need to stop negotiating L4S-congestion signaling. For nodes under control of > participating networks that should only require re-configuration of the > endpoint hosts. For nodes not under control of participants of the > experiment that will be a considerable challenge. To give a strong signal to > such out-of-network endpoints drastic measures might be required, like re- > marking ECT(1) packets to NotECT or even dropping all ECT(1) packets on > network ingress, as these will give clear and strong incentives to endpoints to > stop using ECT(1)/L4S-signaling. But to avoid "burning" the ECT(1) codepoint > indefinitely, such measures should be restricted to a limited duration (e.g. 24 > month) after an unsuccessful termination of the L4S experiment, to allow the > ECT(1) codepoint to be recycled for other uses/experiments afterwards. > > > > I am sure that this is not going to be complete and that there will be differing > opinions on these sections, but I believe something similar in scope should > be added. > > Best Regards > Sebastian
- [tsvwg] draft-white-tsvwg-l4sops-02.txt proposa f… Sebastian Moeller
- Re: [tsvwg] draft-white-tsvwg-l4sops-02.txt propo… Jonathan Morton
- Re: [tsvwg] draft-white-tsvwg-l4sops-02.txt propo… Ingemar Johansson S
- Re: [tsvwg] draft-white-tsvwg-l4sops-02.txt propo… Sebastian Moeller
- Re: [tsvwg] draft-white-tsvwg-l4sops-02.txt propo… Ingemar Johansson S
- Re: [tsvwg] draft-white-tsvwg-l4sops-02.txt propo… Greg White
- Re: [tsvwg] draft-white-tsvwg-l4sops-02.txt propo… Sebastian Moeller
- Re: [tsvwg] draft-white-tsvwg-l4sops-02.txt propo… Greg White
- Re: [tsvwg] draft-white-tsvwg-l4sops-02.txt propo… Sebastian Moeller