From: Pete Heist <pete@heistp.net>
To: ECN-Sane <ecn-sane@lists.bufferbloat.net>
Subject: [Ecn-sane] IETF 110 quick summary
Date: Tue, 09 Mar 2021 00:47:37 +0100 [thread overview]
Message-ID: <af4eadbd15574bf97b55d252a2eb2c9309bbcbac.camel@heistp.net> (raw)
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.
next reply other threads:[~2021-03-08 23:47 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-08 23:47 Pete Heist [this message]
2021-03-08 23:57 ` Dave Taht
2021-03-09 2:13 ` Holland, Jake
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=af4eadbd15574bf97b55d252a2eb2c9309bbcbac.camel@heistp.net \
--to=pete@heistp.net \
--cc=ecn-sane@lists.bufferbloat.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