From: Jonathan Morton <chromatix99@gmail.com>
To: Ruediger.Geib@telekom.de
Cc: swmike@swm.pp.se, tcpm@ietf.org, ecn-sane@lists.bufferbloat.net,
tsvwg@ietf.org
Subject: Re: [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S
Date: Tue, 6 Aug 2019 18:27:57 +0300 [thread overview]
Message-ID: <ED78E4C4-D86F-4068-99C4-7F98D88FB481@gmail.com> (raw)
In-Reply-To: <LEXPR01MB04633F2E6945D6AAE9D4F18B9CD50@LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE>
> On 6 Aug, 2019, at 5:34 pm, <Ruediger.Geib@telekom.de> <Ruediger.Geib@telekom.de> wrote:
>
> Public peerings and not well dimensioned networks may suffer from regular congestion. I'm not sure to which extent technical standards can significantly improve service quality in that situation. IP transport must work as good as possible also in such a situation, of course.
Obviously the application of AQM will not magically improve total throughput. What it can do, however, is reduce latency and packet loss, and thereby improve perceived reliability of the service. It may even improve goodput for the same throughput - an increase in efficiency.
This is especially true under emergency overload conditions, which is when people most desperately want a functioning network, but it is most likely to collapse under the strain. Often a disaster will incidentally knock out some proportion of network infrastructure in the area, turning a previously well-proportioned network into an under-proportioned one, simultaneously with a sharp increase in demand as people try to find out what is going on or communicate with friends and relatives, and emergency response teams also try to coordinate their essential work.
So IMO networks should be designed to work well when congested, even when they are also designed to never *be* congested. Technical specifications already exist and are well tested for this purpose. Having them built in and turned on from the factory would be a great step forward.
- Jonathan Morton
next prev parent reply other threads:[~2019-08-06 15:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-13 16:48 [Ecn-sane] " Bob Briscoe
2019-07-09 14:41 ` [Ecn-sane] [tsvwg] " Black, David
2019-07-09 15:32 ` [Ecn-sane] [tcpm] " Neal Cardwell
2019-07-09 15:41 ` [Ecn-sane] " Jonathan Morton
2019-07-09 23:08 ` [Ecn-sane] [tsvwg] " Yuchung Cheng
2019-08-02 8:29 ` Ruediger.Geib
2019-08-02 9:47 ` Jonathan Morton
2019-08-02 11:10 ` Dave Taht
2019-08-02 12:05 ` Dave Taht
2019-08-05 9:35 ` Ruediger.Geib
2019-08-05 10:59 ` Jonathan Morton
2019-08-05 12:16 ` Ruediger.Geib
2019-08-05 15:55 ` Jonathan Morton
2019-08-02 13:15 ` Sebastian Moeller
2019-08-05 7:26 ` Ruediger.Geib
2019-08-05 11:00 ` Sebastian Moeller
2019-08-05 11:47 ` Ruediger.Geib
2019-08-05 13:47 ` Sebastian Moeller
2019-08-06 9:49 ` Mikael Abrahamsson
2019-08-06 14:34 ` Ruediger.Geib
2019-08-06 15:27 ` Jonathan Morton [this message]
2019-08-06 15:35 ` Dave Taht
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=ED78E4C4-D86F-4068-99C4-7F98D88FB481@gmail.com \
--to=chromatix99@gmail.com \
--cc=Ruediger.Geib@telekom.de \
--cc=ecn-sane@lists.bufferbloat.net \
--cc=swmike@swm.pp.se \
--cc=tcpm@ietf.org \
--cc=tsvwg@ietf.org \
/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