Re: [tsvwg] L4S vs SCE

Pete Heist <> Wed, 20 November 2019 20:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B862D120100 for <>; Wed, 20 Nov 2019 12:20:55 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2L-Vjsue2zUb for <>; Wed, 20 Nov 2019 12:20:54 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::444]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 038761200D7 for <>; Wed, 20 Nov 2019 12:20:53 -0800 (PST)
Received: by with SMTP id c13so308223pfp.5 for <>; Wed, 20 Nov 2019 12:20:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DuqThdOBCfx7mobXyJReDFq6NduoyiBCSwsbacbsphs=; b=dHLD146r8YT8iACNcMgykNvBY6gDDBN0WQ1v7/Xw/k7MVtFvcQpRTfjRHnF6OEUQY7 L8M20uRGdJwjSGk9FZ9D+dww3/CgbmCm76mlNRM3d8Fku2dlvSUcDI1Z6L+ywf3ccWA0 ApZWoFiJlsJUm+q3gqg1iLuW9lzKXGjHYwbjbJm8U8wa0c6knmKej5BH4ce0KKQOT3qz A8wx1HFSSlzzrm74+39OgOM55kXlK0bSaTD3bbaN2xxHJ++ZKo8wC9tQTO7hMnKfCNyf XnNjcpTesRV4pwzSZ3ANNVR6H5unVV7o7Ixj5OKC6cmbIDZcFrv0v8659J7uMmvIppjJ YbyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DuqThdOBCfx7mobXyJReDFq6NduoyiBCSwsbacbsphs=; b=YyacwfzvoYLJognmfGsUV3Chxa1egAZyzgbCoqwdacs8eMBU8ZWV/GBl7g0wszC4ND RHaXY5mIsVRJHPHWJd2rob6n/LVjuINRQ+Y3EmDpIzE3Try8x+7SQdX4GoUioeGuagqz FjYieP6nUmJZb9cJCTQlYKwx+q3XQ7qY9j2HblLiaqpUJllwQg5rD+E88wn/lv6Q8cGE /3CTczHeQHtEXpCu4gFr1EP54b9xplJBseKBiVcuiBULHotOdU/hlmyWbKKgCI/PtDpV 3wESAo87QTuCmFtYun0hrQtAu/Rf2DvQTYBX/ixMPQLToxGXphplblpd6A6ZpFqW3O4t GtEw==
X-Gm-Message-State: APjAAAX+rhNCW+NLn/h7rjYQfVyDxOgQGPBB26eQYbLIkEj8n0WHmWr1 VMmirDPeGbcp5ekHo4rlelxMXg==
X-Google-Smtp-Source: APXvYqxFn+vLBJs5GzBHsDQYnEpAtu5xk0SR0DSJIh+/s9n9euv+9SMmCKo1YjQWaMrRsz7PQoJ0Ag==
X-Received: by 2002:a63:ef17:: with SMTP id u23mr5312432pgh.337.1574281253404; Wed, 20 Nov 2019 12:20:53 -0800 (PST)
Received: from yoda.lan ([]) by with ESMTPSA id q4sm84397pgp.30.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Nov 2019 12:20:52 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Pete Heist <>
In-Reply-To: <>
Date: Thu, 21 Nov 2019 04:20:49 +0800
Cc: Roland Bless <>, Ingemar Johansson S <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: Bob Briscoe <>
X-Mailer: Apple Mail (2.3445.9.1)
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 20:20:56 -0000

> On Nov 21, 2019, at 2:34 AM, Bob Briscoe <> wrote:
> Roland,
> 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.

In my opinion, what would enable future innovation in CCs is a signaling mechanism that is completely safe by design, without the need for protection mechanisms, allowing alternatives to be explored without a risk-benefit analysis.