From: Jonathan Morton <chromatix99@gmail.com>
To: "Holland, Jake" <jholland@akamai.com>
Cc: Dave Taht <dave.taht@gmail.com>, Pete Heist <pete@heistp.net>,
ECN-Sane <ecn-sane@lists.bufferbloat.net>
Subject: Re: [Ecn-sane] IETF 110 quick summary
Date: Tue, 9 Mar 2021 13:06:27 +0200 [thread overview]
Message-ID: <85081354-5D98-4EDF-8849-51F237F36252@gmail.com> (raw)
In-Reply-To: <FC045DF9-8AB7-4371-9B54-0C89BC3CB291@akamai.com>
> On 9 Mar, 2021, at 4:13 am, Holland, Jake <jholland@akamai.com> wrote:
>
> In the chat a person or 2 was surprised about the way
> L4S will impact NECT competing traffic when competing in a queue.
I think that was mostly Martin Duke. I caught up with him in the IETF Gather space immediately afterwards and discussed this with him, one to one, and he now seems to understand more clearly what we were presenting. I was pleased to hear that he's also familiar with the "risk matrix" formulation I presented.
> We also applied that to L4S by first explaining that risk is the
> product of severity and prevalence…
And also, crucially, the concept of "externalised risk", ie. the distinction between involved participants, interested observers, and innocent bystanders. L4S has innocent bystanders (existing networks and their users, who have no idea that L4S even exists nor how to troubleshoot ECN related problems) incur most of the risk of Bad Things happening. This is an "externalised risk" which is very difficult to manage after the fact, and must be minimised to a much greater extent than other risks.
SCE ensures that innocent bystanders incur virtually no risk, in that bad interactions only occur for poeple actually using SCE over an SCE-enabled path, which is where mitigations can actually be practical to employ - in the limit, by switching off SCE. This is much easier to accept in a risk analysis. We didn't get to that slide, however, due to shortage of time.
- Jonathan Morton
next prev parent reply other threads:[~2021-03-09 11:06 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
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 [this message]
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=85081354-5D98-4EDF-8849-51F237F36252@gmail.com \
--to=chromatix99@gmail.com \
--cc=dave.taht@gmail.com \
--cc=ecn-sane@lists.bufferbloat.net \
--cc=jholland@akamai.com \
--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