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

Jonathan Morton <> Sun, 08 March 2020 01:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10F713A1ECF for <>; Sat, 7 Mar 2020 17:35:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 aQmNLC37TcQm for <>; Sat, 7 Mar 2020 17:35:17 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF8E03A1ED1 for <>; Sat, 7 Mar 2020 17:35:16 -0800 (PST)
Received: by with SMTP id j15so4809294lfk.6 for <>; Sat, 07 Mar 2020 17:35:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=B9mQQxeSeF5GX94ZFzGQfhwdHNnev8wmapcPXo+11zU=; b=Kj0ZAwrYT9PZ05XtNqP/2jRy5i514PRz65AQDt2ED7DM5m5N9GhzpO9sr+RGC2jcdw zdoSknsrdWtNOi743Wc5qcqRf0RMKw5xcNTSaIfJ0MIvAOXmRJUjq1zsqhQ8qTTRR8jc DN2PsCOxWlteS7z7oxTEVFzfvpBnXhSnC28JR6wwJjM/3+4NXNm1boM8UGQ//Tzf2sFl 7PR4hbyEwv4G4gt+RLq1Ih1+nqpKkdtImisXqZCvcwMPUf2WJqimG/gkv53ylj/yjDU2 lG7x45pZdjYEK1shbVaznunU2fQyxZn11AmpTlfCHRKujWdcBjfqxsGR0ntokM3Rrb8w +S2w==
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=B9mQQxeSeF5GX94ZFzGQfhwdHNnev8wmapcPXo+11zU=; b=AVIkv9yKqCOnGnFtGR5EkyH10nS6YuVmRQTM6LpklUm89TFdyZbhkddx32SNAZGbsE 5ADaT0mjUA5vDHvImcPyIl2yeRcxFEy8/czscCkifJbH5InFKTmkzyFsfRF+EU9UlpTg YWRr2U1HVtbgor6JfaSAhnaet75YtrVhqNsPt6mdUvrnvR3MGMPdDEYXb/MPs8R2FiWt d+FUWyYdSnrE5jSz9Ux6BS5c+GeFDn/bkPTR4ews4lxrsOZg9zkAnBum7QIP32Oqtt0S CHE/077H8qGArOvnF7QQHqHpIQKyd9yJ6E5y0kVDaihIHZshUZ7ZfjljFWh+75byTcnB S92w==
X-Gm-Message-State: ANhLgQ3OmPZadED6xOpQ2gxC0K0Zpg0FRgNEIBuXySKDSVq1yo7BoKwf c/mvjpZu8X6l8IdY07aUbgM=
X-Google-Smtp-Source: ADFU+vusrVStY1VJvEE1ALQgdPp2s7OlMM81uRMDKO5eA0bXDSgyavFjoLOaSKxClXdhWH13Rm0uNQ==
X-Received: by 2002:a19:7d04:: with SMTP id y4mr5667958lfc.111.1583631314962; Sat, 07 Mar 2020 17:35:14 -0800 (PST)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id r10sm7112792ljk.13.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Mar 2020 17:35:14 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Sun, 08 Mar 2020 03:35:12 +0200
Cc: tsvwg IETF list <>, Bob Briscoe <>, Steven Blake <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Sebastian Moeller <>
X-Mailer: Apple Mail (2.3445.9.1)
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: Sun, 08 Mar 2020 01:35:19 -0000

> On 7 Mar, 2020, at 9:16 pm, Sebastian Moeller <> wrote:
> 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. 

I broadly agree with this argument.  And, as noted further down, the relatively small improvements in latency will only be significant on paths where the baseline RTT is already quite small, implying both a short geographic distance and a small number of routing hops between the endpoints.  These are exactly the conditions most likely to be able to deploy a Diffserv solution through the normal SLA process.

The challenge with L4S is that it relies on the classifier not only for low-latency service (a performance improvement, whose loss would typically be tolerable) but to configure the type of congestion signalling (a safety requirement, whose loss would be dangerous).  This is, I think, why they sought a classifier which would reliably traverse AS boundaries.  This design requirement ultimately stems from their early design decision to perpetuate the DCTCP signalling method, which changes the semantics of CE.

Unfortunately this is not the only requirement exposed by that decision.  Not only must the classifier signal *survive* throughout the path, but every potential bottleneck node must *understand* the classifier and apply the different congestion signalling.  This puts L4S back in the position of having to limit deployment to controlled environments, only now without the Diffserv "containment" mechanism to help indicate when it strays outside of such an environment.  This in turn leads to the present attempt to work around the problem with "classic detection" algorithms, which I believe will show significant detection latency and will therefore be unable to switch modes as seamlessly as SCE has already demonstrated.

With SCE we have approached the problem from a different direction from the start: Safety First.  The spare ECN codepoint is used as an additional output from the network, and CE retains its existing meaning and usage.  This means SCE can be deployed across any existing network with congestion safety, competing normally with conventional traffic - because on a conventional network an SCE flow is almost indistinguishable from a conventional flow.  The performance benefits begin to appear, seamlessly, when the bottleneck on the path is SCE enabled.

And this means that if a Diffserv codepoint is used to request low-latency service for an SCE flow, it can be given by simply adjusting AQM parameters for that traffic, *without* impairing safety should this classifier be lost en route, and with completely equivalent performance.  I think this is a very important point that the L4S team has overlooked, in their continual attempts to discredit the SCE project.

We are working on a demonstration of this capability, which we may be able to show at Vancouver (remotely), perhaps via the Hackathon.  Of course the fully-integrated code will also be publicly available at the time of demonstration, so you can replicate and play with the results.

 - Jonathan Morton