Re: [tsvwg] Follow-up to your DSCP and ECN codepoint comments at tsvwg interim

Sebastian Moeller <> Sat, 07 March 2020 19:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78EA93A1870 for <>; Sat, 7 Mar 2020 11:18:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.111
X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rCxYn7CpkFO2 for <>; Sat, 7 Mar 2020 11:18:08 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C2A93A0D84 for <>; Sat, 7 Mar 2020 11:18:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1583608602; bh=p0R7HW0bdlr9fUAq0E4+aHK/vKtylhhq5EDOMEpbAfI=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=DRQZO8Cj0RLilLvK0CS3VV7ne/b/3M7gKZzFREnmfLHVcl6GwDD6k1YQrCo8E5pEp onTZJ7ioLtN3dZhjCPST3dARmILrFvPQUU0iNPE3WDDuzUc4+7JIYKJvQ72fFTOEjG GhfxyGdBsDHBU+9LvCCnqhqz1Pf/l2gRL4j3b/FI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([]) by (mrgmx004 []) with ESMTPSA (Nemesis) id 1Mo6v3-1jgeJ841v9-00pdms; Sat, 07 Mar 2020 20:16:42 +0100
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <>
In-Reply-To: <>
Date: Sat, 07 Mar 2020 20:16:40 +0100
Cc: tsvwg IETF list <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: tsvwg IETF list <>, Bob Briscoe <>, Steven Blake <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:d/CCfoFQsG8MjJWkOeOOB4VXtOcQS6DCN8VYP0MvTbqRLevsiGq Y0b1nDm2R3Dfg+fIxDWX1pUzIT1oM+pBc+EhNdlEL1B0g+Pm0yDMlJBXd7m4yg/QdZQLTiU 0WoyXzxEvtyLFxpq/0d7QAwYrJMYgzCCMq+GFZLJ9XnhVMD4rmCNNIHXEiDtlbbhf1r2/xe 4nGcBcWFX56+sizmbzI5A==
X-UI-Out-Filterresults: notjunk:1;V03:K0:eb12S+vAecM=:GLUUcnNnRvPZlDeHZQWVwV vA99+OgtoosM8Q8GOoTrwFIwSZrY7O9JccUeqh4iOnVu4kRmtfNxLLBdvqSBklKCbU+JtblRm i//qLh+LnxWKsm3omeGLpGxnLMChtuxhJjws8JR8/7EFNuKu43E7x9oUM4al4fHaxuvaiqBfn 2fnDj4Q006wp2jo3sBqjX053lsOOHKBywjlC73auwaVhDiDqCGc66gYeNklxBOLaaNVjKRlZd Q8J+E6vMbWd0M0pKr1Ca5+3SkcHVjFM5CBLj8TYHHqiICzWyQfWlODLqbaKhycgQ5VQkGHDfQ uq23KS863Z2CgZhXyCE9w72zgUqG7ttWbeGjpYn6yM59JjIUbwX2m5AHa3PAzwZWpTfxDivBI pR6t2FuRKAv49VKKMGbDvtHkHHDJGlVq4eqCD3GQtwlDgAkxOSqZV9q+Du0fa08ggisVmvrpi X/3fRVXm+yFlNq2ZPNXofhQvRMUaJwMst0xhqJ85qpdzqJeZk/RzHyrQx3Tak0Xlu53YhGWhD CJZ99KkHMIGN2k+89nA8UdrdkQ8MEI+gaqLkxT/BK4hiGs2Ocq7nnJNQVwq1BpMqpKFjRhIyh ESqbYjktNl39NEwT+YYux7F7o+eeONTb1UoYAQUDoZY3GdItcL5684kbpF85KKowgNN/O6324 wl4+ZqgjqOrOzDHT8NHHhHvikOVOcr6uAjk5Md8El/dG3TaPe+LgpTN3bP+0e7mefyrbRRyeo BTDesxIaZ4QwnopK6GszV1y09JgYAGDvga2TrVulyVBOWFAE+6tQKQVsBQl7Sis+uTJEjhzmK NV9Hat0w64thr7/1Px62I7IcfQWKMhF82Rv3kEfSj0EUPkxRAsrv/uhs9elkHJVdcwwM+iNJD slNfe78end6AZ+nDQOQqjVZjN2flmtmCwQgDynx+Bz1KPm7Ee7v5vdPrAyRqXmicnQhUZGpgG 6eAN0/4RkzOnZDnpg03u6qPkuI6MiizlzI/I3meAuNHMr9JdG6lV8cq2j9O+GRPnYH12m8n+S VgDUnuaMxdeicZDJDTE1xbRH/ZkfUXtCaq893fg8PxsfccSIj/WR9s4hhLJdWy0xhyB59Et7+ 4Jcl5X0Uenh1amXODeXT2X4YQVJg1bE4+aa+KAqsgknQdpQi1i/EyFJRVyVEEbfMMR4rM3CdZ M9kUSLABDI0PSorfz96RBWEOGMUcVNBz88fJQcsKcMaVvmfK7nB/JEwObBlFOGMaisRgyI1SY PftV9FZt1u2UR5uX6
Archived-At: <>
Subject: Re: [tsvwg] Follow-up to your DSCP and ECN codepoint comments at tsvwg interim
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: Sat, 07 Mar 2020 19:18:11 -0000

Dear All.

I fully understand the challenges of using DSCPs end to end, and yet DSCPs still seem to be the IETF's endorsed intra-domain and end-to-end marking mechanism (see RFC 2474). Any other marking use-case (like the LE PHB) could lay claim on ECT(1) by the same rationale as L4S as it would be currently more reliable. Sure, L4S could claim that it also uses functionally uses ECN and hence has a slightly stronger claim, but since the L4S arch draft explicitly mentions allowing non-responsive bounded-rate (and hence essentially non ECN-aware) flows in the LL queue it seems clear that ECT(1) in addition to all it's other issues is not really fulfilling L4S's marking needs exhaustively.

That said, the only real uses L4S is likely going to see any time soon, IMHO, are those that have an immediate monetary advantage for the ISP rolling out and operating the L4S infrastructure, and hence SLAs between content suppliers and ISP that make sure to conserve the L4S DSCPs seem like a natural solution to the issue. 
	In the spirit of walking before running it would IMHO behoove the L4S effort not trying to solve all potential problems a priori, but rather experimentally demonstrate that even a restricted scope L4S deployment has actual merits in real life. 

More below in-line.

On March 7, 2020 1:34:22 AM GMT+01:00, Bob Briscoe <> wrote:
> Steve,
> I had audio problems during the chairs slides at the tsvwg interim.
> Now I see the following two comments of yours in the minutes, I'd like 
> to follow-up:
>> - Steve Blake mentioned that L4S could be made compatible with each.
> Can you say more about what's behind this idea? or point me to where 
> you've already said it?
>> - Steve Blake noted anyone running these experiments will tinker with
>> boxes, so may handle the DSCP bleaching concern.
> Unfortunately, that's only partially true. It's fairly true for 
> CDN->user applications. However, for (say) conversational video or 
> online gaming, AR, VR, etc, which are particularly important targets 
> apps, the path is often either accessISP-accessISP or 
> accessISP-cloud-accessISP. Altho most access ISPs nowadays are pretty 
> tightly meshed with other access ISPs (with less intermediaries than 
> there used to be), there are still significant numbers of cases where 
> two access ISPs are not directly connected.
> Anyway, if user B's downstream is the bottleneck for user A, even if
> ISP 
> B doesn't bleach Diffserv, the DSCP is still no use if ISP A bleaches, 
> or if an intermediary does.

	[SM] That really just would show that there is a business case for ISP A and B to connect directly in a DSCP conserving fashion....

> See 
> for write-up of the pros and cons.
> Network traversal is already a difficult problem, even with just a very
> few ECN problems. We really don't want to make this impossible. With a 
> 3-part (sender-bottleneck-receiver) L4S deployment, there is already 
> enough deployment barrier without adding Diffserv traversal to make 4
> or 
> more parts (sender-border-bottleneck-receiver). For SCE, there's
> already 
> 4-parts to deploy (tunnels added), so let's not countenance making that
> 5 or more.

	[SM] As mentioned above hat same rationale affects all PHBs that desire end to end persistence. What makes L4S so much more deserving than other PHB's so that the IETF should grant it special preferential treatment? 

	It seems worth mentioning, that today bidirectional FQ on an end user's access link run on the CPE, does already achieve median inter-flow latency-under-load-increases of ~ 5ms, so the incremental gain for switching to L4S will be to get that latency increase down to ~1 ms for LL-flows, while increasing it to 15ms for non-LL flows. These are pretty moderate gains for considerable costs and side-effects! 
	I would love to learn which novel use-cases will be possible by shaving off these additional 4 ms of queueing related delay that will not work with a 5ms target delay? And wonder if any of those that apparently require hard real-time guarantees in the handful of milliseconds range from the network should be run over the shared internet to beginn with independent of the number of parts between the endpoints....?

IMHO, that is orthogonal to the question of how to make 1/p-cc-response type flows equitably share the internet with 1/sqrt(p) type flows. Conflating this by overloading the "I desire LL queueing" marker with the "I will respond in a 1/p-type fashion to CE markings" is really just creating additional unnecessary "coupling" with considerable side-effects. 
As the SCE proposal demonstrates, 1/p and 1/sqrt(p) signaling can concurrently equitably coexist (currently with a few restrictions on propagating signals when decapsulating tunnels), without needing to change the semantics of what CE means, so all this is left to do is solve the orthogonal problem of steering flows into "low-latency" or "besteffort-latency" queues. As far as I understand the IETF's solution for that is DSCP/PHB. 
And for a realistic scope* of an experimental deployment of L4S requiring at least to pair L4S's ECT(1) marking with a DSCP (for the experiment eg out of the "xxxx11" experimental / local use range) does not seem onerous but rather prudent and cautious.

Best Regards

*) L4S is not going to work well over arbitrary internet paths, period. It does have a decent chance over well curated relativ "short" (measured in hops and/or ASs) path, but over these DSCPs can be made sufficiently reliable already.

> Bob