Re: [tsvwg] Reasons for WGLC/RFC asap

Lars Eggert <lars@eggert.org> Thu, 19 November 2020 05:08 UTC

Return-Path: <lars@eggert.org>
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 DC3FB3A0D25 for <tsvwg@ietfa.amsl.com>; Wed, 18 Nov 2020 21:08:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 (1024-bit key) header.d=eggert.org
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 rNH_aEHb2BaT for <tsvwg@ietfa.amsl.com>; Wed, 18 Nov 2020 21:08:27 -0800 (PST)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 E0C693A0D1E for <tsvwg@ietf.org>; Wed, 18 Nov 2020 21:08:26 -0800 (PST)
Received: from [IPv6:2a00:ac00:4000:400:a1c1:451:99bd:2fed] (unknown [IPv6:2a00:ac00:4000:400:a1c1:451:99bd:2fed]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 17C2F6108DF; Thu, 19 Nov 2020 07:08:19 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1605762499; bh=L2hJ9noRtNJ38cGsneyWni631ocQNFSOVIE0UXt0wXQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=N9Pn+g4l/fw3oXFJ8xizpZT+sRfgr2LFyfSxLjk8t29sji1D2M1BeRWlvXL2sNIvT ZFIkqpWxemW+QvX6v8IGehpI7PsYy5v9A6gpq2JeKOfGuhhHEoRv7KCC4ZIJnV89ra lfJwXDgI9O7SLzUZjxKNwON7iFMZh3Fpkkv6/e5I=
From: Lars Eggert <lars@eggert.org>
Message-Id: <4FF8800F-B618-4818-AF5E-1E997EA9FBF3@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_C99F7141-05F1-496E-A2AA-3AA887E54549"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Thu, 19 Nov 2020 07:08:18 +0200
In-Reply-To: <5dff4f73463c2a7e7cc8dc8255ae9825e78f4c11.camel@petri-meat.com>
Cc: "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, tsvwg IETF list <tsvwg@ietf.org>
To: Steven Blake <slblake@petri-meat.com>
References: <AM8PR07MB747626CB7622CB89209018A8B9E10@AM8PR07MB7476.eurprd07.prod.outlook.com> <5dff4f73463c2a7e7cc8dc8255ae9825e78f4c11.camel@petri-meat.com>
X-MailScanner-ID: 17C2F6108DF.A8600
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/w5sPDvenwBn5mmA63nw9nUNAs9M>
Subject: Re: [tsvwg] Reasons for WGLC/RFC asap
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: Thu, 19 Nov 2020 05:08:29 -0000

Hi,

just wanted to say that Steven's email below raises many of the points I tried to make - and expresses them better - so +1.

Thanks,
Lars

On 2020-11-18, at 19:50, Steven Blake <slblake@petri-meat.com> wrote:
> 
> On Wed, 2020-11-18 at 10:31 +0000, De Schepper, Koen (Nokia - BE/Antwerp) wrote:
>> Hi all,
>> 
>> To continue on the discussions in the meeting, a recap and some extra thoughts. Did I miss some arguments?
>> 
>> Benefits to go for WGLC/RFC asap:
>> 	• There is NOW a big need for solutions that can support Low Latency for new Interactive applications
>> 	• The big L4S benefits were a good reason to justify the extra network effort to finally implement ECN in general and AQMs in network equipment
>> 	• Timing is optimal now: implementations in NW equipment are coming and deployment can start now
>> 	• Deployment of L4S support will include deployment of Classic ECN too! So even for the skeptics among us, that consider that the experiment can fail due to CCs not performing to expectations, we will fall back to having Classic ECN support
>> 	• Current drafts are about the network part, and are ready and stable for a very long time now.
>> 	• Only dependency to CCs in the drafts are the mandatory Prague requirements (only required input/review from future CC developers: are they feasible for you)
>> 	• We have a good baseline for a CC (upstreaming to Linux is blocked by the non-RFC status)
> 
> These are arguments to deploy a scheme that has been demonstrated to work. Not arguments to conduct an *experiment* to determine whether a scheme is capable of working (and under what conditions?).
> 
> Do you completely ignore the simulation results that show that L4S currently does not live up to it's own hype? How are you going to conduct the *experiment* without at least one CC that seems to work in simulation?
> 
>> 	• Larger scale (outside the lab) experiments are blocked by non-RFCs status
> 
> Why? What is preventing an interested network operator from conducting L4S *experiments* now, using an experimental DSCP to signal L4S packets? What is preventing two interested directly peering operators? What is preventing two interested but non-peering operators from running tunnels between themselves?
> 
> 
>> 	• It will create the required traction within the CC community to come up with improvements (if needed at all for the applications that would benefit from it; applications that don’t benefit from it yet, can/will not use it)
>> 	• NW operators have benefits now (classic ECN and good AQMs) and in the future can offer their customers better Low Latency experience for the popular interactive applications
>> 	• When more L4S CCs are developed, the real independent evaluation of those can start
> 
> 
>> 
>> Disadvantages to wait for WGLC/RFC:
>> 	• We’ll gets stuck in an analysis paralysis (aren’t we already?)
>> 	• Trust in L4S will vanish
>> 	• No signs that we can expect more traction in CC development; trust and expectations of continuous delays will not attract people working on it, as there will be plenty of time before deployments are materializing
>> 	• Product development of L4S will stall and die due to uncertainty on if L4S will finally materialize
>> 	• Product development of Classic ECN will stall and die due to uncertainty on how L4S will finally materialize
>> 
>> What are the advantages to wait? Do they overcome these disadvantages?
>> 
>> Regards,
>> Koen.
>> 
> 
> As I have said before, the only thing blocking the L4S *experiement* from getting IETF blessing IMHO is the wholly unnecessary insistence on consuming an IP header bit *now* with no plan to relinquish it if the *experiment* fails. Every objection raised to my statement has been an argument predicated on ease of deployment. Ease of deployment as a standard is something to be considered, yes. The allocation of an IP header bit can be considered *after* evaluating the results of the *experiment*, especially when there are practical work-arounds (e.g., experimental DSCP) to enable the *experiment* to proceed.
> 
> I see the same style of argument from particle physicists who want to spend $40B to build a 150-km circumference particle collider, to find what exactly? (Especially considering that all current beyond-Standard Model theories have totally bombed).
> 
> 
> Regards,
> 
> // Steve