CoDel AQM discussions
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: cake@lists.bufferbloat.net,
	"codel@lists.bufferbloat.net" <codel@lists.bufferbloat.net>
Subject: Re: [Codel] [Cake] Proposing COBALT
Date: Mon, 27 Jun 2016 06:56:44 +0300	[thread overview]
Message-ID: <6FC1BE74-748D-41C0-A80F-CE2111F20FA8@gmail.com> (raw)
In-Reply-To: <C0753764-94B5-47DB-9ECC-06FBF6F272DA@gmail.com>


> On 4 Jun, 2016, at 22:55, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
> COBALT should turn out to be a reasonable antidote to sender-side cheating, due to the way BLUE works; the drop probability remains steady until the queue has completely emptied, and then decays slowly.  Assuming the congestion-control response to packet drops is normal, BLUE should find a stable operating point where the queue is kept partly full on average.  The resulting packet loss will be higher than for a dumb FIFO or a naive ECN AQM, but lower than for a loss-based AQM with a tight sojourn-time target.
> 
> For this reason, I’m putting off drafting such an explanation to Valve until I have a chance to evaluate COBALT’s performance against the faulty traffic.

The COBALTified Cake is now working quite nicely, after I located and excised some annoying lockup bugs.  As a side-effect of these fixes (which introduced a third, lightly-serviced flowchain for “decaying flows”, which are counted as “sparse” in the stats report), the sparse and bulk flow counts should be somewhat less jittery and more useful.

I replaced the defunct “last_len” stat with a new “un_flows”, meaning “unresponsive flows”, to indicate when the BLUE part of COBALT is active.  This lights up nicely when passing Steam traffic, which no longer has anywhere near as detrimental effect on my Internet connection as it did with only Codel; this indicates that BLUE’s ECN-blind dropping is successfully keeping the upstream queue empty.  (Of course it wouldn’t help against a UDP flood, but nothing can do that in this topology.)

While working on this, I also noticed that the triple-isolation logic is probably quite CPU-intensive.  It should be feasible to do better, so I’ll have a go at that soon.  Also on the to-do list is enhancing the overhead logic with new data, and adding a three-class Diffserv mode which Dave has wanted for a while.

I’ve also come up with a tentative experimental setup to test the “85% rule” more robustly than the Chinese paper found recently.  I should be able to do it wth just three hosts, one having dual NICs, and using only Cake and netem qdiscs.

Now if only the sauna were not the *coolest* part of my residence right now…

 - Jonathan Morton


  parent reply	other threads:[~2016-06-27  3:56 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-20 10:04 [Codel] " Jonathan Morton
2016-05-20 11:37 ` [Codel] [Cake] " moeller0
2016-05-20 12:18   ` Jonathan Morton
2016-05-20 13:22     ` moeller0
2016-05-20 14:36       ` Jonathan Morton
2016-05-20 16:03         ` David Lang
2016-05-20 17:31           ` Jonathan Morton
     [not found]         ` <CALnBQ5mNgHgFoTcvLxppv2P9XODc4D-4NObKyqbZJ0PccVkwiA@mail.gmail.com>
2016-05-20 16:43           ` Jonathan Morton
2016-05-23 18:30             ` Jonathan Morton
2016-05-24 13:47               ` Jeff Weeks
2016-05-24 14:07                 ` Jonathan Morton
2016-05-24 15:52                   ` Dave Täht
2016-05-24 15:56                     ` Jonathan Morton
2016-05-24 16:02                       ` Dave Taht
2016-05-26 12:33                     ` Jonathan Morton
2016-06-03 19:09                       ` Noah Causin
2016-06-03 19:34                         ` Jonathan Morton
2016-06-04  1:01                           ` Andrew McGregor
2016-06-04  6:23                             ` Jonathan Morton
2016-06-04 13:55                             ` Jonathan Morton
2016-06-04 14:01                               ` moeller0
2016-06-04 14:16                                 ` Jonathan Morton
2016-06-04 15:03                                   ` moeller0
2016-06-04 17:10                               ` Noah Causin
2016-06-04 17:49                                 ` Eric Dumazet
2016-06-04 19:55                                   ` Jonathan Morton
2016-06-04 20:56                                     ` Eric Dumazet
2016-06-27  3:56                                     ` Jonathan Morton [this message]
2016-06-27  7:59                                       ` moeller0
2016-05-20 13:41     ` David Lang
2016-05-20 13:46       ` moeller0
2016-05-20 14:04         ` David Lang
2016-05-20 14:42           ` Kathleen Nichols
2016-05-20 15:11             ` Jonathan Morton
2016-05-20 15:12           ` Jonathan Morton
2016-05-20 16:05             ` David Lang
2016-05-20 17:06               ` Jonathan Morton
2016-05-20 16:20             ` Rick Jones
2016-05-20 16:35               ` Jonathan Morton
2016-05-20 17:01                 ` Rick Jones
2016-05-20 17:07                   ` Jonathan Morton
2016-05-20 17:21                     ` Rick Jones
2016-05-20 17:26                     ` David Lang
2016-05-20 17:33                       ` Jonathan Morton
2016-05-20 14:09       ` 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/codel.lists.bufferbloat.net/

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

  git send-email \
    --in-reply-to=6FC1BE74-748D-41C0-A80F-CE2111F20FA8@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=codel@lists.bufferbloat.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