Re: [tsvwg] Call for comments on the suggested publication timeline for draft-white-tsvwg-l4sops, what to do

Sebastian Moeller <moeller0@gmx.de> Sun, 27 March 2022 10:20 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 587DA3A0100; Sun, 27 Mar 2022 03:20:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.658
X-Spam-Level:
X-Spam-Status: No, score=-1.658 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 RalCsBJWcvoY; Sun, 27 Mar 2022 03:20:10 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 7916E3A00E1; Sun, 27 Mar 2022 03:20:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1648376400; bh=JzK7SyheXN8Ks1hIV28b++jQ+877QjMPWfGMKLScfVo=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=CYqgjzXmYaObZYCEF5w2UpndHZSwqjJHXkCDtc8EKE6rRkIbhflevSkglMNovuFBU zLDRjWinkvkzQJq7DaeET87o2L7f1U4HY4TqbfyqVFmFlVctrA2BqErsFNZB0GuvLi DlTKzx8cr1SLbrkjLtycBE3211yPafRxiYo4+0jo=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from smtpclient.apple ([95.112.252.67]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MMobO-1nHza0331I-00IpHi; Sun, 27 Mar 2022 12:20:00 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <AM8PR07MB8137F26C8B3AAF9FC0D8682BC21A9@AM8PR07MB8137.eurprd07.prod.outlook.com>
Date: Sun, 27 Mar 2022 12:19:53 +0200
Cc: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BBC0B1AD-2BBD-44AA-9E30-F7868AAB7508@gmx.de>
References: <28c48d28-3110-d3a8-d405-b13dcbb224c9@erg.abdn.ac.uk> <80FF9110-6C90-4DBE-B205-120A89A67F33@cablelabs.com> <dd4d69b6-71c3-ad68-9394-d4f4d95607d8@bobbriscoe.net> <FR2P281MB06116583115A736D40287B359C199@FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM> <AM8PR07MB8137F26C8B3AAF9FC0D8682BC21A9@AM8PR07MB8137.eurprd07.prod.outlook.com>
To: Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Provags-ID: V03:K1:ZAY3Dfss+xB2VZFkfjIuXi2a5pH7+0fPRGL6cfXWD5clRLw2J2a n0LAOigDW5DaQ0c/BFKLFOxK8hpHfSIWL3VeY+vWDk/5LCEjBuJrDAyAPvQmOt2v6isKzJY 8vamxp/upVIVrp5oPohV5ES3nztJ1NcLW3lRbB55bK72I22XsUcpFDhvjuetfnIZEa/1IAQ TeryFkdY8PXT7cv/q9v1A==
X-UI-Out-Filterresults: notjunk:1;V03:K0:juOgyf2+PnI=:krIDe1RFPypEb73wOfdwJA 9ebteVn/JghYqng5pRoEAsK71Ktox+33BrcG/Yjn6tK75WgBda5j+f5WA5q1mJWhk3f1eX8IS LIxPTwuyEXsrxJ6XOx3/mKd21ln74qliIywz2be5YtB1rsJ2Ya/D2x84x9zEQ6P/8DFa/uefc jBvLKPCB40CfnwX21VO3804Q8Bjqpo7RUSDHlwPbTpfUTGqj6QIVKR8mm1RFCUywTmTsj+2CJ hAAskPIvxqejbYcMHXlmbUmWMhvC8hwp7lqunOUpWim76Qj/D/1gDot1S3HwHE/GRsuAvCTB3 BIyi6HHNowHcsb1Yb8fKhW9i8ao52Mudzog4bppW6OKj/PvfYPj9yg0kjvu/r6y5Ln3dIRIKR RbJ12y5O/iSbp6NgljxkD3wl/KJrUXXivXkZXBNnCacNah51DSvEX1mPa3lNG5Kd3JHY3EAO0 Q/KgIT6JJMl4Aho53rbDiKYbmy7WYIrucyQ6RJhyerIli9aUuWePp7ZmCG/8b+8bRn7lYhR2Y EDmVZsQAzB35nk9Hoa8Ko8Imj8d6xl34siK+mdnkv8+COOqhzeMBlO9kQ4v3qI7lEiUrWOP0+ IYKpH4K90bxFNF/jFoIA0Lj7mmKHTScqWowt7Kf3m50dTIbMVgVY8+kO/JxDRQAaT+P+2bePi HjogPPsPKrWCDV+zs4MruuKvXMTXtkDAZDyHBdlcYZRyUlycBnwJM8whX7kMichHdAwGI5M3/ ZG/9puY+vskOHgKy72DcAATE5Xp+OYUdgKH5pV4D+ZNuOs0x4v1vo2cKrhzUBqvcfd0oWU1JS zQHckcMlL1J2/l3oMeN+FBQZ4yNGVAYBzzBcGlYIg+jtjM4vKs3ZpCqsUwDDK/B4mZMxIbh3d Bfe8S0DV7VEQIAF815Pr6SeVgm+6tibiX3AY6kSUW1kKhLyPV+xNOOJ3Nz2yHVqqyyuZst+mk V9ZgmUn0cyuucl8oKouz7edwBzRZlVnyRHYH8PjSAZmYrRjTdEC9Jrlu0WBKEEEL69ii4jTys dXN7A7hccHK+gYUWGu3R7TNQlvdvmA9yza1m2BLV7jw1/ZjzPV6BFhSX/vdUBjzHgI4RIaEvD juLx9zKnp2/FLA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/XqzrUi0B0PBHt_WpHl8rSHWngkc>
Subject: Re: [tsvwg] Call for comments on the suggested publication timeline for draft-white-tsvwg-l4sops, what to do
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: Sun, 27 Mar 2022 10:20:15 -0000

Dear list,


if we agree that the L4S OPs draft is supposed to be published only well after the main drafts' ratification and L4S deployment, I believe that the main drafts should at least carry appendices describing how initial experiments should be made safe within the existing internet. This can well be caveated with something  like "For the initial experimental deployment the following recommendations are given which can/will be superseded by a planned RFC giving L4S operational guidance" to make sure these recommendations do not appear to be set in stone in all perpetuity.

Again, I would very much prefer if we would run well-guarded experiments first before RFC'ing the main drafts to gain sufficient operational experience to allow us to give decent guidance (and assure that the safety and functionality assumptions the drafts seem built upon actually hold in reality). That would seem the prudent and inherently safer path forward (and with L4S ideas/drafts being kicking around for almost a decade, adding say two more years for safe internet-scale experiments would not cost all that much in time)

Regards
	Sebastian


> On Mar 25, 2022, at 10:14, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org> wrote:
> 
> +1 
> 
> I think it makes much sense to wait with he publication for draft-white-tsvwg-l4sops until we have more data from the experiments.
> 
> /Ingemar
> 
>> -----Original Message-----
>> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of
>> Ruediger.Geib@telekom.de
>> Sent: Thursday, 24 March 2022 15:10
>> To: gorry@erg.abdn.ac.uk
>> Cc: tsvwg@ietf.org
>> Subject: Re: [tsvwg] Call for comments on the suggested publication timeline
>> for draft-white-tsvwg-l4sops
>> 
>> Gorry,
>> 
>> I agree to Bob's proposal to wait with publication until some experimental
>> experience has been reached.
>> 
>> Regards,
>> 
>> Ruediger
>> 
>> -----Ursprüngliche Nachricht-----
>> Von: tsvwg <tsvwg-bounces@ietf.org> Im Auftrag von Bob Briscoe
>> Gesendet: Donnerstag, 24. März 2022 14:35
>> An: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
>> Cc: tsvwg@ietf.org
>> Betreff: Re: [tsvwg] Call for comments on the suggested publication timeline
>> for draft-white-tsvwg-l4sops
>> 
>> Gorry,
>> 
>> I can see the two sides of this.
>> * Sebastian's point that publication could improve visibility for network and
>> server operators is a good one.
>> * But if I were on the IESG and asked to approve publication of operational
>> guidance before there was any operational experience, I would be
>> concerned.
>> 
>> Similarly, because some of the points in the draft do not have much real
>> experience to back them up, they might have to be removed in order to get
>> it approved for publication. For instance, we have been arguing about:
>> * likely traffic patterns;
>> * likelihood of shared queue Classic ECN being deployed;
>> * likelihood of hash collisions
>> * likelihood that good classic ECN bottleneck detection can be implemented;
>> * likelihood that network equipment can be configured in certain ways; etc.
>> etc.
>> Without some real-world experience on these matters, I'm not sure what
>> the value of this document as an RFC would be.
>> 
>> I think Sebastian's point might be slightly reworded to say this draft needs
>> 'visible status'. Visibility comes from Internet discussion forums, blogs and
>> articles. Not yet being published as an RFC doesn't really change visibility (e.g.
>> anyone interested in the implications of QUIC would have read a draft
>> without waiting for RFC publication).
>> Rather, publication changes the status of the guidance once it is visible.
>> 
>> How about this compromise:
>> * We agree now that this draft is intended to give guidance based on 'early'
>> or 'initial' operational experience (e.g. 1 year), and aim to publish once there
>> is some experience, but not wait until experience is exhaustive.
>> * Where l4sops is cited in ecn-l4s-id (from the requirement on coexistence in
>> Classic ECN AQMs), we edit to say explicitly that l4sops is being kept open as
>> a living document for a short while to capture initial operational experience.
>> 
>> Then, if ecn-l4s-id is published as an RFC, the visible status of the coexistence
>> issue ought to be no less than if two RFCs are published about it.
>> And this extra explanation of the draftiness of the citation should make it
>> more likely that people who need to read l4sops will understand its status
>> and not dismiss it as "not worth reading yet".
>> 
>> HTH
>> 
>> 
>> 
>> Bob
>> 
>> On 21/03/2022 17:53, Greg White wrote:
>>> Hi Gorry,
>>> 
>>> A few points of clarification.
>>> 
>>> The draft in question is actually https://datatracker.ietf.org/doc/draft-ietf-
>> tsvwg-l4sops/
>>> 
>>> Also, there remains one "ToDo" in the document that I briefly mentioned
>> today, and for which I'm hoping to get input from the WG.  Aside from that
>> one item, I'm not aware of any other areas where it is considered
>> incomplete.
>>> 
>>> Is the deadline for responses to your question possibly *April* 8?
>>> 
>>> -Greg
>>> 
>>> 
>>> 
>>> On 3/21/22, 8:28 AM, "tsvwg on behalf of Gorry Fairhurst" <tsvwg-
>> bounces@ietf.org on behalf of gorry@erg.abdn.ac.uk> wrote:
>>> 
>>>     The presentation in TSVWG on Monday 21st March 2022 indicated that
>> the
>>>     authors thought the document was complete and ready for review. The
>>>     chairs previously indicated that publication could be delayed to wait
>>>     for initial experience.  The chairs would appreciate feedback, to help
>>>     decide.
>>> 
>>>     So, does the WG have a  preference regarding when to publish the L4S
>> Ops
>>>     draft:
>>> 
>>>     (1)  If the work is thought complete, there could be value in having a
>>>     frozen draft while experience is gained, this could be updated with
>>>     initial experience, before requesting publication as an RFC.
>>> 
>>>     (2) The WG would not intentionally delay the request for the IESG to
>>>     publish: If the work is thought complete, then we can finish this draft
>>>     and publish in the short-term. The WG retains the option to decide to
>>>     subsequently publish an updated RFC in the future.
>>> 
>>>     Please could send an email to tsvwg, or to the tsvwg chairs by 8th March
>>>     2022.
>>> 
>>>     Before any publication, the ID will be subject to normal review and WGLC
>>>     comments.
>>> 
>>>     Best wishes,
>>> 
>>>     Gorry Fairhurst
>>>     (tsvwg co-chair)
>>> 
>>> 
>> 
>> --
>> __________________________________________________________
>> ______
>> Bob Briscoe                               https://protect2.fireeye.com/v1/url?k=31323334-
>> 501d5122-313273af-454445555731-b0108c2709550a3a&q=1&e=c5e952cd-
>> dfdb-4fee-babd-2c04232e13cd&u=http%3A%2F%2Fbobbriscoe.net%2F