Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: moeller0 <moeller0@gmx.de>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Andrew McGregor <andrewmcgr@gmail.com>,
	cake@lists.bufferbloat.net,
	"codel@lists.bufferbloat.net" <codel@lists.bufferbloat.net>
Subject: Re: [Cake] [Codel]  Proposing COBALT
Date: Sat, 4 Jun 2016 17:03:08 +0200	[thread overview]
Message-ID: <F3DA036A-66E7-44AB-AEF4-BA61E9117FDC@gmx.de> (raw)
In-Reply-To: <0CB3F4FC-5AC2-4B13-8CC5-B6593AAEBD6E@gmail.com>

Hi Jonathan,


> On Jun 4, 2016, at 16:16 , Jonathan Morton <chromatix99@gmail.com> wrote:
> 
> 
>> On 4 Jun, 2016, at 17:01, moeller0 <moeller0@gmx.de> wrote:
>> 
>> Maybe cake should allow to switch from the default mark by ECN policy to mark by drop per command line argument? At least that would allow much easier in the field testing… As is there is only the option of disabling ECN at the endpoint(s)…
> 
> I consider ignoring ECN in the way I described to be a fault condition inevitably resulting in unresponsive traffic.  As a fault condition, it should be rare.

	Operative word being “should” in my opinion; as long as we have no reliable statistics either way, assuming rarity seems overly optimistic to me. Not giving the user control over policy requires the default policy to be almost 100% applicable., here we have a demonstrated case where this requirement seems violated. Make out of that what you want, if cake were my project I would make ECN versus drop configurable at the qdisc, as the control via the endhosts seems comparatively tedious, especially for quick comparative testing. But cake is not my project, so all I can do is try to make a case for introducing a policy control toggle…

> 
> The main effect in practice is that the RTT for the affected flows grows well beyond normal, but since they are bulk transfers,
> this has only a minor detrimental effect (much of which is incurred sender-side in the form of retransmission buffers two orders of magnitude larger than necessary).
> 
> Rather than further complicate Codel or Cake, I’d like to simply apply a general solution for unresponsive traffic, ie. COBALT.

	If adding a toggle for ECN versus drop is your only concern in the complexity of cake’s configuration you have not been reading my arguments regarding the labyrinthian overhead keywords… Really not exposing this control for this might actually be a reasonable thing to do, but trying to “blame” this on added complexity seems far fetched… but what do I know…

Best Regards
	Sebastian

> 
> - Jonathan Mortob
> 


  reply	other threads:[~2016-06-04 15:03 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-20 10:04 [Cake] " Jonathan Morton
2016-05-20 11:37 ` 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
2016-05-20 16:37         ` Luis E. Garcia
2016-05-20 16:43           ` Jonathan Morton
2016-05-20 16:55             ` Luis E. Garcia
2016-05-23 18:30             ` Jonathan Morton
2016-05-23 19:11               ` Luis E. Garcia
2016-05-24 13:47               ` [Cake] [Codel] " 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-25  6:40                         ` Loganaden Velvindron
2016-05-25 12:00                         ` Benjamin Cronce
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                                 ` Vincent Frentzel
2016-06-04 14:16                                 ` Jonathan Morton
2016-06-04 15:03                                   ` moeller0 [this message]
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
2016-06-27  7:59                                       ` moeller0
2016-06-27 15:18                                       ` Kevin Darbyshire-Bryant
2016-06-28  2:51                                         ` Jonathan Morton
2016-06-28  8:40                                           ` Kevin Darbyshire-Bryant
2016-06-28 15:33                                             ` Jonathan Morton
2016-06-28 17:37                                               ` Kevin Darbyshire-Bryant
2016-06-29 15:22                                                 ` Kevin Darbyshire-Bryant
2016-06-30  8:16                                                   ` Kevin Darbyshire-Bryant
2016-06-28 15:44                                             ` Dave Taht
2016-05-20 13:41     ` [Cake] " David Lang
2016-05-20 13:46       ` moeller0
2016-05-20 14:04         ` David Lang
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             ` [Cake] [Codel] " 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       ` [Cake] " 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/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=F3DA036A-66E7-44AB-AEF4-BA61E9117FDC@gmx.de \
    --to=moeller0@gmx.de \
    --cc=andrewmcgr@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=chromatix99@gmail.com \
    --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