Re: [tsvwg] FQ & VPNs

Bob Briscoe <ietf@bobbriscoe.net> Fri, 19 February 2021 23:26 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0BB3A0D91 for <tsvwg@ietfa.amsl.com>; Fri, 19 Feb 2021 15:26:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.567
X-Spam-Level: ***
X-Spam-Status: No, score=3.567 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, GB_SUMOF=5, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaVmASV7DGVS for <tsvwg@ietfa.amsl.com>; Fri, 19 Feb 2021 15:26:11 -0800 (PST)
Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.84.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217A23A0D85 for <tsvwg@ietf.org>; Fri, 19 Feb 2021 15:26:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zQ0ojHFM/hhZzZEVPaCY62J9hd6ednADzikEYIXHWfQ=; b=a6Who0+GLtwssqaA1p4YxrZqbk tdiPvE7KKlgTSUmSefdANy3UFD+L5MuN7jl2rwFhrbs4Al0jv6VlqyPARfAWuXuY5r7+nsHCWRasr Vck1avVJaEo3ZMH2CeLNfYAUvATgP4EYThjs+TquSQ27KRy9D3KKYCDgcGvRv+Y0Iax0gplB5Xm9z dBa93Rtmc+s61p+sIGhvp/nuTtLM+5mxEdLG081UJYFZYz6iXBez1YblMbBZhY17GBmsXJ4xeaIM+ z9cJ6rQsvEeAdEW9S6OBMoBQWHTPcRYj4UEEAiH3StziAbhc5gwvU4kTTWMxEaCq1useZBSlNfG9a R8SwMy/A==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:39954 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <ietf@bobbriscoe.net>) id 1lDF9z-0003RZ-NH; Fri, 19 Feb 2021 23:26:07 +0000
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Pete Heist <pete@heistp.net>, TSVWG <tsvwg@ietf.org>
References: <161366419040.16138.17111583810851995947@ietfa.amsl.com> <BF0810D9-E742-4FCB-90B1-6957551B585D@heistp.net> <b222bbdf-70ae-3e5b-b122-1160299fb4e2@bobbriscoe.net> <E7CC88FA-F064-4B72-BAA9-8BE40F7AF040@gmail.com> <52cb434a-bd91-6260-7be9-85bdbd07b625@bobbriscoe.net> <BCAB7068-A10A-4FC4-9719-E300F644262C@gmail.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <43f43fa2-69c4-bc10-3ffb-e95e41809335@bobbriscoe.net>
Date: Fri, 19 Feb 2021 23:26:08 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <BCAB7068-A10A-4FC4-9719-E300F644262C@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/NGRqHhpt-wi7hJf6QVOM1dmEoVY>
Subject: Re: [tsvwg] FQ & VPNs
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Feb 2021 23:26:13 -0000

Jonathan,

On 19/02/2021 22:11, Jonathan Morton wrote:
>
>> On 19 Feb, 2021, at 11:54 pm, Bob Briscoe <ietf@bobbriscoe.net> 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"?

[BB] On a highly aggregated backhaul link that is only seeing transient 
queuing (probably of the order of 10 or 100 us), there's little need for 
an AQM at all.

But if this backhaul link is capable of being saturated by the sum of 
the access links (i.e. it's theoretically overbooked but relying on 
average usage patterns to remain under-utilized), it would be preferable 
to deploy a FIFO AQM there. With an FQ AQM, if a large proportion of the 
traffic is in VPNs, just when the AQM is most needed, it would makes 
matters worse (i.e. all the flows within the VPNs would get a focused 
hit on their throughput, so they would collectively cause massive queues 
within each per-flow-queue being used by each VPN).


> 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?

[BB] You are talking about instantaneous rate fairness, with no concept 
of occupancy over time. There's been so much more water under this 
bridge since the 1980s/90s. Try this: 
https://bobbriscoe.net/presents/1210isoc/1210isoc-briscoe.pdf

Clearly you never read/absorbed what I wrote for you (specifically for 
you more than anyone else) about this:
Per-Flow Scheduling and the End-to-End Argument: 
https://bobbriscoe.net/pubs.html#FQ_v_E2E

I can tell 'cos:
a) you somehow think I am arguing for RTT-fairness (when have I ever 
done that?) and
b) the assertion that max-min fairness is the gold standard. If you had 
read anything from me, you would at least make a nod to my explanations 
about why max-min only makes any sense during a persistent famine (I 
mean famine for hours/days/weeks), and in all other scenarios max-min is 
the opposite of gold - it's the most rubbish monkey-metal crazy standard 
in a non-famine world.



Bob

>
>> 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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/