Re: [tsvwg] path forward on L4S issue #16

Wesley Eddy <> Mon, 22 June 2020 15:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12A9B3A0DFC for <>; Mon, 22 Jun 2020 08:49:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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 uwSrJm3qWxjW for <>; Mon, 22 Jun 2020 08:49:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 79D353A0E07 for <>; Mon, 22 Jun 2020 08:49:19 -0700 (PDT)
Received: by with SMTP id u8so1084387qvj.12 for <>; Mon, 22 Jun 2020 08:49:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=GZykV1A1toqo4O7Y8EaXl50OlKq+EM2c3ujVBFnf/8g=; b=ePQyJUFtkbvGtiIbO46O7Cszfq0EwlczmB7cU8AzCxGfr8SmIKLUaRWkrhDCzPDl45 AIoLV1axYMvns2vfODpxPu9lx5DPn+gh7Qi8CHjQh3nSA0cQcM9lRNWYtRzYQ2h6rmmX S4FTK96xLjOICGEEStXIeD/JGtzXx+2zQPamAd20A5hxum5Uiof3t41eFadSmc3yBgQi QnwN1N84lSH7xzcVcD87KuUMGUe7iJTeWQLgP5zL1tBwN2paoMxkvR4fcBu9d0u9PrtC YGpHBnN24NaeCTmpEdglT4iGQE4HRMROe0y9giQn6vOCS5DM4Cr9Qt6/ayxbt7MPMeJ3 cAfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=GZykV1A1toqo4O7Y8EaXl50OlKq+EM2c3ujVBFnf/8g=; b=DqZHF9xjMTXTf8vZzO4/Rp9mUdKClAJFdnSNkXzsSQq5BUWQ8KQcG/kcI0WcIIoxPC j/cv20m+Yw7rN0aRjEZ0LDeqvMwPBPX8hLqHVzehMVDQlUiyIbO0MsPhTLtfGq1sFUGJ FjwfMVDxSR8vFZ4Vd96af/UHp/d1FHBQn8XXScDvRn1r2smnlQE6qLJ/pn0kCsgdDtFH MApVjG3BweYnsfiKyckTnllj0R32VJBIMzuhV67oGivPsHUZ3wHyN8fzvrdT+mJUgp7c ED1g5rYyDaRmqksl2gFekwNMLqM2dxoRqM9rYj340ucB8qadN31oF6jzq6jzYjn8WxQn AMCQ==
X-Gm-Message-State: AOAM531NeuOasfm+KXUu2iuGMU2WKtqu+nq1cxw8yZEwfx8/nd/RARd9 wHWFdLoKGVpf28roasSi+SREkpTJtEemZg==
X-Google-Smtp-Source: ABdhPJx2JqK962Yd6HqvNN2XLDbDK91bEcshWgxjiozJnHT1kStDlsddAsRAaAbf6Fk10XxiUlNYJQ==
X-Received: by 2002:a0c:ef47:: with SMTP id t7mr22501944qvs.1.1592840957979; Mon, 22 Jun 2020 08:49:17 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id x26sm9254341qtp.54.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Jun 2020 08:49:17 -0700 (PDT)
To: "Rodney W. Grimes" <>, "Holland, Jake" <>
Cc: "" <>
References: <>
From: Wesley Eddy <>
Message-ID: <>
Date: Mon, 22 Jun 2020 11:49:11 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [tsvwg] path forward on L4S issue #16
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: Mon, 22 Jun 2020 15:49:21 -0000

Hi Rod, I just have a short comment from what I have seen as the WG 

I have not noticed much interest in DSCP global traversal, especially 
from the parties that would need to support it.  Since that is also 
explicitly against the DiffServ architecture that incorporates 
re-marking, suggesting it is a rather big change to all of how DiffServ 
has been defined, unless I misunderstand.  I believe any activity or 
proposals on global DSCP traversal are very interesting and totally fine 
to discuss, but can't be a gate for L4S.

On 6/19/2020 11:14 PM, Rodney W. Grimes wrote:
> Jake,
> 	Thank you for spending the time to collect this
> detailed summary.
> 	I believe you left out: (adding one to your last one and listing)
>   7.  Use a DSCP to seperate the experiment, leaving ECT(1) and CE as
>       currently specified in the L4S draft.
>   8.  Use a DSCP to classify the traffic as L4S and leave ECT(1) unused,
>       altering CE semantics.
>   9.  Use a DSCP to classify the traffic, and use ECT(1) as a 1/p signal,
>       leaving CE semantics in place.
> 10.  Dropping L4S as over promising and short delivering with complexity
>       that almost certainly sets it up for a failed deployment.
> Note that in all 4 of these solutions bleaching is unlikely to be
> used if there are problems, and the experiment is rather trivial to
> terminate if there are problems.  These also keep ECT(1) avaliable
> for a future non-experiment version of L4S should the experiment work,
> or something else should it fail.  7 to 9 can even be started today
> without an IETF consenses and some real operational data created.
> On the side, IMHO, the work going into L4S would be better spent addressing:
> a)  DSCP global traversal
> b)  ack thinning being underspecified such that it creates protocol
>      problems.  Specifically the fact it tosses out changes in reserved
>      bits by thinning packets with different bit values.  This was
>      identified years ago and left as a problem, it needs cleaned up.
> c)  Revision to RFC6040 and other tunnel related drafts to clear
>      the issues there.  Again, identified years ago and left to clean
>      up.