From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
To: Steven Blake <slblake@petri-meat.com>
Cc: Jonathan Morton <chromatix99@gmail.com>,
ECN-Sane <ecn-sane@lists.bufferbloat.net>
Subject: Re: [Ecn-sane] IETF 110 quick summary
Date: Tue, 9 Mar 2021 10:07:21 -0800 (PST) [thread overview]
Message-ID: <202103091807.129I7LYx078190@gndrsh.dnsmgr.net> (raw)
In-Reply-To: <9cbf2c365c0ad635b6f08311d35e0681aa173af7.camel@petri-meat.com>
> On Tue, 2021-03-09 at 12:31 -0500, Steven Blake wrote:
>
> > Their whole safety plan depends on the claim that Classic RFC 3168
> > ECN
> > is not deployed (except in fq_codel on the edge; who cares? they can
> > patch their code). If that were the case, it would make more sense
> > for
> > them to try to move classic ECN to historic and redefine ECT(0) to
> > signal L4S traffic (ala DCTCP).
>
> Actually, that is the ideal outcome. ECT(0) signals ECT-Capable, ECT(1)
> and CE signal two levels of congestion. In other words, SCE everywhere.
>
> Maybe that is an argument that you can throw at them: if it is safe to
> ignore classic ECN, might as well move straight to SCE with non-ECT
> traffic shunted off to a separate queue(s).
Would you be willing to float that infront of them? We have
discussed this internal between Jonothan, Pete and myself,
it is a viable solution. And iirc our discussion resulted in
this ECT(0) being used to signal ECT or SCE treatment to be
rather low risk.
Right now any time we (SCE) try to float anything its shot down without
any due consideration or discussion, sadly.
> Regards,
> // Steve
--
Rod Grimes rgrimes@freebsd.org
next prev parent reply other threads:[~2021-03-09 18:07 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
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 [this message]
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=202103091807.129I7LYx078190@gndrsh.dnsmgr.net \
--to=4bone@gndrsh.dnsmgr.net \
--cc=chromatix99@gmail.com \
--cc=ecn-sane@lists.bufferbloat.net \
--cc=slblake@petri-meat.com \
/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