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

Jonathan Morton <> Thu, 03 December 2020 15:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 833913A0EE4 for <>; Thu, 3 Dec 2020 07:52:50 -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 LYKpidFnlp4z for <>; Thu, 3 Dec 2020 07:52:49 -0800 (PST)
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 A29D83A0FB1 for <>; Thu, 3 Dec 2020 07:52:48 -0800 (PST)
Received: by with SMTP id t6so3380070lfl.13 for <>; Thu, 03 Dec 2020 07:52:48 -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=2MkAGUdxEJ1m8XObaW8Q17YgmQ1mgUBmEmrTKRZX9BM=; b=nOZGOHMzWXzD7fX3I0sB8Ls7O/BIDYVWuMTUqk80tJgjFUOOTpwq0JgwRJ6YTsPCE/ afvHeFprZ0VpybaluBGlWiZwd9ddfPcI9hN5ooZTCzUQgL7bzlvmgaPfhLtGIhK1j7JE C6CWMBX4Q9Kda3egXmO0VCpLZGXFeMlbbLXzHI0oHwWsPo/dPL+iVlWkT+4fDQIeJv2A iqik/IjvgwkexD8ppV96jCuv34/IjsJZOIMIhO8UfkI86Yq4p0tea9swhlOOL0LGAIYx s2yjac0zZCTXHsJWtoQFvuuCDMDmc6CBHDUsddCNhzvNc8/jXLyt0KLzKAnQTrLhIYed 0Hyw==
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=2MkAGUdxEJ1m8XObaW8Q17YgmQ1mgUBmEmrTKRZX9BM=; b=bRGxJMLwgJzqVnl8raQKOvsr1a2eE1EqaqyzUN0Po4gpxLQZG2mXDYtU2iN59HftD6 DY9gbuSwQQTXwGMvNZeeT5r6fNdLQo/NJArzW7gILdaxinEcjMBqg+yjE9Xz6mlh5fzx CMJfmFmuTVWfOe7FQTprUKhfKdOrtl1WaPp6EVVLuu4YJGJVMesESlxiZCKEuIKAxuqF /gvWSnBGmh0sIh4ypltcLP6YIy7qqyxiRof/rxCdfouyTH88sm/06IvVPaUkc//vROnh qft6SoV1fmqLUbQ1PSWMTkPzBMUzoTDoaXl1Q6TkCg+6CcpbkKpIuDBt2NDIMqfk5ck7 2JgQ==
X-Gm-Message-State: AOAM533GKRGk/ui1O0gVOLA2CCLhX+cnf9QETicpzICcOaniUQTdUDPi DSZe+HTxDBy/s8AFnPQzs5g=
X-Google-Smtp-Source: ABdhPJyH2viJOFLZ9Zol3/I3hvh+FQUq67yIw7Y9AWF7erWeVx/v6b6NT47Cme3VwDCY+yEuZ2U6cg==
X-Received: by 2002:a19:711:: with SMTP id 17mr1585694lfh.131.1607010766626; Thu, 03 Dec 2020 07:52:46 -0800 (PST)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id v2sm640711lfn.163.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 07:52:45 -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, 03 Dec 2020 17:52:43 +0200
Cc: Sebastian Moeller <>, Ingemar Johansson S <>, "Black, David" <>, Pete Heist <>, tsvwg IETF list <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Bob Briscoe <>
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 15:52:58 -0000

> On 3 Dec, 2020, at 2:19 pm, Bob Briscoe <> wrote:
> Encrypted tunnels not revealing the component flows in the payload is a correct property of layering, which has been a principle that guides protocol design since long before the Internet protocols adopted it. I would ask you to imagine standing up (virtually) in an IETF plenary (or any networking forum) and blame layering (and/or layered encryption) for FQ not being able to isolate component flows. You would be flamed to a crisp.

I did not make any such argument about layering, so I will treat this as the strawman it is, by ignoring it.

> The root cause of the problem can be objectively determined. FQ doesn't correctly schedule flows within encrypted tunnels, whether L4S is present or not. Therefore L4S cannot be the root cause of this problem.

This is where you are incorrect.  If FQ cannot distinguish between the flows encapsulated within a tunnel, its behaviour merely reverts to that of a single queue, by design.  This also means that FQ-AQMs effectively revert to single-queue AQMs in that case.  Existing traffic is perfectly happy with that arrangement, and it is generally an improvement over single queues *without* AQM, which is presently the status quo over much of the Internet.

RFC-3168 and RFC-8511 lay out certain congestion control behaviours which permit ECN and loss signalling of congestion to coexist, and that arrangement works quite well at present.  Transports obeying these requirements (and those of TCP friendliness without ECN) coexist without starving each other out of the network.  Even though they do not always share the link with perfect fairness (or even RTT-fairness), it is within some reasonable factor.

Specifically, RFC-3168 expects AQMs to signal by loss on Not-ECT packets at the same rate as they signal by CE marks on ECT packets, to treat ECT(0) and ECT(1) as equivalent, and for congestion control to respond in the same way to CE marks as to packet loss.  RFC-8511 relaxes RFC-3168 slightly, and specifies a minimum response to single CE marks (per RTT) of a 15% reduction of cwnd (for window based transports) or send rate (for rate based transports), ie. a Multiplicative Decrease event.

The introduction of L4S traffic upsets this situation, by violating the above-mentioned provisions of these two RFCs.  L4S transports cause substantially more harm to other transports, when they happen to share an AQM queue, than existing transports do.  Redefining the semantics of the CE mark is the single element that, if removed, makes all the coexistence problems on existing networks go away.

Frankly, the sooner the WG understands and accepts that basic fact, the sooner we can move to a viable solution - one which does not redefine CE from the semantics established by RFC-3168 and RFC-8511, and hence does not place burdens on networks which have no interest in the L4S experiment.

 - Jonathan Morton