From: moeller0 <moeller0@gmx.de>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] triple flow isolation
Date: Fri, 15 Jan 2016 09:05:34 +0100 [thread overview]
Message-ID: <E77CBA91-E26B-49EC-8E15-46E515B6096F@gmx.de> (raw)
In-Reply-To: <ACADD503-6BB1-4218-9DB7-5DC3C7B03A37@gmail.com>
Hi Jonathan,
> On Jan 15, 2016, at 01:05 , Jonathan Morton <chromatix99@gmail.com> wrote:
>
>
>> On 14 Jan, 2016, at 20:53, moeller0 <moeller0@gmx.de> wrote:
>>
>> So I have not grokked the triple algorithm fully (aka not at all), but I already know that what user’s are looking for is fairness by internal host IPs. Now, since as I explained before ingress and egress really are too flexible to use as direction pointers, I assume we are looking for some configuration parameter that contains a direction; so as long as “triple” allows to request fairness by source IP or by destination IP (since these might change depending on the interface cake is running on) all will be fine. I just do not see how a simple unidirectional parameter like “triple-iso” will allow to take the fact into account that ingress and egress are only relative to the sqm interface and do not necessarily align with the internal/WAN ingress and egress… But as I said before I do not claim I understand what triple-iso intends to accomplish in detail.
>
> The short version is that, in theory at least, I’ve found a way to ensure fairness without needing to know which side of the interface is which.
Could you please explain the fairness you are talking about here? I still want to test cake in my environment and will do a much better job if I know what behavior to expect, and frankly I am unsure what triple-iso is supposed to guarantee (I know this is my own responsibility, but getting a high level description seems more efficient than trying to deduce this from the implementation, especially given that you are not fully satisfied withe the current implementation). Thanks in advance.
> By accounting for *both* source and destination host fairness at the same time, and not placing one above the other in importance, it should all work out in the end. The method by which I do so is probably interesting enough to write a paper about, once I’ve got it working in practice.
>
> At this point, I strongly suspect I’ve made an implementation blunder, since even single-stepping through the theoretical algorithm’s behaviour, packet by packet, produces approximately the desired results - which are however not reproduced in actual measurements on my LAN. Time to add more stats to the multitude already present!
>
> If you want to be explicit about directionality, that’s what the two new “dual” modes are for. The “triple isolation” algorithm is still used, but the undesired attribute is ignored. The “triple” mode combines their effects.
This is the part I can not get my head around: fairness by internal host IP (what people seem to request, with, as you alluded to before, DSCP tiers per internal host IP and per flow fairness in each tier) basically will not generally allow fairness by external IP. E.g. three internal hosts talk to 6 external hosts, fairness by internal IP will try to give 1/3 of the bandwidth to the internal hosts, fairness by external IP will give 1/6, now unless the connections are symmetric (each internal IP talks to the same number of external IPs) the actual bandwidth distribution will deviate from either 1/3 or 1/6, so what level of fairness will triple-iso aim for? With explicit directionality I can easily see how to enforce either 1/3 or 1/6 in the example...
Best Regards
Sebastian
>
> - Jonathan Morton
>
next prev parent reply other threads:[~2016-01-15 8:05 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 [this message]
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
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=E77CBA91-E26B-49EC-8E15-46E515B6096F@gmx.de \
--to=moeller0@gmx.de \
--cc=cake@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
/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