Discussion of explicit congestion notification's impact on the Internet
 help / color / mirror / Atom feed
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
To: "David P. Reed" <dpreed@deepplum.com>,
	Sebastian Moeller <moeller0@gmx.de>
Cc: "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>,
	tsvwg IETF list <tsvwg@ietf.org>
Subject: Re: [Ecn-sane] [tsvwg]  per-flow scheduling
Date: Thu, 27 Jun 2019 09:53:39 +0200	[thread overview]
Message-ID: <a52d0a9f-9652-705a-babe-441f93532845@kit.edu> (raw)
In-Reply-To: <1561566706.778820831@apps.rackspace.com>

Hi,

Am 26.06.19 um 18:31 schrieb David P. Reed:

> The idea that "link utilization" of 100% must be achieved is why we got
> bufferbloat designed into routers. It's a worm's eye perspective. To

You are right, but IMHO it is even worse, because it is an
artefact of the particular loss-based TCP congestion control
as it was designed and the correspondingly derived "BDP buffer size"
rule. The loss-based AIMD congestion control is able to keep up the
utilization then, because it uses the systematically built standing
queue during its back-off after a packet loss. That essentially keeps
the sending rate at the same level. However, now we know that avoiding
queuing delay is important, we can also design better congestion
controls that do not fill the available buffer capacity up to exhaustion
and that do not require standing queues to keep up link utilization.

However, as you also wrote, the positive and negative effects of
existing buffers depend a lot on the particular traffic pattern and this
has also changed much during the last decades. So I think that revising
the "buffer size" discussion could be useful...

Aside from that I find the SCE proposal very useful, because it allows
to provide an additional level of congestion signalling that could
be used by various congestion control schemes.

Regards,
 Roland


  parent reply	other threads:[~2019-06-27  7:53 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-19 14:12 [Ecn-sane] " Bob Briscoe
2019-06-19 14:20 ` [Ecn-sane] [tsvwg] " Kyle Rose
2019-06-21  6:59 ` [Ecn-sane] " Sebastian Moeller
2019-06-21  9:33   ` Luca Muscariello
2019-06-21 20:37     ` [Ecn-sane] [tsvwg] " Brian E Carpenter
2019-06-22 19:50       ` David P. Reed
2019-06-22 20:47         ` Jonathan Morton
2019-06-22 22:03           ` Luca Muscariello
2019-06-22 22:09           ` David P. Reed
2019-06-22 23:07             ` Jonathan Morton
2019-06-24 18:57               ` David P. Reed
2019-06-24 19:31                 ` Jonathan Morton
2019-06-24 19:50                   ` David P. Reed
2019-06-24 20:14                     ` Jonathan Morton
2019-06-25 21:05                       ` David P. Reed
2019-06-24 21:25                   ` Luca Muscariello
2019-06-26 12:48             ` Sebastian Moeller
2019-06-26 16:31               ` David P. Reed
2019-06-26 16:53                 ` David P. Reed
2019-06-27  7:54                   ` Sebastian Moeller
2019-06-27  7:49                 ` Sebastian Moeller
2019-06-27 20:33                   ` Brian E Carpenter
2019-06-27 21:31                     ` David P. Reed
2019-06-28  7:49                       ` Toke Høiland-Jørgensen
2019-06-27  7:53                 ` Bless, Roland (TM) [this message]
2019-06-22 21:10         ` Brian E Carpenter
2019-06-22 22:25           ` David P. Reed
2019-06-22 22:30             ` Luca Muscariello
2019-07-17 21:33 ` [Ecn-sane] " Sebastian Moeller
2019-07-17 22:18   ` David P. Reed
2019-07-17 22:34     ` David P. Reed
2019-07-17 23:23       ` Dave Taht
2019-07-18  0:20         ` Dave Taht
2019-07-18  5:30           ` Jonathan Morton
2019-07-18 15:02         ` David P. Reed
2019-07-18 16:06           ` Dave Taht
2019-07-18  4:31     ` Jonathan Morton
2019-07-18 15:52       ` David P. Reed
2019-07-18 18:12         ` [Ecn-sane] [tsvwg] " Dave Taht
2019-07-18  5:24     ` [Ecn-sane] " Jonathan Morton
2019-07-22 13:44       ` Bob Briscoe
2019-07-23  5:00         ` Jonathan Morton
2019-07-23 11:35           ` [Ecn-sane] CNQ cheap-nasty-queuing (was per-flow queuing) Luca Muscariello
2019-07-23 20:14           ` [Ecn-sane] per-flow scheduling Bob Briscoe
2019-07-23 22:24             ` Jonathan Morton
2019-07-23 15:12         ` [Ecn-sane] [tsvwg] " Kyle Rose
2019-07-25 19:25           ` Holland, Jake
2019-07-27 15:35             ` Kyle Rose
2019-07-27 19:42               ` Jonathan Morton

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=a52d0a9f-9652-705a-babe-441f93532845@kit.edu \
    --to=roland.bless@kit.edu \
    --cc=dpreed@deepplum.com \
    --cc=ecn-sane@lists.bufferbloat.net \
    --cc=moeller0@gmx.de \
    --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