Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: moeller0 <moeller0@gmx.de>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] Christmas Cake
Date: Wed, 23 Dec 2015 13:59:26 +0200	[thread overview]
Message-ID: <47F36AAA-54E7-490D-B92C-8D6B934BE506@gmail.com> (raw)
In-Reply-To: <53905DAE-AEBB-42BA-9B87-2E58222D05EB@gmx.de>

>>> I’d like to see the results of testing the new “triple-isolation” flag.  It should pass all tests involving one host-pair just as well as “flows” does.  Additionally, it should share bandwidth fairly between multiple hosts on either side of the link, regardless of any imbalance in the number of flows involved.  For example, one flow between A and B, two flows between C and D, where both paths pass through the same Cake instance, should result in each of C-D’s flows receiving half the throughput of the A-B one.
>> 
>> Interesting, now I have a question (since reading the code only gets my that far), the typical scenario people want is basically to enforce per source host fairness on egress and per destination-host fairness on ingress, because in a torrent swarm as far as I can see there will not be multiple flows between internal_C and external_D, but rather between internal_C and external_ALPHABET. And the stated goal often seems to be fairness per internal host address.
> 
> To add to myself, multiple internal hosts accessing the same external host should result in each flow using up to each host’s bandwidth share.

The test I outlined is only the simplest and most obvious one.  Since I haven’t run any serious, lab-style tests myself yet, I thought it best to start simple.

>> (In your description it is unclear what happens if internal C started also talking to external E, will this increase C’s share of bandwidth or not and what will be the bandwidth ratio of C2E as compared to the C2D aggregate?)
>> 
>> Which of the three options will handle that well dual-X or triple-iso?

I intend the same per-host sharing to occur when the test is repeated with A and C being the same host, and again when B and D are the same host, but not both at the same time, obviously.

The difference between dual-srchost, dual-dsthost and triple-isolate is whether only one of these additional scenarios works, or both of them, ie. dual-srchost ignores destination addresses for host-fairness purposes (but not basic flow-isolation).

The situation where A and C are also both talking to E is an interesting one, especially since it can easily arise if E is, say, Steam or Windows Update or suchlike (given some simplifying assumptions).  The desired results in “dual” mode are hopefully obvious, whichever way around you configure it; one way, the aggregate bandwidth of A and C will be equalised, while the other way, B, D and E will be equalised, with A and C’s shares of E depending on the relative number of flows involved.

But what happens in triple mode?

I think what triple mode will do with that situation is to equalise B, D and E in aggregate, and further will equalise A and C’s shares of E, regardless of relative flow counts.  At least, that’s what it’s designed to do.

All the above assumes that all this traffic is in the same priority class (or that “besteffort” mode is in use) and is saturating.  Cake’s behaviour gets difficult to describe concisely in other cases, but should be intuitively reasonable.

There are other possible topologies, of course, but I think the above are the interesting ones to test for now.  It’s entirely likely that some tweaking is still required, so I would appreciate whatever help is forthcoming in setting up robust tests along those lines.

 - Jonathan Morton


      reply	other threads:[~2015-12-23 11:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-23  6:28 Jonathan Morton
2015-12-23 10:01 ` moeller0
2015-12-23 10:31   ` moeller0
2015-12-23 11:59     ` Jonathan Morton [this message]

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=47F36AAA-54E7-490D-B92C-8D6B934BE506@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