Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)

Pete Heist <> Sat, 27 March 2021 13:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79FEC3A2A3B for <>; Sat, 27 Mar 2021 06:33:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 HNHYHhuRZqCK for <>; Sat, 27 Mar 2021 06:33:10 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC8563A2A37 for <>; Sat, 27 Mar 2021 06:33:09 -0700 (PDT)
Received: by with SMTP id x16so8293005wrn.4 for <>; Sat, 27 Mar 2021 06:33:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version; bh=9QYpWuM/3/VnPKFJ/nygNfZ2PSa7urztWET/CMNm56M=; b=NIGUWFioRbrjXoGHdJPOOIqpC3YCFJgQERvmkaAZPBq6+9Zr0oGMaDgQj4eYSmFvxe zoK1l5JdOC+mHcSYOTqz8v/m3ZfoMLusWopYAGbXGyTtwAsNpglL/kNmtllhKdwiTDe/ 1+ZUcyaJNIK2gYnrTb2fDi+gmtWz3gbth+pKIqMx0MZenS8J4YJfXKgbL2BHq29xdEZA 4T2vPkekHzax79kup6WsMcjh2ee2RE/BCEyVMjAqy6UDkHpc41bX++iAoSl8j+quhRJc 2VJysFJ8E337jq27/QQo4M4snOkcTDvpDKkQJQE9AsBTQPTdsKB+clXuS11/r71V2bYk /k4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version; bh=9QYpWuM/3/VnPKFJ/nygNfZ2PSa7urztWET/CMNm56M=; b=q4tP+fXlEm5L/fSW3KjPPGed8T9kZhbT5nqkzrkFcLRc1rVepjvmLyo3SaPhaATfgr ic8zBADTSwxO/KsW1SP4BaCbiBu/br1LE1nOylPg9NtCqE3Roo9oTGTnFkamOsN7tqQ7 pwClfvTomIwACvAj8h9aOs9sOIsJcwRkgBGsCasgyvqEfSLm61l4rIQ/X+52Pwztpmmw ATMF+OmJRDUMmxeviVkEFH9PtrRazkfrnhSlpoPEyXGrOGp8Dr1dFm9Kr8nZatagGe0J nWLvXYNAo9v7Gtz0jW4K/TnEEyGpkqQ0DSY9yOZUWWxNpHDkxEQKhG6bxVpHJqvFEb+8 YgTQ==
X-Gm-Message-State: AOAM533J/1uFbn2FJ3+nSDiDRzGntuTQiPBRHrZ/+H2x8Cf92lywu2I4 cv2dp7uD3I7h8gquXBHYIUq7cQxO7O3RKw==
X-Google-Smtp-Source: ABdhPJypS7eqDu58YM3q45YrsTZQyEw2blPtwA+a5NAcFk5dsBxEOx0Z36UcPFVqpqhWDnl9f0m4zg==
X-Received: by 2002:adf:f303:: with SMTP id i3mr19274947wro.67.1616851982745; Sat, 27 Mar 2021 06:33:02 -0700 (PDT)
Received: from ( []) by with ESMTPSA id l6sm18953623wrn.3.2021. for <> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Mar 2021 06:33:02 -0700 (PDT)
Message-ID: <>
From: Pete Heist <>
To: tsvwg IETF list <>
Date: Sat, 27 Mar 2021 14:33:01 +0100
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Content-Type: multipart/alternative; boundary="=-2r1HijOxx4esAtzXcjNL"
User-Agent: Evolution 3.38.4
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)
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, 27 Mar 2021 13:33:15 -0000


On Fri, 2021-03-26 at 08:54 -0400, Kyle Rose wrote:
> On Fri, Mar 26, 2021, 8:30 AM De Schepper, Koen (Nokia - BE/Antwerp)
> <> wrote:
> > I understood the goal of your proposal. But before diving into the
> > details of a DiffServ-based proposals, I'm taking a step back
> > asking: Is using DiffServ an option at all.
> Why wouldn't it be? The point of the proposal AIUI is to require
> networks to take action to explicitly opt-in to this experiment.
> Given the DiffServ bleaching that occurs by default at network
> boundaries, operators that take no action will not find themselves
> ambushed by novel behavior.

I agree- the topic of this thread is the use of a guard DSCP for
experiment. Sorry if I contributed to mixing in other possible uses
early on.

> This approach allows for experimenting with ECT(1) as a classifier in
> a safe (contained, time-limited) way, thus allowing a path toward
> universal deployment (i.e., removing the DSCP guard) if the
> experiment is successful without requiring standardization and
> rollout of end-to-end DiffServ. And it does so (a) without
> permanently burning the ECT(1) code point if the experiment fails,
> and (b) in an opt-in manner that greatly reduces the potential for
> unintended side effects on classic traffic.
> This seems to me like the obvious path toward consensus on an
> experimental deployment aimed at gathering real-world experience
> without first committing to something unproven.

Although an RFC isn't technically required to do this, it should still
serve to codify how DSCP should be used and treated, and also to raise
visibility as a sanctioned IETF experiment. After a successful
experiment at "operator scope" (if that terminology captures it, but
the larger the better), it should be easier to justify and start an
experiment at Internet scope.

I also think that with codepoint space this tight, it's not just about
verifying safety, but also effectiveness. I feel the same way even for
proposals that fall under RFC4774 Option 3 ("Friendly Coexistence with
Competing Traffic").


> Kyle