Re: [tsvwg] Reasons for WGLC/RFC asap

Gorry Fairhurst <> Thu, 19 November 2020 16:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 898163A09AD for <>; Thu, 19 Nov 2020 08:35:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kXSNfJRomStb for <>; Thu, 19 Nov 2020 08:35:04 -0800 (PST)
Received: from ( [IPv6:2001:630:42:150::2]) by (Postfix) with ESMTP id D0F2C3A0989 for <>; Thu, 19 Nov 2020 08:35:03 -0800 (PST)
Received: from GF-MacBook-Pro.lan ( []) by (Postfix) with ESMTPSA id A83FF1B00210; Thu, 19 Nov 2020 16:34:58 +0000 (GMT)
To: Pete Heist <>, "De Schepper, Koen (Nokia - BE/Antwerp)" <>
Cc: tsvwg IETF list <>
References: <> <>
From: Gorry Fairhurst <>
Message-ID: <>
Date: Thu, 19 Nov 2020 16:34:58 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.4.3
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------2828501A4DF23654F609B8FC"
Content-Language: en-GB
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:35:07 -0000

On 19/11/2020 16:22, Pete Heist wrote:
> 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.
By the way, I liked your data - and it helped me a lot to look at this, 
thanks very much for doing this.

It would help me if you clarify what you mean by  "unsafe" - to me 
"safety" relates to traffic unresponsive to drop, as in CBR traffic, 
etc. I've not understood how CE-marked traffic can erode safety, but 
maybe I missed something?

I'm not sure why "tunnels have crept in here. There have always been 
side-effects with classification (and hence scheduling), but I don't see 
new issues relating to "tunnels" with ECN.

I'm not commenting on when the Chairs think a WGLC will provide useful 
information, we'll say that in due course.

Best wishes,


> Regards,
> Pete
> 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.