Re: [tsvwg] Another tunnel/VPN scenario (was RE: Reasons for WGLC/RFC asap)

Jonathan Morton <> Thu, 03 December 2020 23:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C9173A0E6E; Thu, 3 Dec 2020 15:00:28 -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 hs_bDCxv_JPU; Thu, 3 Dec 2020 15:00:26 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 66A333A0E71; Thu, 3 Dec 2020 15:00:26 -0800 (PST)
Received: by with SMTP id t6so5113229lfl.13; Thu, 03 Dec 2020 15:00:26 -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=Bt+ZrwYf28EhQX9oI1BXNKG5khcuf2XDQq1T/LMpVDc=; b=MF7DvIvAEEXqpFytLabxCbSlwA5dMR3/Ix++0JwWEBJyjzeHIewSVqjVG+Jy62yKbL rV5dhOR8DnetT7qK+q0YCw1sSP21hnCfULPDlWbD8bD5Tfh/zQzT9SwaNVo9jFnykEkA MVPGs0f6ESASAaD11DgvQPVnt0lzwkxNXJCkda1ATjbgbg+F/a+J8xVVVhYXdtK/Elr/ UkXlvOfGCFcxAYmLMopIbhceLKKzyetupLNtM9OTM2xQ9pOqHVyyDH3PZl2ZhXL3R69t b0Dmt1jru55DgqFvMp0d00d5QINDaRMeg7t7lflXDckKxrQpT71vbCRNNr78+o6G5yN4 C3cQ==
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=Bt+ZrwYf28EhQX9oI1BXNKG5khcuf2XDQq1T/LMpVDc=; b=ct4Hdl0kHNTmThDapSFdeuYP/DC2uPGnhvirRWV1l/ZruZ/+pF6KaXpqdzWqAEGUzX rPJtUc7JRrstpn3iwCnghvLopaugNvpAWeJWpmNczCtbQ0uhR110L6TrxUWF+rtnYWHm oO/L6F9Na2PiR3NRFFxRmHgzieuYYczV+9axdt0XDCFjz1IDtWT0cwzFNBTMNzHuPXWL rYe9XxSf+3VrY2FrN1hT2zAMrU4gQDdJkow31MkSUPd7HOeq8dCfcce3Py/RF3+VTuMV l5IHh8IKLp9VoHL6KITysW7JnhF5tIE9Dt9p+YVyN6hH8KkBTOT5VSDuuqDO+nJ4ekiV WJOA==
X-Gm-Message-State: AOAM532Sy0WkG5MIgeWZfcnYPJWQPcmJvA+erjGjqPv+tarjsrOXcB9k DeTepmakNOhXxmBq/U/DIFI=
X-Google-Smtp-Source: ABdhPJyQy9OSh4A5AVDF5uos9npy758ErMOXyECiRRG9+qsPM1hbvObLAFYTXFhEQgpK82FUL0ii3w==
X-Received: by 2002:a19:43:: with SMTP id 64mr2231784lfa.504.1607036424441; Thu, 03 Dec 2020 15:00:24 -0800 (PST)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id i4sm986459lfl.131.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 15:00:23 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Fri, 04 Dec 2020 01:00:21 +0200
Cc: Bob Briscoe <>,, Ingemar Johansson S <>, tsvwg IETF list <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Sebastian Moeller <>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <>
Subject: Re: [tsvwg] Another tunnel/VPN scenario (was RE: 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, 03 Dec 2020 23:00:29 -0000

On 3 Dec, 2020, at 11:36 pm, Sebastian Moeller <> wrote:

> …team L4S (not team FQ whoever that is) keeps claiming that FQ will make L4S' re-definition of the CE response "safe".; but in the light of tunneling that claim simply is not true. Also not really a reason to go off on an unprovoked rant about FQ and layer violations.

Just to put this completely to bed:

- If you remove FQ from the equation, and just have single-queue RFC-3168 AQMs, then L4S' problems get worse, not better.  Every instance, rather than only a limited subset of instances, of L4S sharing an AQM bottleneck with conventional traffic would be doing so in a shared queue, and we know perfectly well where that story ends (see Issue #16).  Therefore, FQ is not the cause of the problem, but a partial workaround; it works well when applicable, but there are scenarios where it does not apply, whence the behaviour is merely as if FQ were not present.

- If you remove AQMs from the equation entirely, then the coexistence problem goes away, but also L4S shows no benefits over the status quo, because it relies on an AQM to inform it of the bottleneck queue status.  Both L4S and conventional traffic would experience a lot of queue delay.

- If you remove L4S from the equation, then the problems associated with it go away completely.  Conventional traffic coexists with other conventional traffic just fine, whether in a shared queue or with FQ.  Therefore, L4S is the cause of the problem, because it is the single element that you can remove (while changing nothing else) to solve the problem.

In causal analysis, this is a no-brainer.  L4S, not FQ, is the problem.

With that high-level insight, it is then straightforward to drill deeper into the system and find the design element within L4S that is the *root* cause of the coexistence problems.  Everything leads back to the design decision to change the meaning of CE, slavishly following the (bad) example of DCTCP.  All subsequent design of L4S has been driven by the need to mitigate the consequences of that basic choice, and ultimately it has not worked - fundamentally because existing networks (as opposed to those specially prepared for L4S) see only the behaviour inherited from DCTCP.

In SCE, we made a different choice.  We chose from the outset to keep CE with its existing meaning, and even to use the existing ECE/CWR feedback mechanism for it.  For the high-fidelity signal we followed the suggestion in RFC-3168 of using the spare ECN codepoint, which seemed very natural, and we then had to decide on a feedback mechanism for it.  All of our subsequent work on SCE has been driven from the natural consequences of these early decisions, and some WG feedback on what behaviours are more or less desirable.  But it has resulted in a scheme that is inherently compatible with existing networks and existing traffic, unlike L4S.

Wes wrote:

> I wish this thread was making progress in any way, but I don't see it, and it's become a bit heated again.

I, and probably Sebastian too, feel some need to robustly counter disinformation when we see it.  That is unfortunately something we have to do rather a lot when L4S comes up.  Today's discussion about FQ is emblematic.

I agree with Wes in wishing that more people would get involved in this topic.  They should look at the test data that Pete, Jake and I have organised, maybe try to replicate our findings, and come to an informed opinion as to whether L4S (as a current WG item) remains worthwhile and/or can be salvaged somehow, or not.  They could also try some mathematical analysis to see what the theoretically predicted behaviour would be, and whether our tests reproduce that accurately.  Third-party validation (or repudiation) would be welcomed.

In connection with that, I would point to the lack of progress in addressing Issue #16 by technical means, in more than a year since it was first raised.  The heuristic bottleneck type detector was a valiant effort, but was not successful.  No better alternative has been put forward - except for changing the signalling mechanism, at least two versions of which the L4S team has flatly rejected.  I think we must consider the signalling mechanism to be a defining feature of L4S at this point, such that they share fates.

May I ask the Chairs whether a WGLC would be capable of de-adopting L4S from the WG agenda?  If so, then I might just remove my objection to having another WGLC for L4S.  At present, it seems like one of the most promising avenues for making concrete progress towards a worthwhile experiment in high-fidelity congestion control.

 - Jonathan Morton