Re: [tsvwg] L4S vs SCE

Bob Briscoe <> Wed, 20 November 2019 18:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E6EF0120111; Wed, 20 Nov 2019 10:34:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 cyvX-6EN3k7E; Wed, 20 Nov 2019 10:34:49 -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 512A7120020; Wed, 20 Nov 2019 10:34:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding: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=5C50xAn58QnsZ+2BkayFLk8VeYuBl8D+nsC7aILNKq8=; b=E4/mOX5YaRFKtQyKY3+EVwC66 CCZsRCZsLBqD2XqmLuClXvKkD9v7+BNK6TsX5FHMnn/Fz9+diaTw58cWpPzh6lGWJ0OQFNfV5pWl7 MkvoILPz6L87K7GdN30hW/T2qgd9HW3uOHQdU1ILMfEplzUCFlNfxbQivrLlNktkwFlLX7dez3N6L pEEg02qqSNlKQJ5vbXVHoulg5EKk8XXmjZtxJAJm2vwTfU208Af9PaH+vyV+/64uMkaeVSD983lnr SvW5rdHZuIdAZ5XH/abMOimys5oAS3YVR85wL7Jp7E/Oskm97Emc44ZyJ1KJ+0YywNh1JWrT8w3+O EJQv3E2gg==;
Received: from [] (port=34114 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <>) id 1iXUoR-0002Qw-Gd; Wed, 20 Nov 2019 18:34:47 +0000
To: Roland Bless <>
Cc: "De Schepper, Koen (Nokia - BE/Antwerp)" <>, Ingemar Johansson S <>, Kyle Rose <>, "" <>, "" <>
References: <> <> <> <> <> <> <> <> <> <>
From: Bob Briscoe <>
X-Remindit: Thu Nov 21 2019 08:00:00 GMT+0800 (+08)
Message-ID: <>
Date: Thu, 21 Nov 2019 02:34:44 +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: multipart/alternative; boundary="------------CB0CC06FE7E5512D73AFE5C9"
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: Wed, 20 Nov 2019 18:34:53 -0000


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...

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.

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 
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!

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.

As another example, "MUST reduce or eliminate RTT bias" is deliberately 
expressed with wriggle room, but with enough strength to address the 
harm issues.

These are all up for review. If you care about evolvability, this is 
where your focus should be.


Bob Briscoe