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

Wesley Eddy <> Fri, 19 July 2019 22:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9079E1200EF for <>; Fri, 19 Jul 2019 15:09:11 -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 G0fowMCiIdMr for <>; Fri, 19 Jul 2019 15:09:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B043120071 for <>; Fri, 19 Jul 2019 15:09:10 -0700 (PDT)
Received: by with SMTP id h18so32651891qtm.9 for <>; Fri, 19 Jul 2019 15:09:10 -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=dbOVz0BNIVMkymCFcLKBcIPN/A+CVZvsVbmvojiniPQ=; b=bGANBo3YFA77axL3ZfjA+Y63XZJZEaIivUyI3OnrtifZYs7kjPCPoP8TCwIEsyMqms ZN+S8DdaICvpA9/VnDJqPhFwQrLQl4DEwDUxUqvjD6apNjGSsrgo93pkijClXPpcisYI orrHS6EJWo19HjKtIaft30Hvjn6YJrBDXRqgSn1K+SXdJXAEAl2mGcJ3ofsBYrhe3VCm vuM0joaAkk391XT52A/GMFygfSja7gmrML9KuzgQM6n4KJ38AfJTwxrQoKWkKv0sa7OV tgPeSCPTJnJaLP8Qt7hc0HWLVuvDeeVQpVSimgA+MV/whOeqZLbJbxWhKIL8hWmqx6ZF 1U2Q==
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=dbOVz0BNIVMkymCFcLKBcIPN/A+CVZvsVbmvojiniPQ=; b=WPMel0NMAmmcej2XVBP3iXA2UTVKxdDfa3fbbJjp1wzLgyFzj3EmaRpgDN+CWhIs05 VVPIB87RXP5DGI57qA1NKTEBAKPyLQIv4IePzwpugPTaa4UdLwP8nw2PxbU1PWZNNI8n mBiDdT/NeJeDcfz95jNQInhbPDw65mKavN64vu9yu4r9iLwjecjblXxXrDsgQFUkWGYR cy+w/MWi9s6JTOptwPYgmEHw5PJougCHk9BlT4PyPv/PmwE/N2G7AfjhvznGyavxLP63 ytTOv5R4q+ZoHjRkQu+wHPZB6/MZLSaP2FqM6hc9K0uCT6GhzFPrS9ooCjpaOtaotCXe FTNg==
X-Gm-Message-State: APjAAAVbW1MKDcuPJGPKkX23HRDzifLI/fiYRu5Ke36NJM+KzJz2PnLE CEiYcvHUzy3a2ufU2j26NVgv7I5Z
X-Google-Smtp-Source: APXvYqzhqarr6tOLr6lrzKpGZoiwDDl+24QALkHKHZBUKKaCbkxbXzxrOIuu0PRALYFPQSY8nXWOxg==
X-Received: by 2002:ad4:55a9:: with SMTP id f9mr39866942qvx.133.1563574149126; Fri, 19 Jul 2019 15:09:09 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id a54sm16442671qtk.85.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jul 2019 15:09:08 -0700 (PDT)
To: Dave Taht <>
Cc: Dave Taht <>, "De Schepper, Koen (Nokia - BE/Antwerp)" <>, "" <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Wesley Eddy <>
Message-ID: <>
Date: Fri, 19 Jul 2019 18:09:06 -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 22:09:12 -0000

Hi Dave, thanks for clarifying, and sorry if you're getting upset.

When we're talking about keeping very small queues, then RTT is lost as 
a congestion indicator (since there is no queue depth to modulate as a 
congestion signal into the RTT).  We have indicators that include drop, 
RTT, and ECN (when available).  Using rate of marks rather than just 
binary presence of marking gives a finer-grained signal.  SCE is also 
providing a multi-level indication, so that's another way to get more 
"ENOB" into the samples of congestion being fed to the controllers.

Marking (whether classic ECN, mark-rate, or multi-level marking) is 
needed since with small queues there's lack of congestion information in 
the RTT.

To address one question you repeated a couple times:

> Is there any chance we'll see my conception of the good ietf process
> enforced on the L4S and SCE processes by the chairs?

We look for working group consensus.  So far, we saw consensus to adopt 
as a WG item for experimental track, and have been following the process 
for that.

On the topic of gaming the system by falsely setting the L4S ID, that 
might need to be discussed a little bit more, since now that you mention 
it, the docs don't seem to very directly address it yet.  I can only 
speak for myself, but assumed a couple things internally, such as (1) 
this is getting enabled in specific environments, (2) in less controlled 
environments, an operator enabling it has protections in place for 
getting admission or dealing with bad behavior, (3) there could be 
further development of audit capabilities such as in CONEX, etc.  I 
guess it could be good to hear more about what others were thinking on this.

> So I should have said - "tosses all normal ("classic") flows into a
> single and higher latency queue when a greedy normal flow is present"
> ... "in the dualpi" case? I know it's possible to hang a different
> queue algo on the "normal" queue, but
> to this day I don't see the need for the l4s "fast lane" in the first
> place, nor a cpu efficient way of doing the right things with the
> dualpi or curvyred code. What I see, is, long term, that special bit
> just becomes a "fast" lane for any sort of admission controlled
> traffic the ISP wants to put there, because the dualpi idea fails on
> real traffic.

Thanks; this was helpful for me to understand your position.

> Well if the various WGs would exit that nice hotel, and form a
> diaspora over the city in coffee shops and other public spaces, and do
> some tests of your latest and greatest stuff, y'all might get a more
> accurate viewpoint of what you are actually accomplishing. Take a look
> at what BBR does, take a look at what IW10 does, take a look at what
> browsers currently do.

All of those things come up in the meetings, and frequently there is 
measurement data shown and discussed.  It's always welcome when people 
bring measurements, data, and experience.  The drafts and other 
contributions are here so that anyone interested can independently 
implement and do the testing you advocate and share results.  We're all 
on the same team trying to make the Internet better.