[tsvwg] Making ECT(1) safe for experimental roll-out

Sebastian Moeller <moeller0@gmx.de> Fri, 21 February 2020 08:29 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 59CFF1200A1 for <tsvwg@ietfa.amsl.com>; Fri, 21 Feb 2020 00:29:33 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 uoUU4TgL1DPB for <tsvwg@ietfa.amsl.com>; Fri, 21 Feb 2020 00:29:30 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6727712001E for <tsvwg@ietf.org>; Fri, 21 Feb 2020 00:29:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1582273766; bh=k5RIrPzSssU76NRzeI7V82FMvYyRXhqQPhr9qiXIY8k=; h=X-UI-Sender-Class:From:Subject:Date:To; b=MxtlSaxBnvIWMvy12so78L7wwOvQhXC5q53abxx2C1N9C9IPrOWqcIFnTfjsPVu0P 8lunmQIDrGS0iVLhRsS6cfjv9rTcWP1QW3EqnYt+Bshyh2ZFO+4OzLPgITHuOgD5p9 myA0yvLPX2UXEkZ16F7kyPoy3aQKzYba20GJDL/I=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.22] ([134.76.241.253]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MEV3C-1jFXH53q6E-00G0tH for <tsvwg@ietf.org>; Fri, 21 Feb 2020 09:29:25 +0100
From: Sebastian Moeller <moeller0@gmx.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <0894B9DE-A33C-459E-BC39-C88CCF58C44C@gmx.de>
Date: Fri, 21 Feb 2020 09:29:25 +0100
To: tsvwg IETF list <tsvwg@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:SgCZaf0yKDM2GDkT4F+yCPsddzLaPrGCsw7RnRC78l/MRfmIO71 +eoXe7W+7GWbkS4DmafrBoH1xkEK3WcMLpsWuruXt+G43ZnVgzxvc1cWS627hULjqX0GiL8 kiggyZSRnUuDc5R6NKTa+TijH4Uad3dQymGTNOTRydnXOgwLWs92cN9kcFMvFGcsfv6cG7r g43TyTrZo9YGyhA5K99jg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:AuUfyMoB35g=:SlBVQfAYSO3N/9UMokXuDe HQh5vbQw6gr4IyiCc3X+oy0vjb4y6BTH+UVKBZZICHT3/BJz/hmdhNcvXptPmLb+S4l/ijehG AGONHM1OqVd+VBkpUp2ugGWWCYWtpyeU2zWThs3qrSL4rS8/lpP+0paM8u7XSWC9xlNiMlwIA 2eiAVri/Ps6JS1reC7wUZ7db9nRcC8mAFFtX4U58ckB4l9ya1m0F23/sEsWG3s6HjnLXptA+h uHhRBIUY0y83z0UdIKghH8TXWFfB//8vP4G89M+weaAhXIwtbrc7J0D2Nc/flOmkWXEXffg+N 1Sh7K97UcJ37HvPqN8YPC54UDCvOgR0XDtSh70/RnaJ24V3fYV4Y1oagxaF9z2ZGyzA3CoOiF vF9hNIs6l5Ff8WtY0kXfStyWw0tO+sia1jCMU3OEDVUHW97ActYdJhX/Cc8tdY4K/pu98atSy lnQ5EkwVY0B9NxgkMyVAgXYRqYAX+gP5sZFx820Znjrp3PY9V5+ItHwymxCmJEgK4C70KjU1s mGKXUE9JpcOIVbljlCX5oEg3BUEFeJquEPr7KDNVN0h2AqKcsqYM/wpPAV9Yc+blVLhO+3s1g CkMqQP2TmhSNOKgA7JVxQYugF67AN1i/kdab/D2CqjuQuSRQK/FxwIj3mY1WxCFUglQ0QGs6t CIScMs6ReIbBxBufwa63OtNyCz5Zhba5bj5YYHV/Jf1QhvTVWtEiNLbyKjw4mW+iEnt/JlpJ9 IyQA58iSs11DUSBqAN0v1hWrv9fuymWJiSwWp5xV8g3vZ7H+z2b9ddB9jc7wbXwvLq6xuVih7 kQNFWAidLNL1T7jaEtRL9zelSwdfxon4Rje4OjiCuwX24slJWOkSC34CKs8TNE8hebezl4lxr oDz7NCKCS9JREXO4EGEDQNdMSWluCSurYO1ayQw6D0+HBQryjm7clX2n0mXGfS52Bht//ebMr VJNm437+3fg4f3TyFB1bJipLRy2D97GlC+Cy3/GlDNcMtQFe77VCXOLF4KvgxPCcQ3Ph4KZXG +bFykalRI73+U9TroRVK1ph4HlaPaoFsg/phHsoT67FFXP9clK6gxtTwjPdIcZMs1FnUrfG2N nVaJQ3q+NY126WLlKmbAsI2+c1akhqpwuk8mS1D5QpqBaK5/8vJM/CLlZL6oziZhFD9KiK1mL vqk6s2fdH4v50Ra8DLGisbrtzNM+C6kKIsssZ/3p5pDhEQCNu0gurkAh3fHznBooHxSZwR6Kq +m3vQRf87PAZVcGtU
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/LBQvBZUHLAo2Lv9kNKME3wZccsI>
Subject: [tsvwg] Making ECT(1) safe for experimental roll-out
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: Fri, 21 Feb 2020 08:29:34 -0000

Dear All,

thanks for organizing yesterday's virtual meeting. While not covering all topics and running over time it did help a lot, looking forward to the next full IETF meeting.

I have been thinking more about the "highlander" clause for ECT(1), or there only being one concurrently acceptable use of ECT(1) concurrently.

And the more I think about it, the less I see this as without alternatives. 
	If the IRTF would mandate that for experimental roll-out both L4S and SCE have te also require a unique DSCP each, both experiments can be started and run simultaneously.

	Once a winner has emerged, or hybridization between the two approaches has developed, the IETF could simply drop the DSCP requirement for the winner. At that point the winning proposal could leave experimental status and be elevated to a full standard with pure ECT(1) use.
	For initial experimentation this DSCP requirement can not be a major road-block as neither proposal has existing user bases, so that the end points for experimentation need to to be carefully set-up de novo anyways, so that requiring a DSCP-conserving path to the relevant AQMs does not seem to be onerous. The primary use-case for L4S for example supposedly is the per-customer traffic-shaper that ISPs employ, and the targetted traffic in all likelyhodd will come from close-by CDNs/data-centers, so DSCP conservation should not be an insurmountable obstacle, and for the egress path that will be even less of an issue.

I accept that none of the two proposals actually proposed to go that router and have this implemented as part of their design already, but I argue that:

A) since this arguably affects per hop behaviour (namely per hop ECN marking behavior) both proposals should have mandated an, at least opportunistic/best-effort, DSCP from the on-set.

B) the IETF, as far as I can tell is the ultimate arbiter about which drafts reach RFC status and is in a position to mandate requirements and changes to assure the safety of an experiment.

So in essence there is no hard justification why the ECT(1) plus unique DSCP requirement can not be made a precondition for permitting experimental RFC status. This also has the added advantage that to shut down the experiment in case is is not successfuk should be considerably easier, as most ISPs already have gear to re-map DSCPs while fudging with ECN bits is rightfully frowned upon.


I would be delighted if others could opine on this proposal, especially the chairs, preferably "ex cahtedra".

Many thanks in advance
	Sebastian

P.S.: I admit that I am a pessimist, and all of that contingency planning might prove to be wasted time and effort if the L4S experiment succeeds, but that is quite typical in engineering that a design is required to not only work under best-case or even "normal" conditions, but that it also does no harm under extreme conditions, and so far I am not convinced that the L4S proponents have looked hard enough at the worst-case scenarios.