[Ecn-sane] IETF 110 quick summary

[Steven Blake]

If I'm a random network operator, not participating in any L4S
experiments, and L4S traffic traversing my network hits a bottleneck,
what happens? Consider all of the cases (no AQM tail-drop, AQM-drop,
AQM-classic ECN).

My understanding was that TCP-Prague's classic bottleneck detection
code wasn't fully baked.


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 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.
> 
> 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 at 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 at 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.


Regards,

// Steve