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

Jonathan Morton <> Thu, 12 March 2020 13:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64F5C3A0827 for <>; Thu, 12 Mar 2020 06:07:34 -0700 (PDT)
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 ZW6wq389NYs1 for <>; Thu, 12 Mar 2020 06:07:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F390B3A0837 for <>; Thu, 12 Mar 2020 06:07:31 -0700 (PDT)
Received: by with SMTP id b186so4670611lfg.11 for <>; Thu, 12 Mar 2020 06:07:31 -0700 (PDT)
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=uj9BGHfwaeVtRPm+F7hxjzHNAboLofWOj3qT8tvRA5U=; b=dkdJNXbpC6b11cWDTWA1Hc/99DV9wnGbK+ZSV/d3Phmx6G1OWPVYGyizRPZDQe1745 MWg85Df6VxQLrPgjoEpeOw6seWpsbSwbzt8ZKbfQJZjjmIbleFeb9T+LZp7Ypb15IPLq R/wlbFRvzp6MadyDVYNrVy8qmd5vt0RaMXdAaoIp7oIBgfhHMuoWl0R10WpKtbmZl05A L0QQ/yytx+Ju/Nyix6BcMSnRfnvLzDuQ0E+zWZP/Q9C5JiuSDLrZb7Reugg3TnrZzkVG Fjb0SNm02i9WYzlJH0eH3p8AV5Wm+UIwQYKsROy6mXU1/URz/mr7HvwlItKaloA1380P ETRg==
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=uj9BGHfwaeVtRPm+F7hxjzHNAboLofWOj3qT8tvRA5U=; b=Nf4snQiJIk8gi0GbP9jNyX9uu636soVqNrGRx2mbRlm9M7+2K/5UYY/jpfTHfy/5rf WMGdneSIVMpwZmJ27Y8fojcU/pz2oNkG3MTlL/qc6N9naZGOO0XjeSImCcVWmLLbUHG/ vTETVQyyJXzDs+UGFJGXz0GYYoyE+5XUmF2qtpEja40PfQX6io2slXjPffmktplaiHDT 4XXsSFQWzr+v4WTfHUG+3TR8TnkYKGg56jZ1haKdU8mKtpi0sYdbaIDhMZXiAdQ0dYz0 jJddonf4YP4HU7fXVO8UibuU2xFhShMVWmKgPTINGdM3+lkkf0ZPbpGt5BZfXDKEUpQj ikzQ==
X-Gm-Message-State: ANhLgQ1iaCZ5BkpEBkpXPmU43L5AMQrBIUFxuwHpvuh96ceaHqjihmeb e5RZAbYi6VjPDAfufR/7+6fpT8Xf
X-Google-Smtp-Source: ADFU+vsAvhOeanA+Bv2+s3yrnsx1QNT85PV+40FmQ1ND4lXL4PmqMJn48lW3MkgufRYeHWjy1JQ4Aw==
X-Received: by 2002:ac2:5605:: with SMTP id v5mr5457494lfd.184.1584018450097; Thu, 12 Mar 2020 06:07:30 -0700 (PDT)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id v17sm17143647lfn.64.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Mar 2020 06:07:29 -0700 (PDT)
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: Thu, 12 Mar 2020 15:07:14 +0200
Cc: Lars Eggert <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Gorry Fairhurst <>
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: Thu, 12 Mar 2020 13:07:42 -0000

> On 12 Mar, 2020, at 2:19 pm, Gorry Fairhurst <> wrote:
>>> Is it simple?

>> Yes.  I could summarise the technicalities on two slides - or one, if I really had to.  Implementing SCE also does not require very intrusive or extensive changes to existing network stacks; a year ago, we got a basic proof of concept running in about a man-week.

> Yes, we should capture those two slides for SCE! We will also ask the same for L4S.

> One slide on how SCE offers benefit will also be useful. Again we should obtain the same for L4S.

We'll bear that in mind when preparing.

> ... Or rewrite ECT(1),  as I understand for some existing tunnels/encaps. I recall from the early L4S discussion that this consideration was also be important, and hence we charted work to try and improve ECN-marking in the IP layers.

I think we will need to have a focused discussion about tunnels at some point.  For the moment, I'll just note that if the SCE signal is erased (on either the forward or feedback path), then the flow will revert to conventional RFC-3168 behaviour, which is conservatively safe.

>> SCE enabled middleboxes are easy to detect, by passing ECT(0) traffic through it and seeing if ECT(1) marks appear alongside (or before) CE marks. If CE marks or an AQM-like (or tail-drop-like) pattern of drops appears but ECT(1) does not, it's not an SCE enabled middlebox.  This is probably sufficient to reclaim the spare ECN codepoint.

> Probably worth writing down. I've found it hard to test for ECN-marking on operational paths, but insight in this is always going to be welcome.

Granted, there is the corner case where the middlebox in question is not a bottleneck on the path under test - so SCE or ECN functionality may be present but not visible.  That would appear to be the chief difficulty with achieving full probe coverage.  But I think enough confidence could be obtained by such tests to permit reclaiming the codepoint for another experiment in a reasonable timeframe.  We can try paying more rigorous attention to this question if the WG deems it necessary.

> This was to be an important topic of the face-to-face meeting in Vancouver, where we have been planning to allow time for different viewpoints to be aired and the consensus of the group to be sought. We still plan to do that, and are considering how best to proceed.
> Comments in-line to show the expected direction of travel, but please do avoid growing this discussion thread for a week or so, until we have a plan to conclude it (see end of email).

> The TSVWG Chairs are now aware that we need to plan to make progress and will be in touch in the next week or so, with a plan move forward in the absence of an IETF face-to-face meeting.


 - Jonathan Morton