Re: [tsvwg] L4S drafts: Next Steps

Pete Heist <pete@heistp.net> Mon, 22 March 2021 08:03 UTC

Return-Path: <pete@heistp.net>
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 7B7EF3A046B for <tsvwg@ietfa.amsl.com>; Mon, 22 Mar 2021 01:03:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heistp.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 MHnKgip2i9dV for <tsvwg@ietfa.amsl.com>; Mon, 22 Mar 2021 01:03:48 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 F0D9A3A044A for <tsvwg@ietf.org>; Mon, 22 Mar 2021 01:03:47 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id e18so15615811wrt.6 for <tsvwg@ietf.org>; Mon, 22 Mar 2021 01:03:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heistp.net; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=TNor7I+CBM6P60NrsOSHAieBUsHGBWdkPchJcNWpOG4=; b=IcmlqKepp/I830FlRWkop1VG6gX85ckszcFQ4NhGvtvMmRHVJ+iOJRpcoEwP3ZcLtc aZ/vPt6LOhqsjm8aNZA2Kh0xWzmqHM9eFbjf4NsJSjdAlKtqTOaloRsBj9U1QAOjy7qp SolIFeEzZr3b7PVMLofEu5mUZQUz7In+30KbpZbqMRSBzTxNJW/eBK6SXbrGY9pJGzSj iQSbVh/t0jFTiVb0pqQuHjfySfKty++p/fH440SFpu0sC6sU7/CEbIt9Gd03p10ISDox gnKJ/d2rYFe9pczlgrS2/QWGkBWYO/zv9Gwe/YOI5TDYQa+JWCJmRHCx6jjdxyo+cCA+ GsOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=TNor7I+CBM6P60NrsOSHAieBUsHGBWdkPchJcNWpOG4=; b=T6LaA2n5cn0rHFSyMygwxnVYHggUBygvZsrzppKoNe+U4dBlaU7EAdciEZJeqpNU/s LhitLuk+k9TLdgiA0JLPEGKgvF9BbZKK/pfRjV79vWRZVtUeXzeJxBhU+Db+DEXmdge5 /g6wMrYSuvGdUCFu9x3qAGZLIDHWu5TByfURP17ePS0PFnMb49EWl9ZK8S8kQwT+N0Nu QgJ/71euIupM+DW3vmN8XGlebDyKSkv0Gh+sa3uRqaEPcLZzrN2uH0LD/nDddU6psaaW MX/0N5gFevkVYXc1RQ6vigUWDesiNZCnKRzwXBF0jAW/TkcVw+Z16L4ud+h5UQltmxAO 6WIQ==
X-Gm-Message-State: AOAM530UF924aipP+Pxk0pgRIKndiVHMhENFoSps42nLzAnFD8Ecktaj RqSx3jehd9IzFsMPrEVCWnMchq7EcUStZA==
X-Google-Smtp-Source: ABdhPJz6hPyCzt1nVoKx33UdmYunBVd8gSZVhi/dxJAwd+99gu3U2pYyPBhsiw3l9hkVhztMrGeUjA==
X-Received: by 2002:adf:fb87:: with SMTP id a7mr17043204wrr.58.1616400224809; Mon, 22 Mar 2021 01:03:44 -0700 (PDT)
Received: from [10.72.0.88] (h-1169.lbcfree.net. [185.193.85.130]) by smtp.gmail.com with ESMTPSA id r26sm15404477wmn.28.2021.03.22.01.03.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Mar 2021 01:03:44 -0700 (PDT)
Message-ID: <ae0e45b542a23eefb610bb59cf9b76414cf0c87e.camel@heistp.net>
From: Pete Heist <pete@heistp.net>
To: "Livingood, Jason" <Jason_Livingood=40comcast.com@dmarc.ietf.org>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Date: Mon, 22 Mar 2021 09:03:43 +0100
In-Reply-To: <11C85D70-0D22-437D-9A1C-B1A5E6BE0EEF@cable.comcast.com>
References: <MN2PR19MB4045FAC079C74FC262005BF483F10@MN2PR19MB4045.namprd19.prod.outlook.com> <92283815-f81a-ba86-fe63-7925e23e31f6@bobbriscoe.net> <MN2PR19MB404513C22FE4025C31261BC783CC0@MN2PR19MB4045.namprd19.prod.outlook.com> <5d8f0031-1aee-9e41-7860-04a46a89607e@bobbriscoe.net> <MN2PR19MB4045305CA7D5673C554BCBA383919@MN2PR19MB4045.namprd19.prod.outlook.com> <ee0c9cd2-608c-ef69-ef84-892cd4f17204@bobbriscoe.net> <MN2PR19MB404522F073A03BA2F866604E83909@MN2PR19MB4045.namprd19.prod.outlook.com> <83559d3f-6004-118a-cde2-ec999fc8c483@bobbriscoe.net> <DE5B87E4-DD60-435E-80AD-01C09F13D173@gmail.com> <375666b8-1123-a635-1cd6-eb496835369a@bobbriscoe.net> <D8EA6E7B-738F-424A-88F2-EFEE3D053C02@gmx.de> <9165ED30-4A09-4B14-99AD-74690DC4AB04@cable.comcast.com> <AA407F19-492D-44FB-9B86-B40BD365F884@gmail.com> <11C85D70-0D22-437D-9A1C-B1A5E6BE0EEF@cable.comcast.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.38.4
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/1OGepWf6wasJaiqbUZoIuiHcP6c>
Subject: Re: [tsvwg] 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: Mon, 22 Mar 2021 08:03:53 -0000

Hi Jason, one comment below...

On Sat, 2021-03-20 at 15:08 +0000, Livingood, Jason wrote:
> > The lab studies have shown
> 
> IMO the challenge with lab studies is that there are a lot of variables
> that are artificial and/or the test environment or test traffic does
> not fully reflect reality (production). 10 or 15 years ago I would have
> been very focused on extensive QA testing and an elaborate lab test
> environment. These days its more how to do controlled testing directly
> in the production network, with a controlled/minimized blast radius in
> case of problems, easy/quick rollback, rapid code/config iteration.
> 
> > far from a promising system that might be ready for a field trial,
> > one that shows worrying failure modes that primarily affect innocent
> > bystanders.
> >  What we're asking for is a system that at least behaves reasonably
> > under lab conditions, chosen to represent realistic challenge
> > scenarios likely to occur in the real world.  Only then can we have
> > any confidence that L4S will not cause problems anywhere and
> > everywhere that it is deployed.
> 
> Only one way to find out - test it in a real production experiment with
> appropriate risk controls.

Along these lines, there is nothing stopping anyone from using DSCP (as
an appropriate risk control within participating ASs), to perform
experiments to reproduce issues that can be demonstrated in the lab.
Here are a few: https://github.com/heistp/l4s-tests/

It would be nice if someone took the time to set up some production
gear with fq_codel built into it, like routers and/or WiFi access
points, and test various kinds of real-world traffic, through tunnels
and not. One could combine traffic to L4S servers within the
experimental network, along with conventional traffic to anywhere on
the Internet. That seems like a useful step before starting an
Internet-wide experiment. Perhaps even better would be to fix what
safety issues are known so that they can't occur in the first place.

Regards,
Pete

>  The status quo seems to suggest years more debate without (IMO)
> sufficient data. An alternative is a controlled production experiment,
> appropriately risk-managed, between willing participants. I see no
> downside to allowing that to occur via experimental RFC. We're setting
> the bar at the proposed standard or standard level, which I think is
> incorrect. I would say instead enable the experiment to accelerate the
> learning & improvement & drive data-driven decisions.
> 
> Jason
>