[Ecn-sane] IETF 110 quick summary

[Dave Taht]

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 <moeller0 at gmx.de> wrote:
>
> Hi Jonathan,
>
>
> > On Mar 9, 2021, at 14:53, Jonathan Morton <chromatix99 at gmail.com> wrote:
> >
> >> On 9 Mar, 2021, at 11:57 am, Pete Heist <pete at 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
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane



-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

dave at taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729