Re: [tsvwg] FQ & VPNs

Tom Henderson <tomh@tomh.org> Sun, 21 February 2021 18:56 UTC

Return-Path: <tomh@tomh.org>
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 0E3493A0EB2 for <tsvwg@ietfa.amsl.com>; Sun, 21 Feb 2021 10:56:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tomh.org
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 LDcs3FiRio8f for <tsvwg@ietfa.amsl.com>; Sun, 21 Feb 2021 10:56:54 -0800 (PST)
Received: from gateway32.websitewelcome.com (gateway32.websitewelcome.com [192.185.145.178]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92093A0EAE for <tsvwg@ietf.org>; Sun, 21 Feb 2021 10:56:53 -0800 (PST)
Received: from cm13.websitewelcome.com (cm13.websitewelcome.com [100.42.49.6]) by gateway32.websitewelcome.com (Postfix) with ESMTP id 166AEB919F2 for <tsvwg@ietf.org>; Sun, 21 Feb 2021 12:56:53 -0600 (CST)
Received: from box5867.bluehost.com ([162.241.24.113]) by cmsmtp with SMTP id DtuXlXeAEoE4DDtuXlTrly; Sun, 21 Feb 2021 12:56:53 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; 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=7Ssq0UMRniyv4S6P196WqzcDKJUM/lkK2/uETDY/+Ck=; b=6DjvlZdVfAULT0nGraQroekZt+ o4dp37mfr2UH7i8MxLU9vVWL8Bx3IjNXyCc4qDrLCvlZieCSAkHWKFWK3MXcK0MdWIoRVEqPcvRam CcDUNbxw1feN5aEo+AHjCfmdOct76JV/zVJKyepLXP9Dst8J7LKHORkByGALA1E4BNWWOizQ5Z2t5 0hnDpW4eDd8/vFgacuzyAFq+rJc1dUP5wO8GCVWK0kkCPw79xja1vkzbqgZK9o4+CefmbW4OXdsmN trKgpvQxLkznni2Sxbuw8lhnbQGxY2SQgzf6bv/V/EK0in9BxCqLtxDIYF2I96lpu22bdVXfovoZT HKNgPfyw==;
Received: from c-73-35-161-107.hsd1.wa.comcast.net ([73.35.161.107]:46114 helo=[192.168.168.110]) by box5867.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <tomh@tomh.org>) id 1lDtuW-0015MA-NF; Sun, 21 Feb 2021 11:56:52 -0700
To: Dave Taht <dave.taht@gmail.com>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Cc: 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> <4835a3cd-4d88-68ac-d172-1e21bc42a150@bobbriscoe.net> <CAA93jw7_yvkqU-uxHkbHkO2g_RFmzCmJcxQhMJcBQjo=+QMh=w@mail.gmail.com> <HE1PR0701MB2299CF42CA83576C86070BB0C2839@HE1PR0701MB2299.eurprd07.prod.outlook.com> <13EBAF97-A9AF-47A1-AB71-546C31F762C2@gmail.com> <HE1PR0701MB22999A319816198B515234BEC2829@HE1PR0701MB2299.eurprd07.prod.outlook.com> <CAA93jw6GNbgOSDfWo2mQPWSS5GQdTNqtq=fBgspP=MNkyPNtfA@mail.gmail.com>
From: Tom Henderson <tomh@tomh.org>
Message-ID: <eef468c8-1152-f6e8-cfbf-c80cb2d465a0@tomh.org>
Date: Sun, 21 Feb 2021 10:56:51 -0800
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: <CAA93jw6GNbgOSDfWo2mQPWSS5GQdTNqtq=fBgspP=MNkyPNtfA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box5867.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - tomh.org
X-BWhitelist: no
X-Source-IP: 73.35.161.107
X-Source-L: No
X-Exim-ID: 1lDtuW-0015MA-NF
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: c-73-35-161-107.hsd1.wa.comcast.net ([192.168.168.110]) [73.35.161.107]:46114
X-Source-Auth: tomhorg
X-Email-Count: 9
X-Source-Cap: dG9taG9yZzt0b21ob3JnO2JveDU4NjcuYmx1ZWhvc3QuY29t
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/cUrt7arnph0DcqalvbrG82h88eU>
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: Sun, 21 Feb 2021 18:56:56 -0000

On 2/21/21 4:00 AM, Dave Taht wrote:
> Participating reluctantly, as usual.
> 
> On Sat, Feb 20, 2021 at 11:04 PM Ingemar Johansson S 
> <ingemar.s.johansson@ericsson.com 
> <mailto:ingemar.s.johansson@ericsson.com>> wrote:
> 
>     Hi____
> 
>     __ __
> 
>     Trying to summarize. Your concern is that the L4S flows starve out
>     the non-L4S flows when they share the same VPN tunnel. ____
> 
>     You proposed the solution yourself below: ____
> 
>     “The VPN user is thus in a position to predict, understand, and
>     possibly mitigate the effect by splitting the traffic across
>     multiple VPN flows, if performance turns out to be more important
>     than hiding that piece of information”. ____
> 
>     The same rationale can be used to put the L4S flows in a separate
>     VPN tunnel, problem solved.____
> 
>     __
> 
> 
> In terms of VPNs there are multiple other problems. Site-site, bare 
> metal, running fq_codel over ipsec
> 
>     __
> 
>     And then, there is always a possibility to upgrade the AQMs to
>     support L4S as well ?. It always appear from your argumentation that
>     fq-codel is some kind of untouchable monolith that cannot at any
>     cost be modified, unless of course you see a possibility that VPN
>     tunnels can somehow leak inner header information (see separate
>     discussion around draft-ietf-tsvwg-transport-encrypt)____
> 
>     __
> 
> 
> It's not an untouchable monolith. It is merely the default qdisc in 
> nearly every linux distribution at this point, ios, and osx. It is used 
> by 10s, maybe 100s of millions of devices at this point. It is part of 
> billions of containers. With nearly 9 years of deployment into an ever 
> increasing number of embedded devices that typically lag 5 or more years 
> behind the mainline OSes. Making changes to how ecn is interpreted would 
> take 8+ years to flush out of the field.

Dave, it seems to me that this could be taken in two steps, in much less 
time than 8+ years for the majority of devices, given that most are (or 
should be) patched for other security reasons.

1) upstream a patch to the Linux kernel (and ask other OS vendors to do 
similarly) to treat ECT(1) as not-ECT
2) later add options to enable alternative semantics of ECT(1)

I don't see any reason to postpone the first step.

- Tom