Re: [Ecn-sane] IETF 110 quick summary

[Pete Heist <pete@heistp.net>]

On Mon, 2021-03-08 at 15:57 -0800, Dave Taht wrote:
> Thx very much for the update. I wanted to note that
> preseem does a lot of work with wisps and I wish they'd share more
> data on it, as well as our ever present mention of free.fr.
> 
> Another data point is that apple's early rollout of ecn was kind of
> a failure, and there are now so many workarounds in the os for it as
> to make coherent testing impossible.

Is there any info on what way it was a failure, or what workarounds
there are?

> I do wish there was more work on ecn enabling bbr, as presently
> it does negotiate ecn often and then completely ignores it. You can
> see this in traces from dropbox in particular.

I haven't tested BBR but briefly. I'd expect:
- BBR harming itself through fq_codel as TCP RTT goes up, but if it
also uses that as a signal to back off, I don't know the end result
- Harm to competing traffic in a tunnel through fq_codel

> On Mon, Mar 8, 2021 at 3:47 PM Pete Heist <pete@heistp.net> wrote:
> > 
> > Just responding to Dave's ask for a quick IETF 110 summary on ecn-
> > sane,
> > after one day. We presented the data on ECN at MAPRG
> > ( 
> > https://datatracker.ietf.org/doc/draft-heist-tsvwg-ecn-deployment-observations/
> > ). It basically just showed that ECN is in use by endpoints (more
> > as a
> > proportion across paths than a proportion of flows), that RFC3168
> > AQMs
> > do exist out there and are signaling, and that the ECN field can be
> > misused. There weren't any questions, maybe because we were the
> > last to
> > present and were already short on time.
> > 
> > We also applied that to L4S by first explaining that risk is the
> > product of severity and prevalence, and tried to increase the
> > awareness
> > about the flow domination problem when L4S flows meet non-L4S flows
> > (ECN or not) in a 3168 queue. Spreading this information seems to
> > go
> > slowly, as we're still hearing "oh really?", which leads me to
> > believe
> > 1) that people are tuning this debate out, and 2) it just takes a
> > long
> > time to comprehend, and to believe. It's still our stance that L4S
> > can't be deployed due to its signalling design, or if it is, the
> > end
> > result is likely to be more bleaching and confusion with the DS
> > field.
> > 
> > There was a question I'd already heard before about why fq_codel is
> > being deployed at an ISP, so I tried to cover that over in tsvwg.
> > Basically, fq_codel is not ideal for this purpose, lacking host and
> > subscriber fairness, but it's available and effective, so it's a
> > good
> > start.
> > 
> > Wednesday's TSVWG session will be entirely devoted to L4S drafts.
> > 
> > 
> > _______________________________________________
> > Ecn-sane mailing list
> > Ecn-sane@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/ecn-sane
> 
> 
>