From: Jonathan Morton <chromatix99@gmail.com>
To: moeller0 <moeller0@gmx.de>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] triple flow isolation
Date: Mon, 18 Jan 2016 11:37:35 +0200 [thread overview]
Message-ID: <72B1E8E5-F42D-4B13-A404-5DE82F8658F9@gmail.com> (raw)
In-Reply-To: <079A86FB-D2A6-4787-BC42-D2E200AD3290@gmx.de>
> On 18 Jan, 2016, at 11:21, moeller0 <moeller0@gmx.de> wrote:
>
> Am I right to assume that dust and src host isolation works with the same counters but simply ignores one of them?
Yes. That’s explicit in the code.
> So if all internal hosts talk to one external host, does this scheme then equal pure per-flow fairness? I am trying to understand how robust triple-iso is going to be against attempt at shenanigans by unruly machines on the internal/external networks…
No. If there is only one host on one side (whichever side that happens to be), then maintaining per-host fairness for that side is trivial. The algorithm will instead maintain per-host fairness for the other side. This derives from the fact that it also maintains per-host fairness within traffic to each individual host. Per-flow fairness is also still maintained within individual host-pairs.
My measurements show that this aspect of the isolation is not perfect. There is still some influence from the number of flows, which biases the actual throughput slightly from ideal per-host fairness. This bias is however *much* smaller than pure per-flow fairness would be, and I’ve been unable to come up with a robust way of eliminating it entirely.
Hence I think it’s reasonable to simply switch on triple isolation by default, in the near future. It does approximately the right thing, without further configuration, in the great majority of practical cases (that I can think of), and to a greater extent than the existing “flows” mode does.
I think that might also be a good time to overhaul the documentation and do some other overdue cleanup.
- Jonathan Morton
next prev parent reply other threads:[~2016-01-18 9:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-11 17:40 Kevin Darbyshire-Bryant
2016-01-11 18:16 ` moeller0
2016-01-11 20:33 ` Kevin Darbyshire-Bryant
2016-01-14 14:20 ` moeller0
2016-01-14 14:45 ` Jonathan Morton
2016-01-14 15:48 ` moeller0
2016-01-14 16:05 ` Jonathan Morton
[not found] ` <02A10F37-145C-4BF9-B428-BC1BDF700135@gmx.de>
2016-01-15 0:05 ` Jonathan Morton
2016-01-15 8:05 ` moeller0
2016-01-16 9:05 ` Jonathan Morton
2016-01-16 9:35 ` Jonathan Morton
2016-01-17 22:22 ` moeller0
2016-01-18 9:21 ` moeller0
2016-01-18 9:37 ` Jonathan Morton [this message]
2016-01-18 11:08 ` Alan Jenkins
2016-01-18 11:39 ` Jonathan Morton
2016-01-18 16:20 ` Sebastian Moeller
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=72B1E8E5-F42D-4B13-A404-5DE82F8658F9@gmail.com \
--to=chromatix99@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