From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A70EE3B2A4 for ; Tue, 9 Mar 2021 09:35:32 -0500 (EST) Received: by mail-il1-x136.google.com with SMTP id z9so12372385iln.1 for ; Tue, 09 Mar 2021 06:35:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=98l3tbuYGIQOPvCJOFiIsDtddGPQGgwh9kSw9l5YaLs=; b=IMy105Z9Z8bi08OflJX30p+z4qnC6zEKibO2qDiikJLvIDufWGwdkKfCPMd1LqmVVc 7dVNEeeRrqa4peZowoz/KsTY38Q87y2yY9X7bDGzb8ORM2N4ZmdBFCZiYUWbvgOiDP6G JHOHLmUCboz9bemPm9b2YhFoDtFIEghTu46N8x+bZYAe5ZeJGftZS3ifl43wckqWBWSA Te/e39TPyePlj/N21dozc57NE64J8MVsFhzz+u5tWBlL+7zdVAYhEH5z2+vBhEIXnYg+ Mn8g9ajGUMqfXd4RR8bslq7aT2lo2OMohRD4yCScg+xQk2wBlfyM2sSx7TXxHlYFTpO8 shiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=98l3tbuYGIQOPvCJOFiIsDtddGPQGgwh9kSw9l5YaLs=; b=UKJo4T+2h+v20/XFhcLmYXj47bedn0luMNKoF7V4lzPYUHpmo6NhLbWIJa301SYjsY fCPKDSouJkkspm5GlGPlxmXGguNmPSxevHgoDfuKVk764BaTYqJ1IQha031FtyJBeBmj 7Okw1Jy/DMBYux2sQLGWkpRxQdic6KQuAmfTz4hsH50HuVdFsF6uJw67QmSx+3rgwSZa RZZEyIBhgT85abZfYLDMpztCMxlvpW8OWnNL5o+C0B7TmO1rnwUY5UAuqpEx4mysWTI1 B6DUGqnhb7kTTDEd9ohAyrW1/xC0X8Olnj3HlMVjMZTl4uERCX0W+cXBmkOecHXVGw/M 2b1A== X-Gm-Message-State: AOAM530oXEKgxnw3h4H/xHvICtW6F7CVITmitQK6S6RIi4GjtY6fhN+o WeUV9BJgTfuI+YQgqSF+RygS3nYaA21FsgCb+pc= X-Google-Smtp-Source: ABdhPJymhmnWTGTn8Upmc81wWAa8zgN0iQUZjQhIL79rc9bzk6ojsarcIGzMuyHNv4d+Q5Tt6c8cvp10XlrFk3aRNBk= X-Received: by 2002:a05:6e02:2142:: with SMTP id d2mr24487317ilv.249.1615300532079; Tue, 09 Mar 2021 06:35:32 -0800 (PST) MIME-Version: 1.0 References: <7ff9063df5c5e05420ef47245becb77a2de80f2f.camel@petri-meat.com> <1cb500b5cff9a570f71a9b92096f5f279f4a27e7.camel@heistp.net> <0B2ABDF5-A4B0-418B-A6C3-90FE8E4F20BC@gmail.com> <13A4CC96-BF87-4E97-8298-B762751BDA35@gmx.de> In-Reply-To: <13A4CC96-BF87-4E97-8298-B762751BDA35@gmx.de> From: Dave Taht Date: Tue, 9 Mar 2021 06:35:20 -0800 Message-ID: To: Sebastian Moeller Cc: Jonathan Morton , ECN-Sane Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:35:32 -0000 I would certainly like to see more exploration of when and where the ipv6 flow label gets peed on. but as it is yet another untried idea... On Tue, Mar 9, 2021 at 6:27 AM Sebastian Moeller wrote: > > Hi Jonathan, > > > > On Mar 9, 2021, at 14:53, Jonathan Morton wrote= : > > > >> On 9 Mar, 2021, at 11:57 am, Pete Heist wrote: > >> > >> 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 EC= N > >> bits from the inner to the outer. If anyone thinks of any other reason= s > >> we haven't considered why competing flows would share the same 5-tuple > >> and thus the same queue, do mention it. > > > > Bob Briscoe's favourite defence to this, at the moment, seems to be tha= t multiple flows sharing one tunnel are *also* disadvantaged when they shar= e an FQ AQM bottleneck with multiple other flows that are not tunnelled, an= d which the FQ mechanism *can* distinguish. Obviously this is specious, bu= t it's worth pinning down exactly *why* so we can explain it back to him (a= nd 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 tun= nels). 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 quest= ion 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 so= me degree... > > Best Regards > Sebastian > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane --=20 "For a successful technology, reality must take precedence over public relations, for Mother Nature cannot be fooled" - Richard Feynman dave@taht.net CTO, TekLibre, LLC Tel: 1-831-435-0729