Re: [tsvwg] Reasons for WGLC/RFC asap

Pete Heist <> Thu, 19 November 2020 16:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75B6E3A0836 for <>; Thu, 19 Nov 2020 08:22:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hb6bHg7uFnGX for <>; Thu, 19 Nov 2020 08:22:20 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 167A13A07F9 for <>; Thu, 19 Nov 2020 08:22:19 -0800 (PST)
Received: by with SMTP id s8so7013727wrw.10 for <>; Thu, 19 Nov 2020 08:22:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version; bh=IHGWA+5sJHh8n6Cqfmc0WwVYejjevlN73RWf4gOFmZo=; b=g1d/5S9L9yVsM4DlUKED8/Gf3zCwnyVSHb/YCaIJj/v/9DCqTSYCsd+UVJhDv34f5J saGi+D5VqwjN8oceM5sTo97Y5/53ppyLy5B1G0jDN7eDnd4DTzLOazlJpC79ORgeqbYa vy+9RHspoa09I8dpIQ41WYkjr78TjeJq78H1gLOtIh4oh8/q1HwuRVS8vYQMrf+9qyBi /cnziG7Vc2I9nJsJRd0Kn/MQK80nSo4d78GpwgfPe6xbhSVuaRHnT2FqyDD5Lcxaag7f HXFtcyiSnuHGeVLwQ8S4F/LIerQkCZRVv0Gf0TMd5Blk8RKKDfsePdmdy9/E4+fTBeEE YZBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version; bh=IHGWA+5sJHh8n6Cqfmc0WwVYejjevlN73RWf4gOFmZo=; b=N3w0ghkCtn3hOU7rYwZOmBRKWsOJu5TQhFQssQZNiQkSoK0jJw0HCJR+MVZNHas1ZT XiZ5RmpzCutjPflQnqYSFU+3PubQyFS7ljYK+nll4v0kIp94+XsO8Efmr7Gfvl4duTEh 14gNKzA8nsbt0saJHHnMWl4tcCN250r9w4GM+rKmKjAdUVwevfRndtqKzNwCpnR2IybW AtJCm9l970Yy//QBAhahOwK3/MR1Ms+fPXwQ4eam7CqOGOCR2fi0MpLluhabjLrE6+ea rOdaObjueGKFrSYTkDzFfkEM8KC3kcTfPtIsnKxRMmWud2KLw1PgOJ7oIIaDtvlAUReG bHfQ==
X-Gm-Message-State: AOAM532zqbpTMk3jnZt9K0d3oO8dI5t2Q6vSimoza5lIBv+7HYFvCoDa G1pphwkiDVGI9I/6Fx2Zki4OY7qLLV7l0Q==
X-Google-Smtp-Source: ABdhPJwhS/Ny4FMGW77+GpY9rcSipPzBa3OF6DLMfLIn0BMMjyD9foKY7Sc/tsHPHzrYknwPuPB9RA==
X-Received: by 2002:adf:e287:: with SMTP id v7mr11575869wri.252.1605802938482; Thu, 19 Nov 2020 08:22:18 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id d3sm580001wmb.5.2020. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Nov 2020 08:22:17 -0800 (PST)
Message-ID: <>
From: Pete Heist <>
To: "De Schepper, Koen (Nokia - BE/Antwerp)" <>
Cc: tsvwg IETF list <>
Date: Thu, 19 Nov 2020 17:22:16 +0100
In-Reply-To: <>
References: <>
Content-Type: multipart/alternative; boundary="=-FpJ3lFX1iZLGH6Z+RlT7"
User-Agent: Evolution 3.38.1
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [tsvwg] Reasons for WGLC/RFC asap
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Nov 2020 16:22:23 -0000

Hi Koen,

Rather than thinking of this as advantages and disadvantages to
waiting, I see it as an engineering process. It was decided earlier
this year that the L4S proposal has enough support to continue, so
we're on that path now. Part of that decision, as I understood it, also
recognized that there are valid safety concerns around compatibility
with existing AQMs, and some solution needs to be devised.

RFC3168 bottleneck detection was added to TCP Prague, which appears to
be difficult to do reliably when there is jitter or cross-flow traffic,
and it has since been disabled in the reference implementation. The
l4s-ops draft was started, but isn't complete yet and may need WG
adoption as part of a LC. We can then decide how effective the proposed
mitigations are against the risks and prevalence.

To start a WGLC now would circumvent that earlier recognition that a
safety case needs to be made. Meanwhile, since testing showed that
tunnels through RFC3168 FQ AQMs are a straightforward path to unsafe
flow interaction, along with other issues relative to the goals, it
doesn't seem like the engineering process is done just yet.


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)
> * Larger scale (outside the lab) experiments are blocked by non-RFCs
> status
> * 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.