Re: [tsvwg] L4S vs SCE

Bob Briscoe <> Thu, 21 November 2019 14:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68AC11200EC; Thu, 21 Nov 2019 06:45:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 6dIanhUHi6Q1; Thu, 21 Nov 2019 06:44:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3CAAB1200E3; Thu, 21 Nov 2019 06:44:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VNXRDGfMS52XQ/T0m5RActDU0xbVCz64pWi+AVGm8Y8=; b=M6FDqKSlcfxtUDs2Cj2B7ovGqL LZCdoEIj2zrsUM3lQZiwPtn6dAl6U8b1hG7uFr63SvS5a9AOoO235pkuEeWgnXmGOfsrsn6f3MFka dHKYc9Tn1tBzjAg6GpO1MPhzKMq8rwz7Oc2sYR9+h85Hr2h5Dnuc1MImJI+PumYjX/RbPGj+So4Pj MBRYBR6vKXbLn0tRsAo80sQC2/dHhCxgbFmoWYLdaIX1ag7kQGA7hNHhLRsWtSv8DqOruRvTXz4Oh voWVVCgKDO99+zU2T2D0iGM/34C1TTcr4yf/NGjbOZbd95E4mwOAPYGYEy/1HSRn59HqmBxhKV33p BF/phWLQ==;
Received: from [] (port=43560 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <>) id 1iXnhX-0008V3-UD; Thu, 21 Nov 2019 14:44:56 +0000
To: Roland Bless <>
Cc: "De Schepper, Koen (Nokia - BE/Antwerp)" <>, Ingemar Johansson S <>, Kyle Rose <>, "" <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Thu, 21 Nov 2019 22:44:52 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [tsvwg] L4S vs SCE
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, 21 Nov 2019 14:45:00 -0000


I'm not getting it....

On 21/11/2019 09:32, Roland Bless wrote:
> Hi Bob,
> see inline.
> On 21.11.19 at 19:34 Bob Briscoe wrote:
>> On 20/11/2019 21:22, Roland Bless wrote:
>>> Yes, but as I also expressed my concerns w.r.t. the L4S codepoint
>>> earlier, at the cost of binding this to a quite fixed set of L4S
>>> behaviors and "burning" the last ECT codepoint. Personally, I like
>>> concepts with a little bit more potential to be useful for future
>>> development (evolvability) of congestion controls, e.g., BBRv2 and
>>> LoLa could also benefit from an SCE-like marking...
This last sentence... please really spell it out what you could possibly 
be meaning here. What has made you suddenly think this particular 
marking scheme has got magical properties that bestow evolvability? I'm 
serious, if you can't explain why you've said a sentence like this, it 
implies you are under the spell of some cult or fad.

>> My whole purpose in solving the problem of deploying scalable CCs over
>> the Internet was to re-juvenate evolution (to widen the range of
>> applications that could be supported by different transport behaviours,
>> particularly for real-time with low latency and high throughput at the
>> same time). One of the main things that has stopped CCs evolving so far
>> is the need for friendliness with the Reno behaviour that was not
>> scaling over the years.
> FWIW, our delay-based approach has deployment problems at the
> other end of the spectrum: it gets suppressed by loss-based CCs...
> (and we don't want to sacrifice our low delay goal).
>> If SCE is primarily supported in FQ AQMs, that will constrain flows to
>> be capped at the rate that FQ gives them. How is that doing anything
> I was solely referring to the marking behavior of SCE, not a particular
> implementation based on FQ-AQMs.
This implies you believe all that silliness about a shallower SCE 
threshold not starving an SCE flow in a single queue, because it makes 
SCE flows not want to use the queue.

>> other than massively constraining future evolution of CCs, especially
>> real-time ones? See Per-Flow Scheduling and the End-to-End Argument
>> <>. I don't need
>> to tell you that the e2e argument is all about giving end systems the
>> power to innovate without permission.
>> Anyway, what are you imagining would stop CCs evolving alongside other
>> scalable CCs? In much the same way CCs have always evolved. With L4S you
>> have a clean slate that seems just like a FIFO with a shallow ECN-only
>> immediate AQM. And other flows are causing you hardly any delay and very
>> rarely any loss. Think of all the things you can do with that. Go
>> evolve, Roland!
> I already said that the Dual Queue AQM is nice, but comes with the
> problem due to its built-in dropping law. Other CCs may react differently
> and BBR was one example of newer CCs that did not work in the L4S queue
> without further adaptation.
The built in dropping law is for the old traffic ('pre-evolved' if you 
like) that doesn't respond to anything else but loss. That's what 
drop-based AQMs were for - to fool Reno etc into thinking they had hit 
the buffers, so to speak.

>   > The key thing here is the wording of the Prague requirements
>> <>.
>> We have a session in the 'Prague' side-meeting tomorrow to review them
>> (and I encourage this on this list too).
>> Later down the line, if the L4S experiment is successful, there will be
>> an opportunity to review these requirements if a standards track doc
>> replaces the experimental (it is easier to relax CC requirements than
>> tighten them). So, for the expt track, the requirements are designed to
>> protect competing flows from harm in a tighter way than you might find
>> in RFC5033 or similar.
>> Nonetheless, even the 1/p isn't tightly spec'd, quoting:
>>     The inverse proportionality requirement above is worded
>>     as a 'SHOULD' rather than a 'MUST' to allow reasonable flexibility
>>     when defining these specifications.
> Yes, but something has to be implemented (in hardware) and therefore it
> is fixed for some time and it should be consistent along a path, so I
> don't see a viable path for evolvement of this coupling law...
Why does the coupling law need to evolve? It's a relationship between 
something invariant (scalable) and the past (which is over, by 
definition, so it's not going to change now).

If you want to evolve, you select what's best for you - probably the 
nice clean L4S ECN queue. I still don't get what sort of evolution you 
can't do? Evolvability isn't about a researcher being able to do what 
they'd like. It's about being weeded out if what you think is best turns 
out not to be.


> Regards
>   Roland

Bob Briscoe