Re: [tsvwg] FQ & VPNs

Bob Briscoe <ietf@bobbriscoe.net> Sat, 20 February 2021 00:44 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 A056A3A0AB5 for <tsvwg@ietfa.amsl.com>; Fri, 19 Feb 2021 16:44:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.434
X-Spam-Level:
X-Spam-Status: No, score=-1.434 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, NICE_REPLY_A=-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 iXVjJbqKUuCP for <tsvwg@ietfa.amsl.com>; Fri, 19 Feb 2021 16:44:51 -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 45A863A0ABB for <tsvwg@ietf.org>; Fri, 19 Feb 2021 16:44:49 -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=hUeKtbJg1idQG1oD+iDhp1QzWzOcCqH5cr4GBm5UbQ0=; b=QviIxOEbNePDVKnC15/BSOCSFk +wSR9J0KSsGc3iThB3CR5mqZbiMl104q9U82iZG/6E0eN31lAX9WIulUxVFpR1XjWmp03L3UAavkl IiVFocrSxidM+RbPcobNSYTbgxG0mVYLn6I6Z0yG+XQFvSrkzn7tE4UIXmVksKkpVcEgB9sClMjE/ iIAJM/0cMDoj4AUnxCDrDn1RcrgSPBBlroRPU75/MjAxPc9iVADRxASwIC84HiAVejGCBRBwOToqi 7e3eFRExYx3yYASldGz/+GYORAmYYSIdFfONZvCnQ/9/m55DyGLnOrAa6bkXcPz5MwyfVfaVrgem/ 4sN55TRQ==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:40664 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 1lDGO6-00019p-Fr; Sat, 20 Feb 2021 00:44:46 +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> <43f43fa2-69c4-bc10-3ffb-e95e41809335@bobbriscoe.net> <ACB56762-4724-43FA-8A2B-ED0AD2AD7D9E@gmail.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <ad16822f-e102-2afc-373c-505312942ba7@bobbriscoe.net>
Date: Sat, 20 Feb 2021 00:44:46 +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: <ACB56762-4724-43FA-8A2B-ED0AD2AD7D9E@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
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/nu_bOlEqttq3qbpuEE5bN-jamVQ>
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: Sat, 20 Feb 2021 00:44:54 -0000

Jonathan,

Please engage in reasoned discussion. Particularly about occupancy over 
time.
If you've read what I've written and you disagree, please talk about it 
in a calm, measured manner, to argue against the actual points made, 
instead of asserting that you disagree, then threatening to run away 
with the ball unless I run some software you've written.

I'm going to take the list off future emails, 'cos this is not edifying 
for anyone else.

one inline...

On 19/02/2021 23:59, Jonathan Morton wrote:
>> On 20 Feb, 2021, at 1:26 am, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>>
>> 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've read your papers already.  I happen to disagree vigorously with their conclusions, and I believe others with far more standing than myself also do so.
>
>> I can tell 'cos:
>> a) you somehow think I am arguing for RTT-fairness (when have I ever done that?) and
> I'll quote you:  "…it would be preferable to deploy a FIFO AQM there."
>
> If you pass AIMD traffic through a single FIFO with a single AQM instance, what you get is a (slow) convergence towards equal cwnd values and thus RTT-fairness.  That is not a controversial statement, but the truth.  And that is what you explicitly recommended just a few sentences before asking this question.

[BB] There is no truth there, because the RTT-Fairness doesn't come from 
the FIFO. It comes from the assumption you've just added - that an 
ACK-clocked AIMD is running in all the senders. Anything can be run on 
the end-systems. You know I've argued that that is a "good thing".

It might help if you tried to summarize what you understand from the 
above paper about "flow sched and the e2e arg".
But pls, remove the list. The worst way to find why two people are 
disagreeing is to play to a crowd in the process.


Bob

>
>> 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.
> That is precisely where I'm aware of your point of view, but diametrically opposed to it.
>
> At this stage I can only recommend that you install Cake, turn on the host-and-flow fairness options, and just try it out for a while.  You might be pleasantly surprised by how well it works in practice.  In fact, until you have done so, I will simply not respond to any further posts by you on this subject.
>
>   - Jonathan Morton

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