From: Sebastian Moeller <moeller0@gmx.de>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Pete Heist <pete@heistp.net>, ECN-Sane <ecn-sane@lists.bufferbloat.net>
Subject: Re: [Ecn-sane] IETF 110 quick summary
Date: Tue, 9 Mar 2021 15:27:48 +0100 [thread overview]
Message-ID: <13A4CC96-BF87-4E97-8298-B762751BDA35@gmx.de> (raw)
In-Reply-To: <0B2ABDF5-A4B0-418B-A6C3-90FE8E4F20BC@gmail.com>
Hi Jonathan,
> On Mar 9, 2021, at 14:53, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 9 Mar, 2021, at 11:57 am, Pete Heist <pete@heistp.net> 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 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.
>
> 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
next prev parent reply other threads:[~2021-03-09 14:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-08 23:47 Pete Heist
2021-03-08 23:57 ` Dave Taht
2021-03-09 2:13 ` Holland, Jake
2021-03-09 4:06 ` Steven Blake
2021-03-09 9:57 ` Pete Heist
2021-03-09 13:53 ` Jonathan Morton
2021-03-09 14:27 ` Sebastian Moeller [this message]
2021-03-09 14:35 ` Dave Taht
2021-03-09 17:31 ` Steven Blake
2021-03-09 17:50 ` Steven Blake
2021-03-09 18:07 ` Rodney W. Grimes
2021-03-09 18:13 ` Pete Heist
2021-03-09 19:51 ` Holland, Jake
2021-03-09 20:53 ` Pete Heist
2021-03-09 18:44 ` Holland, Jake
2021-03-09 19:09 ` Jonathan Morton
2021-03-09 19:27 ` Holland, Jake
2021-03-09 19:42 ` Jonathan Morton
2021-03-09 8:43 ` Pete Heist
2021-03-09 15:57 ` Holland, Jake
2021-03-09 11:06 ` Jonathan Morton
2021-03-09 8:21 ` Pete Heist
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/ecn-sane.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=13A4CC96-BF87-4E97-8298-B762751BDA35@gmx.de \
--to=moeller0@gmx.de \
--cc=chromatix99@gmail.com \
--cc=ecn-sane@lists.bufferbloat.net \
--cc=pete@heistp.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox