From: Jonathan Morton <chromatix99@gmail.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] CDG
Date: Fri, 29 May 2015 11:35:02 +0300 [thread overview]
Message-ID: <5315D91E-AEE5-4782-A83F-37D48C749AD9@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1505261328290.9487@uplift.swm.pp.se>
> On 26 May, 2015, at 14:31, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
>
> I just read https://lwn.net/Articles/645115/ about CDG congestion control.
>
> After reading the article, I am left wondering how this kind of congestion control mechanisms handles being exposed to a token bucket policer:
>
> http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-policing/19645-policevsshape.html
>
> With this kind of rate limiting, there is never any buffering or increase in latency, you're only seeing packet drops, no other congestion signal.
>
> Anyone have any insight?
It doesn’t have to be a policer - most properly-configured AQMs also start to mark or drop packets before significant extra delay can be measured by the endpoints, which is why LEDBAT behaves like a conventional TCP under AQM. I would hope that CDG responds appropriately to ECN marks, even if it assumes packet loss might not be congestion-related.
I happen to believe that the ultimate goal of zero induced delay can *only* be achieved using a combination of network and endpoint intelligence, not one or the other alone. Lots of work has been done so far on endpoint intelligence, using the assumption that the network uses only dumb FIFOs (which is, at present, a reasonable observation). CDG is merely another example of this.
- Jonathan Morton
next prev parent reply other threads:[~2015-05-29 8:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-26 11:31 Mikael Abrahamsson
2015-05-29 8:35 ` Jonathan Morton [this message]
2015-05-29 12:43 ` Bill Ver Steeg (versteb)
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/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5315D91E-AEE5-4782-A83F-37D48C749AD9@gmail.com \
--to=chromatix99@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=swmike@swm.pp.se \
/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