Re: [tsvwg] Options for improving L4S safety

Jonathan Morton <> Tue, 09 June 2020 01:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E06473A08D1 for <>; Mon, 8 Jun 2020 18:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 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, 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 55V4PJfm5lqi for <>; Mon, 8 Jun 2020 18:23:37 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E40D43A08CC for <>; Mon, 8 Jun 2020 18:23:36 -0700 (PDT)
Received: by with SMTP id x22so11464142lfd.4 for <>; Mon, 08 Jun 2020 18:23:36 -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=K+BpXm93X3TxeuYIJP1c0fA/RNIfIJXLPEWuxLibqXo=; b=OU9UE8rNfTourtJO3O2SGBBaT/fuPLeNRNO7xD0VVFrIjdF30QkrZUzGmJRUo6l8Mw 0OlWnz+feG16gcXNU2gJGjfCD5cSMxKc1LgqI/QuVy+yNhI60/kkd+8b8roNMaBYpr6o s/65O8BJjq7fJP9WaaG6P/z1q45s+h3i7aevI2fd10sC80pxDGNzbEo6TcEk2kAp2ipW Ojrpz1hb26wvevkZfHEnIzslgNI1tsJqpkhQMA0m1EBju5b/BymVSptScwuIYBUtYwH/ IhB4ZswOPZuGSX3fjfBO1fRhlbXMgbTfzXfk6pmivJ/iy4XL9ssKZqdXIqEZh2nX9NFr 1s+A==
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=K+BpXm93X3TxeuYIJP1c0fA/RNIfIJXLPEWuxLibqXo=; b=rqNBQTstenWJ2sh1hXTj8t/9YxjoMbRarD1cCMqzeKTaksEjofnBl4HavzXtXerSgo Mh3+OFscbnkVVOHv253a9nuIfsG448MDzWVKV+MX/oiuKayrUpsO77ZAahzrG1OFWsev 4P2gp2t9EAGfQ0AzQmeuhhko3qne71AMtSJS5v0jHLh+t5ZzIeINoIRURUMeT4FNSMKB 6gTPLsAKVRMvkh+raFWpk5d8JRHgUDqLgoqtb1IHmz5D0f51SpXxuYxnkTh8++L7FATD 6It5YZNCEl6bj2XmB4d/Z1T8yqGlSLm23WjTC9gMxtYE58cBGEqwzAASkpKJOs59abNA Qdig==
X-Gm-Message-State: AOAM532zbfA131gvH0pu8aBo9ozuyPYkoNE/qlo75vOo6N6PTK8ArbH1 dwNnoIORwDAuoHaG1+lv9gSCW7ct
X-Google-Smtp-Source: ABdhPJyHtVbziYq+6kHmMEScGxMKKiggrKIrAmY26IIL0FYRALazgNDBh9Ud9zN4O34vm3U6epQwdQ==
X-Received: by 2002:ac2:511d:: with SMTP id q29mr14072595lfb.24.1591665813272; Mon, 08 Jun 2020 18:23:33 -0700 (PDT)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id y17sm4733445lfa.77.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 18:23:32 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Tue, 9 Jun 2020 04:23:31 +0300
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: "" <>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <>
Subject: Re: [tsvwg] Options for improving L4S safety
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: Tue, 09 Jun 2020 01:23:41 -0000

> On 9 Jun, 2020, at 2:47 am, wrote:
> 1) As frequently mentioned, if L4S marks were distinguishable from RFC3168 marks, L4S endpoints would be able to react more appropriately. 
> Since the group is now persuing ECT(1) as network input, this approach is currently without an codepoint, although there has been some speculation that DSCP could be used as an output. This is sufficient for safety, but perhaps it is not necessary. However the 'safe by construction' 
> attributes are obviously attractive. 

Obviously, SCE does things this way, but without an input classifier.  This makes sense, since it started with observation of this very problem in DCTCP and L4S, and sought to avoid it "by construction" as you put it.

Jake Holland made an alternative proposal which does use ECT(1) as an input, and makes ECT(0) the output from a HFCC AQM.  This retains the RFC-3168 meaning of a CE mark, and thereby unambiguously distinguishes the outputs of L4S and RFC-3168 AQMs.  I believe this has the potential to work well, and might be the single most promising solution to the problems that L4S has, under the constraint that ECT(1) is used as an input to the network.

The only substantive argument that I have noticed against this is that it might interact with tunnels poorly, due mostly to underspecification of how mismatches between ECT(0) and ECT(1) in different ECN fields belonging to the same packet should be resolved upon reassembly and/or decapsulation.

I think we need to understand the tunnel situation much more clearly, with reliable and up-to-date information about their prevalence and detailed behaviour, in order to properly judge whether the effects on Jake's proposal (or indeed on SCE) are helpful, benign, undesirable, or catastrophic.  I'm aware that both RFC-3168 and RFC-6040 have things to say about this area, and that they do not necessarily agree with each other or with actual field practice.  In principle it is possible to update these specs, but initially it is already-deployed systems that will be important here.

Intuitively, I would classify the effects of CE being an ambiguous signal as "catastrophic", while the effects of a tunnel muddling up an ECT(0/1) signal are likely to be "benign".  By the latter I mean that a HFCC signal applied to the outer header of a tunnel may be amplified or erased upon decapsulation, but that a CE mark or an unmarked packet will be decapsulated correctly.

 - Jonathan Morton