From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 70D583B2A4 for ; Tue, 9 Mar 2021 09:27:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1615300069; bh=zHMMDd63X3rUB7LVDg4aqj7wvNSFQ4V5iwMIJMhUW8Q=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Mduvd9HoD7Wa/TqHc6GqcH1XFmVxRJv8CXyJgVvqXMgUJVuF3U+AkcNYMhG0fJr54 cmEUvK8cb/9z9MVK63Ms/nd+yoDNmuXUcaa5Y7RFqa1OS4xK3slfe93FUC9TfYerCm eNXDSBfN7c2WEjNqq88A/bzr/J0VfWlIjE815qgI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [172.16.10.207] ([134.76.241.253]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MLR1f-1l1HN81dqN-00ITsf; Tue, 09 Mar 2021 15:27:49 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Sebastian Moeller In-Reply-To: <0B2ABDF5-A4B0-418B-A6C3-90FE8E4F20BC@gmail.com> Date: Tue, 9 Mar 2021 15:27:48 +0100 Cc: Pete Heist , ECN-Sane Content-Transfer-Encoding: quoted-printable Message-Id: <13A4CC96-BF87-4E97-8298-B762751BDA35@gmx.de> References: <7ff9063df5c5e05420ef47245becb77a2de80f2f.camel@petri-meat.com> <1cb500b5cff9a570f71a9b92096f5f279f4a27e7.camel@heistp.net> <0B2ABDF5-A4B0-418B-A6C3-90FE8E4F20BC@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3445.104.17) X-Provags-ID: V03:K1:MUE9k3j8EiOTeSwL93IlWQcywnKjtk5kGlua9FQy0NfKPcSWt5T H+m6TAvz1MUyZs1cSAKq80oAM6NVak9n6uCGC9ZIKjVwY1CIq1+7PLv+Lb0bjMB8AKs7e2j byGyM6v1uc5jehmXOzA8IkvabAIeZT/EHtwfoTCjx84EjmxgTISw0WUketuN40x4x8niT07 mKWGGqqM2FCEAZ9VfrtHg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:TIgQFlHjtrI=:D1ShmbL4kH93zlSQA6N1Dk FFiIW9RRByTq06AQ2G0pSv2LZcvxMB4Sw8S0wSNT2odE7fkuQ3VBWFwlDd0M5kGmTLv3cy/Mh fP94NvG9o67703BeGeeR9CfMXpwRdQ96r+5C9DOr/kQA24BQkl7KdOhTOfrrRm2f5vkhfeES4 dWdmmDwuZSGCX0uwHuy8Urdlc8PwZcXLZDmWiYeAPGCPwtcQf7TjKzxEQ9LlHLt1ZhnLa8AjN em71TTcbERnK292sSIHwdgue2zR3t0oN1BhfeOyhBr9ObiwwVzYCtz7nr79yGKcxb64rv7ll1 4wJZ3V0v8i+ixv/3HUHLEeCWwP/NpEpZR8KmW71Hyo3l2+1pAwLYQIl9dDhvN7OFBGfKsYMT+ TjqPPX6FjaO23WLIPd20KCy8+vWiDi1S40lL9mSVMM6plfoKb6faia9bw5OwMXjAigOMkBDcR iQyanD8UbF2JmHMdR2/DMcO+MH/tcNfKeyJngaUwtM0V3CDIiWXq84gSYdbPknbheHakG8/v/ ID+Ood1tql8Lv37ntWpoRBnRvPu0PU9xPRNZJ7UXGzUsS0zcBzVxbwK/nxF1Y26QWA1K+w5Mp x8tR4FP2bSiF9hLXyR5I/jGDvEZPCe+p55/mQERDmCgU9D2y+P3oBaEDI8ERqSy6sl54t1gxc Y1t+81LG85eVWKJpzpkfpwwFvP+OIGRqF3OOHfHJV5oVtxNhoo/zQd4OyoH2j9QqmgPaS9MMP +i04w1xxz94nhYsPaEAO5NHa9cXg2NTajYFz+5DB5AnIfKLV7Z9iHBffCGkN5o0oiDCPSF/an 2+q8xReUVfWqK51x2zgU9TLzKLOOuI56DivR6ZooD7KTEdgt5O3ziAQdI40oawIM5A7L2gm1n 052HOe6X+ncNznka1blA== Subject: Re: [Ecn-sane] IETF 110 quick summary X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 14:27:51 -0000 Hi Jonathan, > On Mar 9, 2021, at 14:53, Jonathan Morton = wrote: >=20 >> On 9 Mar, 2021, at 11:57 am, Pete Heist wrote: >>=20 >> FQ protects competing flows, unless L4S and non-L4S traffic ends up = in >> the same queue. This can happen with a hash collision, or maybe more >> commonly, with tunneled traffic in tunnels that support copying the = ECN >> bits from the inner to the outer. If anyone thinks of any other = reasons >> we haven't considered why competing flows would share the same = 5-tuple >> and thus the same queue, do mention it. >=20 > Bob Briscoe's favourite defence to this, at the moment, seems to be = that multiple flows sharing one tunnel are *also* disadvantaged when = they share an FQ AQM bottleneck with multiple other flows that are not = tunnelled, and which the FQ mechanism *can* distinguish. Obviously this = is specious, but it's worth pinning down exactly *why* so we can explain = it back to him (and more importantly, anyone else paying attention). [SM] I think the way forward in this would be to embrace the = IPv6 flow label, and include it into the hash (sure will not help with = IPv4 tunnels). That way even tunneled flows can reveal them selves to = upper layers and get per-flow treatment (or they can decide to keep to = their secret ways, their choice). I think that trying to abuse the flow = label will result in massive reordering for the tunneled flow, so might = still be a risk (but it seems hard for an abuser to gain more usable = capacity). How do such tunnels behave in the prevalent FIFO's, do they actually get = a share depending on their number of hidden constituent flows, or are = they treated as a single flow? And in either case, isn't that not a = policy question the operator of the bottleneck should be able to = control? I snipped the rest of your excellent analysis, as I only want to bring = up the flow-label to side-step that issue partially. This does not solve = L4S' misdesign, but it will take Bob's argument the wind out of the = sails to some degree... Best Regards Sebastian=