Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Benjamin Cronce <bcronce@gmail.com>
Cc: Sebastian Moeller <moeller0@gmx.de>, cake@lists.bufferbloat.net
Subject: Re: [Cake] upstreaming cake in 2017?
Date: Sat, 24 Dec 2016 19:22:43 +0200	[thread overview]
Message-ID: <76C6FEF2-4939-4601-9F78-43B3077C39E4@gmail.com> (raw)
In-Reply-To: <CAJ_ENFHKOSOf2gFzJjJHntz_tbrA4vFF84KABb6_S5yWu3Ob+A@mail.gmail.com>


> On 24 Dec, 2016, at 17:55, Benjamin Cronce <bcronce@gmail.com> wrote:
> 
> What was also interesting is the flows consuming the majority of the buffer were always in flux. You would think the same few flows that were consuming the buffer at one moment would continue to, but that is not the case, TCP keeps them alternating.

That sounds like the links are not actually congested on average, and the flows which temporarily collect in the buffer are due to transitory bursts - which is what you’d expect from a competently-managed backbone.  A flow-isolating AQM doesn’t really help there, though Cake should be capable of scaling up to 10Gbps on a modern CPU.

Conversely, there have been well-publicised instances of congestion at peering points, which have had substantial impacts on performance.  I imagine the relevant flow counts there would be very much higher, definitely in the thousands.  Even well-managed networks occasionally experience congestion due to exceptional loads.

The workings of DRR++ are also somewhat more subtle than simply counting the flows instantaneously in the buffer.  Each queue has a deficit, and in Cake an empty queue is not normally released from tracking a particular flow until the deficit has been repaid (by cycling through all the other flows and probably servicing them) and decaying the AQM state to rest, which may often take long enough for another packet to arrive for that flow.

The number of active bulk flows can therefore exceed the number of packets actually in the queue.  This is especially true if the AQM is working optimally and keeping the queue almost empty on average.

While fq_codel does not explicitly assign queues to specific flows (ie. to avoid hash collisions), the effects of hash collisions are similarly felt under the same circumstances, resulting in the colliding flows failing to receive their theoretical fair share of the link, even if they never have packets physically in the queue at the same time.

With that said, both fq_codel and Cake should work okay with statistical multiplexing to handle exceptional flow counts.  In such cases, Cake’s triple-isolate feature should be turned off, by selecting either “hosts” or “flows” modes.  I could run an analysis to show how even the multiplexing should be.

 - Jonathan Morton


  reply	other threads:[~2016-12-24 17:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-22 19:43 Dave Taht
2016-12-22 20:02 ` Sebastian Moeller
2016-12-23  1:43   ` Stephen Hemminger
2016-12-23  3:44     ` Jonathan Morton
2016-12-23  8:42       ` Sebastian Moeller
2016-12-23  9:53         ` Jonathan Morton
2016-12-23 12:40           ` Sebastian Moeller
2016-12-23 14:06             ` Jonathan Morton
2016-12-23 16:24               ` Sebastian Moeller
2016-12-23 17:01                 ` Dave Taht
2016-12-24 15:55           ` Benjamin Cronce
2016-12-24 17:22             ` Jonathan Morton [this message]
2016-12-24 21:15               ` Benjamin Cronce
2016-12-30  7:42 ` Y

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/cake.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=76C6FEF2-4939-4601-9F78-43B3077C39E4@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=bcronce@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=moeller0@gmx.de \
    /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