From: "Holland, Jake" <jholland@akamai.com>
To: Dave Taht <dave.taht@gmail.com>, Pete Heist <pete@heistp.net>
Cc: ECN-Sane <ecn-sane@lists.bufferbloat.net>
Subject: Re: [Ecn-sane] IETF 110 quick summary
Date: Tue, 9 Mar 2021 02:13:57 +0000 [thread overview]
Message-ID: <FC045DF9-8AB7-4371-9B54-0C89BC3CB291@akamai.com> (raw)
In-Reply-To: <CAA93jw5E-_Z1EMhRt1Lq5+J0_h4UGQTpp3C+JUUE6SwHQaHFuw@mail.gmail.com>
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@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$
next prev parent reply other threads:[~2021-03-09 2:14 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-08 23:47 Pete Heist
2021-03-08 23:57 ` Dave Taht
2021-03-09 2:13 ` Holland, Jake [this message]
2021-03-09 4:06 ` Steven Blake
2021-03-09 9:57 ` Pete Heist
2021-03-09 13:53 ` Jonathan Morton
2021-03-09 14:27 ` Sebastian Moeller
2021-03-09 14:35 ` Dave Taht
2021-03-09 17:31 ` Steven Blake
2021-03-09 17:50 ` Steven Blake
2021-03-09 18:07 ` Rodney W. Grimes
2021-03-09 18:13 ` Pete Heist
2021-03-09 19:51 ` Holland, Jake
2021-03-09 20:53 ` Pete Heist
2021-03-09 18:44 ` Holland, Jake
2021-03-09 19:09 ` Jonathan Morton
2021-03-09 19:27 ` Holland, Jake
2021-03-09 19:42 ` Jonathan Morton
2021-03-09 8:43 ` Pete Heist
2021-03-09 15:57 ` Holland, Jake
2021-03-09 11:06 ` Jonathan Morton
2021-03-09 8:21 ` Pete Heist
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/ecn-sane.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=FC045DF9-8AB7-4371-9B54-0C89BC3CB291@akamai.com \
--to=jholland@akamai.com \
--cc=dave.taht@gmail.com \
--cc=ecn-sane@lists.bufferbloat.net \
--cc=pete@heistp.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox