Re: [tsvwg] Reasons for WGLC/RFC asap

Jonathan Morton <> Thu, 19 November 2020 16:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2EFB73A0A4E for <>; Thu, 19 Nov 2020 08:46:21 -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 LyVstJFkbuDr for <>; Thu, 19 Nov 2020 08:46:19 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 93BD23A0A50 for <>; Thu, 19 Nov 2020 08:46:19 -0800 (PST)
Received: by with SMTP id u18so9188855lfd.9 for <>; Thu, 19 Nov 2020 08:46:19 -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=Akn7ZtCRKulOXZXt45rUzQ5Yt8FW6hiYJEsR665jq5s=; b=ml+rVQ3Hb37MzRYrM6bNHuvRs3PN5czw9X7PZiHYkU3vIuhKW7k+3A1xAHCTMmhjOz OQ3GeYUXWvQz7ck39PyhWetFWnb0YcnWkSVMYkZ6guNo0RLiJZmjbZ0ViM0S+wgu8Jwg JhoyLV5F2+wkziqxaJxW7sDXdUhoj1TiUE2pDenufVwALwE3hrSxTqXD7+9JbBVRpai4 YmGVpTU/W3hF8iNQFyNyUZ5NOwRHDmVwW7VO2AWbvinkTeS1O9jbZwmtncqa9r5aO4qe iihZtsuAeGaFWd7aHhOErIQgPUJ+WEZd5Q5Re/RfsB/SOp8rLW/4KdnNNQLYXdbtXlxh VpyQ==
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=Akn7ZtCRKulOXZXt45rUzQ5Yt8FW6hiYJEsR665jq5s=; b=JJ/i03k3CkO88k2SPWEo+hCHNjGhKosoC2AI0XeiRdiEDjjaueye0oeBpjZLGvX6VP JRXE+cU6FGhb+U00RGuzQdjbsOldzAFhn3FY7vllP/isFEBXZag0Roc6e7BLNGWIFxbt wc0Qc7T7tO+1fgaDbf1PG/fKPRo+1Fh61RGt3VeU9q3qIQ+NiZD+njQ8nD7v3q2DquGa Ts4hva3quzawUIczmi2Zu6z/YsbsW6zeCvoDL+ZvgzymVUiQQz1UXoaTboMtk3s7nL+C fx4UoAUIrMk0O+rdBYhmq+XxvvybLCG/ndbStJ8QGc/eam3tjYYo7oL8bfdbNwCVK2mT 4egQ==
X-Gm-Message-State: AOAM5316s5n106r3vWxwOu2h+cT82gkOU8Rs4ocibFx11hMMUKg5c3Ag VqHTgHFwtA+TdMYmKin2hKs=
X-Google-Smtp-Source: ABdhPJzEjdbaMU+MbDe5rtxVfYTN5DaA9lO0Egvl0wUukKqFyhxln75qpAR2oDJ1NsQDoMS6YnIA8g==
X-Received: by 2002:ac2:53ad:: with SMTP id j13mr5805423lfh.177.1605804377757; Thu, 19 Nov 2020 08:46:17 -0800 (PST)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id e14sm16006lfd.145.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Nov 2020 08:46:17 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Thu, 19 Nov 2020 18:46:15 +0200
Cc: Pete Heist <>, "De Schepper, Koen (Nokia - BE/Antwerp)" <>, tsvwg IETF list <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Gorry Fairhurst <>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <>
Subject: Re: [tsvwg] Reasons for WGLC/RFC asap
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, 19 Nov 2020 16:46:21 -0000

> On 19 Nov, 2020, at 6:34 pm, Gorry Fairhurst <> wrote:
> It would help me if you clarify what you mean by  "unsafe" - to me "safety" relates to traffic unresponsive to drop, as in CBR traffic, etc. I've not understood how CE-marked traffic can erode safety, but maybe I missed something?

There is the potential for traffic between existing, RFC-compliant endpoints over an existing, RFC-compliant network to suffer a Denial of Service due to the presence of L4S traffic on that same network.  In some runs, we see CUBIC and Reno forced down to the minimum cwnd of 2 segments, and would be forced down further if that were possible.  That is the safety concern.

There is separate concern that the reference implementation of L4S doesn't meet its own specifications.  That's less of a safety concern, but we think L4S proponents should be more concerned about it than appears to be the case.  These results can (and should) be confirmed in the lab before attempting any kind of deployment.

> I'm not sure why "tunnels have crept in here. There have always been side-effects with classification (and hence scheduling), but I don't see new issues relating to "tunnels" with ECN.

An L4S middlebox can cope with tunnels containing a mixture of conventional and L4S traffic.  An RFC-compliant middlebox cannot, even if it implements FQ, which is otherwise held up as being "sufficient" to isolate L4S traffic from conventional traffic.  It is the fact that tunnels can defeat FQ that is causing renewed concern here.

The l4s-ops draft appears to say some things about this which should be a relevant point of discussion.  However, L4S proponents appear to be keen to proceed with L4S WGLC without waiting for l4s-ops.  That is a problem.

 - Jonathan Morton