Re: [tsvwg] L4S operational guidance draft

Sebastian Moeller <moeller0@gmx.de> Wed, 18 November 2020 07:21 UTC

Return-Path: <moeller0@gmx.de>
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 AC4083A0C86; Tue, 17 Nov 2020 23:21:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 kUeiBr-x7L_P; Tue, 17 Nov 2020 23:21:32 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 843CB3A0C8A; Tue, 17 Nov 2020 23:21:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1605684088; bh=WumulIo4x+bQBpPXkJZe3prLGK0XyKwupHt3BgVhIL8=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:CC:From; b=LAEYw2aJtMaJ2CDoGebt6URpTmKSQAYUz9oz6WVGRioLerc7jk+fJr+om1uhaWubY KJdYmzmZcigTr1GndAjRIu6815RBiHHo0+JE3vlXRS/doc3dF+WPZZmKHAf29KczbE 0mCHocduGzbYWBC+mdIqiYpN515JkTr2/UCoztt0=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.17] ([134.76.241.253]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MMobU-1kvihX3O8C-00IpbQ; Wed, 18 Nov 2020 08:21:27 +0100
Date: Wed, 18 Nov 2020 08:21:26 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <HE1PR0701MB28761A98F113177964FC2AF2C2E10@HE1PR0701MB2876.eurprd07.prod.outlook.com>
References: <b6bc81f5-e1f2-e226-1612-7f1070290bbd@mti-systems.com> <9CC37D46-3783-47DD-A1C8-7106EF437642@akamai.com> <f6ebc50de8d7ee42621a8db673f05d17ed8694c4.camel@heistp.net> <5FAF8D38-369B-4642-AAD2-BD5F7E430542@akamai.com> <HE1PR0701MB28761A98F113177964FC2AF2C2E10@HE1PR0701MB2876.eurprd07.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: tsvwg@ietf.org, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>, "Holland, Jake" <jholland=40akamai.com@dmarc.ietf.org>, Pete Heist <pete@heistp.net>, Wesley Eddy <wes@mti-systems.com>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>
From: Sebastian Moeller <moeller0@gmx.de>
Message-ID: <A322EF18-ECA7-452D-9BB1-7CC7752EE4CB@gmx.de>
X-Provags-ID: V03:K1:pPnkq4El8wyeKKRYajuvfN2m9sngZZNp8fLU7zPd8xJGupNGNbg 5wHCKY36afOb1x8ut2nCuuTUACaYFolehhYU/PFxSgDSai18sWs6JgkDtrs20b2qwqt+81V rtSUwVm8Du0GqVDXD5ye/7ZOC2k8XOY1LcZ6RumNUNgR8nyBX1HQn0oir7/0rhDE+7s3Mub eTsho3cZ931rNnH7AiPnA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Doza68lqYmA=:drk25uXFQl73MCd7T/6i1f r3Ppc/S6v6V8ToKUC3ik2q4tMsj+anZvRk0ElSpUWiF3Y3R3OzPVdEo2gPaJdZ3oGuGnGa2YI Es3spQxfa5RHfZB5YQrJvmvQSpClVZCackHzfOAM4GvQt4teICfwVnuQvN8i/SOOzkg+/oEuL sBVdr+7ildGI76Vh0JrxgCKltCjFGT69LJIgqnCFHjlWC9PghsNCXRiZZ3MhvNWAUmngpssUk 1R0O5tqaKKyh0b8YaP/FK1qfz5K8gwKHDpxkUCh3sQKfm+SC3jTePg/yBpjIC8EmL6I/RC4L/ 8jzf75EmRb5tf4KcByy0kQ1YUYll1SzZiy1BLn7180H1fm6ETx9stJf9y9IIlkO5AxOvezI1W 2ViiMsTA6pxHRZoGmX2YOy67TphMNt7f3CAflpT2Q7s+JEup4Ej2qX6LzHupkeVtFMPN7Oi+Y FMBMQoj2AZrcweqllfoWlfbLhxmXQZ5YbNOFHB7rCQNWZyXFKlzC7D616tEwDlg9kAS3Ab0iz tRCF4e8paE7TkvCibY1LF/m12fwc4TzjiobASkN/3hT7dZ6HZRX0o8D6Ee7buji+EwFJmGQ1d wjJUkorj8MU7DKRbgL/jDAPCovcaB+ZFz9c5vMoIMxafUTbTDwFWDlifA7Fb70Wn4Kkgcnp87 pDN9IbAdliDT1bp8M/Ox2Jjx5B1//VneNrfL8B/A3XWdVMCrjhwIBPTF1VpX+9dNaf5S1tbQS /koPfB8D9trlOH+ZH9WwwW0UUAiECwXp9NqrcwdsRQo/JTGSRqh42gZbTTUUxAh6roX0NqfHF 1yUAf956ZznzxkR+s6EsYfJrG9CSXtRtdkdrs3jS4ZSPrQZU/TO/OASR/Mbkce4diC6HI8qV1 YCOkiU5YX4++EfSTvpESyNiIT5v6t3T6WY9F9CTclN2IDbNnbMtkyr+k4VjLtC3Z2NVtMevB9 k+iuuP9yw2d+1vwaGMaKoNgvLonQh5Dc=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/5H8azR15WOKHPY_rE4RUR9NjgAs>
Subject: Re: [tsvwg] L4S operational guidance draft
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: Wed, 18 Nov 2020 07:21:34 -0000

Hi Ingemar,



On 18 November 2020 07:44:04 CET, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org> wrote:
>Hi Jake and Pete + others
>
>I try to understand this input, thanks for raining this BTW. 
>
>I interpret this as: 
>1) Flow queue AQMs don't work properly across tunnels, as flow
>isolation based om 5-tuple does not work


         Another, less negative, interpretation is that tunnels, that multiplex multiple flows into one externally visible flow are treated and recognized only as that flow. Which for things like encrypted VPNs is exactly the behavior that seems appropriate, no?

Best Regards
          Sebastian

>2) L4S flows can potentially (or will) get an unfair share as a
>consequence of #1 above because the bootleneck only implement a RFC3168
>ECN marking. 
>
>Is this understanding correct ?
>
>/Ingemar
>
>> -----Original Message-----
>> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Holland, Jake
>> Sent: den 18 november 2020 03:21
>> To: Pete Heist <pete@heistp.net>; Wesley Eddy <wes@mti-systems.com>
>> Cc: tsvwg@ietf.org
>> Subject: Re: [tsvwg] L4S operational guidance draft
>> 
>> Hi Pete,
>> 
>> On 11/17/20, 12:04 PM, "Pete Heist" <pete@heistp.net> wrote:
>> > One addition to this is the fact that when tunneled traffic
>traverses
>> > fq_codel, since the 5-tuple for all of the tunnel's inner flows is
>the
>> > same, that places them in one fq_codel queue, leading to the same
>> > safety problem when L4S and non-L4S flows meet. So, while single
>queue
>> > RFC3168 AQMs or hash collisions are one way for that to happen,
>> > tunneled traffic may be a more likely way. We recently added a test
>> > scenario using Wireguard through fq_codel to cover that case, which
>> > for some reason I didn't think to try earlier:
>> >
>> > https://protect2.fireeye.com/v1/url?k=aaf3845d-f568bd70-aaf3c4c6-
>> 8692d
>> > c8284cb-99cc9ade2897f933&q=1&e=b25cd448-5648-4fc4-8858-
>> a85d6c2df9b0&u=
>> > https%3A%2F%2Fgithub.com%2Fheistp%2Fl4s-tests%2F%23unsafety-in-
>> tunnels
>> > -through-rfc3168-bottlenecks
>> >
>> > That should probably be covered in the guidance in relation to FQ
>> > classic ECN as well...
>> 
>> Thanks Pete, I 100% agree.  I knew I was forgetting something.
>> 
>> I meant to include exactly that sentiment and link, and I thought it
>was a very
>> helpful point when you posted it a few weeks ago, but several hundred
>> messages later it slipped my mind while writing this up.  Thanks for
>getting it in
>> there.
>> 
>> Best regards,
>> Jake
>> 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.