Re: [tsvwg] [Ecn-sane] Comments on L4S drafts

Wesley Eddy <> Fri, 19 July 2019 18:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AFC6312034E for <>; Fri, 19 Jul 2019 11:33:45 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 HjRyKBt_aK6N for <>; Fri, 19 Jul 2019 11:33:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 539D6120323 for <>; Fri, 19 Jul 2019 11:33:40 -0700 (PDT)
Received: by with SMTP id m24so60420678ioo.2 for <>; Fri, 19 Jul 2019 11:33:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=CHbeoSjiydIbgoMJhJU1aIt94S1Qcp2PC7atnk0lYq0=; b=U5N+alTVof0qyQfdAC/f/O06JnfCGSF9ADysT3tuwXA/80cgQZRB1l0bC0pQrfcR9v 15VevVZnm455DkdIlmmYiuTRhwiKF6MFnqyekuiVpEHj/em0wGQXkxNPpLCDUingEIv7 XNO8YCo2Px49QAl+URxsfxJlXB7tixQ6epm6LYhCb4xrPYkFpjUA16fWAUoCa6FzYTGh uiJyrF2UwUgfPlB1q7gbHTWB+tUm58N/5daTpGUIxDPbzknOG7Hg3ToWK0VcFWvzVCAr 2K89skY0i9b2kmHqeSGOSf4FoAr72uMh+qppK7MUawzKmJ729VqxvZnnSlGB3vhWWyn+ tOmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=CHbeoSjiydIbgoMJhJU1aIt94S1Qcp2PC7atnk0lYq0=; b=cED5BVpbtVgm82AbRfISsEmo8NEv9LcJKBSqeZemPEnqIoNJcillbuLg1TF22ckjLg IpGySpmJc4llQzmRJeLA0mo1ME1Iax+oIJ8rJT3ayfpXyZN3oL8JdyOHDfRdOJ0sqfGg zB5b3VGNtAivvAhlbYnHRXT1rJ9RwL7/JTLGpZKs3KAvn6rsaigz8OuiHly9R4ewEhO3 R0NXxDmyLXFT1PsEUaNfMcmshnLr3VYP1kpWBvn5oWubUfXYDTEVnDHS1Edworww0lF2 Y5skPVHwh/RvGaHMNu5CbN1yqHY63XwGo6GpCR+BJE6zsLtd3eI2Sz50lHCUFaXUIGPU CJQw==
X-Gm-Message-State: APjAAAXMd+LKcKkIVnzz5N2E6flEmzTl5U5wGSOqsgRSUQUULTwUYZgU SlxQRXdAmj/1IaH65D1xuOLtdOlg
X-Google-Smtp-Source: APXvYqwPRKGqQn5Y8exhwpirU2TLrsMvvZ7uWlX07jiF6IWHKCxpX5iQoSpOfMEIsHcKNsoGK6s/AA==
X-Received: by 2002:a5e:9314:: with SMTP id k20mr31598752iom.235.1563561219339; Fri, 19 Jul 2019 11:33:39 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id p3sm37535817iom.7.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jul 2019 11:33:38 -0700 (PDT)
To: Dave Taht <>, "De Schepper, Koen (Nokia - BE/Antwerp)" <>
Cc: "" <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Wesley Eddy <>
Message-ID: <>
Date: Fri, 19 Jul 2019 14:33:37 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [tsvwg] [Ecn-sane] Comments on L4S drafts
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: Fri, 19 Jul 2019 18:33:46 -0000

On 7/19/2019 11:37 AM, Dave Taht wrote:
> It's the common-q with AQM **+ ECN** that's the sticking point. I'm
> perfectly satisfied with the behavior of every ietf approved single
> queued AQM without ecn enabled. Let's deploy more of those!

Hi Dave, I'm just trying to make sure I'm reading into your message 
correctly ... if I'm understanding it, then you're not in favor of 
either SCE or L4S at all?  With small queues and without ECN, loss 
becomes the only congestion signal, which is not desirable, IMHO, or am 
I totally misunderstanding something?

> If we could somehow create a neutral poll in the general networking
> community outside the ietf (nanog, bsd, linux, dcs, bigcos, routercos,
> ISPs small and large) , and do it much like your classic "vote for a
> political measure" thing, with a single point/counterpoint section,
> maybe we'd get somewhere.

While I agree that would be really useful, it's kind of an "I want a 
pony" statement.  As a TSVWG chair where we're doing this work, we've 
been getting inputs from people that have a foot in many of the 
communities you mention, but always looking for more.

> In particular conflating "low latency" really confounds the subject
> matter, and has for years. FQ gives "low latency" for the vast
> majority of flows running below their fair share. L4S promises "low
> latency" for a rigidly defined set of congestion controls in a
> specialized queue, and otherwise tosses all flows into a higher latency
> queue when one flow is greedy.

I don't think this is a correct statement.  Packets have to be from a 
"scalable congestion control" to get access to the L4S queue.  There are 
some draft requirements for using the L4S ID, but they seem pretty 
flexible to me.  Mostly, they're things that an end-host algorithm needs 
to do in order to behave nicely, that might be good things anyways 
without regard to L4S in the network (coexist w/ Reno, avoid RTT bias, 
work well w/ small RTT, be robust to reordering).  I am curious which 
ones you think are too rigid ... maybe they can be loosened?

Also, I don't think the "tosses all flows into a higher latency queue 
when one flow is greedy" characterization is correct.  The other queue 
is for classic/non-scalable traffic, and not necessarily higher latency 
for a given flow, nor is winding up there related to whether another 
flow is greedy.

> So to me, it goes back to slamming the door shut, or not, on L4S's usage
> of ect(1) as a too easily gamed e2e identifier. As I don't think it and
> all the dependent code and algorithms can possibly scale past a single
> physical layer tech, I'd like to see it move to a DSCP codepoint, worst
> case... and certainly remain "experimental" in scope until anyone
> independent can attempt to evaluate it.

That seems good to discuss in regard to the L4S ID draft.  There is a 
section (5.2) there already discussing DSCP, and why it alone isn't 
feasible.  There's also more detailed description of the relation and 
interworking in

> I'd really all the tcp-go-fast-at-any-cost people to take a year off to
> dogfood their designs, and go live somewhere with a congested network to
> deal with daily, like a railway or airport, or on 3G network on a
> sailboat or beach somewhere. It's not a bad life... REALLY.
Fortunately, at least in the IETF, I don't think there have been 
initiatives in the direction of going fast at any cost in recent 
history, and they would be unlikely to be well accepted if there were!  
That is at least one place that there seems to be strong consensus.