Re: [tsvwg] FQ & VPNs (was: Fwd: New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-00.txt)

Jonathan Morton <> Fri, 19 February 2021 22:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3E5B3A0B56 for <>; Fri, 19 Feb 2021 14:11:27 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 XzrcvY4VGzNq for <>; Fri, 19 Feb 2021 14:11:26 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B2563A0B44 for <>; Fri, 19 Feb 2021 14:11:26 -0800 (PST)
Received: by with SMTP id v6so29491213ljh.9 for <>; Fri, 19 Feb 2021 14:11: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=BtwpUMX/UajeYNdQfYjC3TKuLUNU6CYvlNfRrZLRqso=; b=Pk38Jf2EOM7n5r4631M5+CgG+auLhTGPZaCSCs7FSHa4+PdBxtr0m2SQrP4x3dbYkA wJXNvO/XBFdi+m2bZIQC6v0CbrClVm1MHRM8N5CKfKrzXNL0bJ1U9jvZa6jNsZzTG24d gYm3G/5F3NqD76trpnXSj5Zd/tBK3MEoZO4sJzkg2Z3hwq/M9UqsEuCDj7tDFweMnFnD TkBcq9eQ4i0UEITmP0Pb3l7NjaRHYbXHuVR1aHUgdTXi6vtC4leO/BOzjjY1IdsMGaj0 TYd20N6Pq7u2SHMBXdN76hID5Tb4XhWeyV92zttKo3lMMZUK1JWR8z4ddTsBvhDomFpM uDKQ==
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=BtwpUMX/UajeYNdQfYjC3TKuLUNU6CYvlNfRrZLRqso=; b=SjqQ2qLyymaM59eUwcHKIbO24hka5mkmhYrQRwLZjkB9E9XhjpjlMZ2+f436V4gRZi Qi06n8VX55Zh8G4ie2yJjlQrEpuWoHBZzO9uTcsljgxiAQU1g/j74+ocyRqQBQU8H3nv AIVaga3pjyYmlVnv5HECdhrbABEThX+lCSDi9XroLc5glw7fznE16i6MvsYmR0zpprvr 7tJGbmqlRXiak9XBcWzJz35D7SxRrBG2MLNZwHuuBlYVTn33BBtkllgKnm8deybqFXcE 2g6wod2+clVxf2AMD16D6VNdxV0SF+bL1U8V2+Z0JFj/NDDLxFFk1BkjCeO6dtLRJtWn fygQ==
X-Gm-Message-State: AOAM530poUiKf7YK88yir62uAP6TLdTivdCqYJq/8REIjacSQHCDc0Va 8uQYnu+ipJo0pG5jMqsbWfM=
X-Google-Smtp-Source: ABdhPJzauEx5eA3tIm5Q4zRJ9ACkYJBTXtTHkjRoBi/GBxJxn5HZtpt2lr91+MxkmxzmDytYhY4AYA==
X-Received: by 2002:a19:4f0e:: with SMTP id d14mr7082554lfb.298.1613772684369; Fri, 19 Feb 2021 14:11:24 -0800 (PST)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id z20sm1041056lfj.178.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Feb 2021 14:11:24 -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: Sat, 20 Feb 2021 00:11:22 +0200
Cc: Pete Heist <>, TSVWG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Bob Briscoe <>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <>
Subject: Re: [tsvwg] FQ & VPNs (was: Fwd: New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-00.txt)
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: Fri, 19 Feb 2021 22:11:28 -0000

> On 19 Feb, 2021, at 11:54 pm, Bob Briscoe <> wrote:
>> However, I would remind you that neither SFQ nor fq_codel can distinguish between flows carried inside an encrypted tunnel, so this cannot be relied upon alone to make L4S safe.  Pete's data shows significant tunnelled traffic, much of which is probably due to people working from home and using VPNs to access a corporate network.
> [BB] So would you not advise this ISP to remove the FQ on their backhaul, given they are serving large amounts of tunnelled VPN traffic?

No, of course not.  Max-min fairness is the gold standard, after all, and that is what FQ is designed to provide at a saturated bottleneck.  I honestly don't understand why you keep arguing, in effect, for RTT-fairness while promoting a specification which mandates working to eliminate it.

At a bottleneck which is *not* persistently saturated, FQ serves to insulate latency-sensitive flows from bursty ones, and sparse flows from spurious AQM activity sparked by transient saturating loads.  Are these not good things, even absent any rigorous notion of "fairness"?

It is possible, of course, that improved *perceived* max-min fairness would be achieved by moving to an algorithm that is fair between subscriber IP addresses as well as between flows to each subscriber.  Cake is capable of doing that, and I have plans to upgrade some of my other qdiscs to match.  Would that solve your objection to flow isolation?

> Debating games like this just turn people off.

Yes, they do - and in recognition of that, perhaps we could avoid going over old ground like this, yet again.

 - Jonathan Morton