Re: [tsvwg] Reasons for WGLC/RFC asap

Steven Blake <slblake@petri-meat.com> Wed, 18 November 2020 17:50 UTC

Return-Path: <slblake@petri-meat.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 4DA253A0147 for <tsvwg@ietfa.amsl.com>; Wed, 18 Nov 2020 09:50:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 XF5vV4be3KF7 for <tsvwg@ietfa.amsl.com>; Wed, 18 Nov 2020 09:50:35 -0800 (PST)
Received: from cyan.elm.relay.mailchannels.net (cyan.elm.relay.mailchannels.net [23.83.212.47]) (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 0A08A3A0B02 for <tsvwg@ietf.org>; Wed, 18 Nov 2020 09:50:15 -0800 (PST)
X-Sender-Id: totalchoicehosting|x-authuser|slblake+petri-meat.com@pawpaw.tchmachines.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 82510340BF3; Wed, 18 Nov 2020 17:50:12 +0000 (UTC)
Received: from pawpaw.tchmachines.com (100-96-227-237.trex.outbound.svc.cluster.local [100.96.227.237]) (Authenticated sender: totalchoicehosting) by relay.mailchannels.net (Postfix) with ESMTPA id 188683416BF; Wed, 18 Nov 2020 17:50:08 +0000 (UTC)
X-Sender-Id: totalchoicehosting|x-authuser|slblake+petri-meat.com@pawpaw.tchmachines.com
Received: from pawpaw.tchmachines.com (pawpaw.tchmachines.com [208.76.80.100]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.10); Wed, 18 Nov 2020 17:50:12 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: totalchoicehosting|x-authuser|slblake+petri-meat.com@pawpaw.tchmachines.com
X-MailChannels-Auth-Id: totalchoicehosting
X-Spot-Bottle: 56a9e9562f4792aa_1605721808648_3445994515
X-MC-Loop-Signature: 1605721808648:3517196023
X-MC-Ingress-Time: 1605721808648
Received: from [136.56.88.61] (port=50418 helo=axion.home.arpa) by pawpaw.tchmachines.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <slblake@petri-meat.com>) id 1kfRal-0002Yr-7n; Wed, 18 Nov 2020 12:50:03 -0500
Message-ID: <5dff4f73463c2a7e7cc8dc8255ae9825e78f4c11.camel@petri-meat.com>
From: Steven Blake <slblake@petri-meat.com>
To: "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, tsvwg IETF list <tsvwg@ietf.org>
Date: Wed, 18 Nov 2020 12:50:05 -0500
In-Reply-To: <AM8PR07MB747626CB7622CB89209018A8B9E10@AM8PR07MB7476.eurprd07.prod.outlook.com>
References: <AM8PR07MB747626CB7622CB89209018A8B9E10@AM8PR07MB7476.eurprd07.prod.outlook.com>
Content-Type: multipart/alternative; boundary="=-sOpiQ0os95m3u3VkfeU7"
User-Agent: Evolution 3.34.4 (3.34.4-1.fc31)
MIME-Version: 1.0
X-AuthUser: slblake+petri-meat.com@pawpaw.tchmachines.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/SFLHqFpIZei6v6qooO101Pzm5s0>
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: Wed, 18 Nov 2020 17:50:37 -0000

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 applicationsThe big L4S benefits were a good
> reason to justify the extra network effort to finally implement ECN
> in general and AQMs in network equipmentTiming is optimal now:
> implementations in NW equipment are coming and deployment can start
> nowDeployment 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 supportCurrent 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
> applicationsWhen 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 vanishNo 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 materializingProduct development of L4S will stall
> and die due to uncertainty on if L4S will finally materializeProduct
> 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