Re: [Ecn-sane] IETF 110 quick summary

[Pete Heist <pete@heistp.net>]

On Tue, 2021-03-09 at 02:13 +0000, Holland, Jake wrote:
> The presentations were pretty great, but they were really short
> on time.  In the chat a person or 2 was surprised about the way
> L4S will impact NECT competing traffic when competing in a queue.
> I agree some of the people who have tuned out the discussion are
> learning things from these presentations, and I thought Jonathan's
> slot was a good framing of the real question, and Pete's study was
> also very helpful.

I'm glad to hear that. At least it adds something to your work before,
from a different vantage point, albeit much smaller. I know that
studies from entirely disinterested parties would be good too, but that
might the hard part, they're disinterested! :)

> I seem to recall a thread in the wake of Apple's ECN enabling about
> one of the Linux distros considering turning ECN on by default for
> outbound connections, in which one of them found that it completely
> wrecked his throughput, and so it got tabled with unfortunately
> no pcap posted.
> 
> Any recollection of where that was?  I was guessing it might be
> one of the misbehaviors from the network that Apple encountered.

That is odd and would be good to know about. I enabled ECN on my Linux
laptop a long time ago and haven't noticed a problem that I'm aware of.
I wish the distros would reconsider enabling it, unless there are
active reasons it shouldn't be deployed, but they may now just be in a
holding pattern on it.

> I also thought Apple had a sysctl to disable the hold-downs and
> always use ECN in spite of the heuristics, did that not work?
> 
> -Jake
> 
> On 3/8/21, 3:57 PM, "Dave Taht" <dave.taht@gmail.com> 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.
> 
> 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.
> 
> 
> 
> 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-heist-tsvwg-ecn-deployment-observations/__;!!GjvTz_vk!AsneqOLeLWeNxzyWItOxlVbVQYefAMLslNpK4U9NEHw0dfUI0vDG7O07G3f1kzw$
> >  
> > ). 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://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/ecn-sane__;!!GjvTz_vk!AsneqOLeLWeNxzyWItOxlVbVQYefAMLslNpK4U9NEHw0dfUI0vDG7O07L2Cfk-Y$
> >  
> 
> 
> 
> -- 
> "For a successful technology, reality must take precedence over
> public
> relations, for Mother Nature cannot be fooled" - Richard Feynman
> 
> dave@taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane@lists.bufferbloat.net
>  
> https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/ecn-sane__;!!GjvTz_vk!AsneqOLeLWeNxzyWItOxlVbVQYefAMLslNpK4U9NEHw0dfUI0vDG7O07L2Cfk-Y$
>  
>