[Ecn-sane] IETF 110 quick summary

[Holland, Jake]

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.
>
>
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane at 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 at taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729
_______________________________________________
Ecn-sane mailing list
Ecn-sane at lists.bufferbloat.net
https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/ecn-sane__;!!GjvTz_vk!AsneqOLeLWeNxzyWItOxlVbVQYefAMLslNpK4U9NEHw0dfUI0vDG7O07L2Cfk-Y$