[Cake] Christmas Cake

[Cake] Christmas Cake

[Jonathan Morton]

With spectacularly good timing, I’ve finally worked out the last kinks of how to make the triple-solation scheme work in practice.  Or at least I hope I have - it still needs concrete testing.  At least my PowerBook didn’t blow up when I started running it, so it’s probably safe to deploy straight away.

So that’s the big update I put in last night.

I also made a couple of small but significant tweaks to the Codel implementation, bringing it closer to the published ideal behaviour. This seems to have improved my own connection under heavy ingress load, so it’s probably on the right track.

It no longer attempts to vary the trigger point based on queue growth speed, but it *will* now trigger instantly if an entire interval’s worth of traffic arrives in one queue all at once.  The inverse-square-root calculation is also now performed to 32-bit precision, matching the range of the count variable and possibly saving some instructions in the process.

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.

Merry Christmas...

 - Jonathan Morton

Re: [Cake] Christmas Cake

[moeller0]

Hi Jonathan,

> On Dec 23, 2015, at 07:28 , Jonathan Morton <chromatix99@gmail.com> wrote:
> 
> With spectacularly good timing, I’ve finally worked out the last kinks of how to make the triple-solation scheme work in practice.  Or at least I hope I have - it still needs concrete testing.  At least my PowerBook didn’t blow up when I started running it, so it’s probably safe to deploy straight away.
> 
> So that’s the big update I put in last night.
> 
> I also made a couple of small but significant tweaks to the Codel implementation, bringing it closer to the published ideal behaviour. This seems to have improved my own connection under heavy ingress load, so it’s probably on the right track.
> 
> It no longer attempts to vary the trigger point based on queue growth speed, but it *will* now trigger instantly if an entire interval’s worth of traffic arrives in one queue all at once.  The inverse-square-root calculation is also now performed to 32-bit precision, matching the range of the count variable and possibly saving some instructions in the process.
> 
> 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. (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?

Best Regards
        M.


> 
> Merry Christmas...
> 
> - Jonathan Morton
> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] Christmas Cake

[moeller0]

Hi Jonathan,


> On Dec 23, 2015, at 11:01 , moeller0 <moeller0@gmx.de> wrote:
> 
> Hi Jonathan,
> 
>> On Dec 23, 2015, at 07:28 , Jonathan Morton <chromatix99@gmail.com> wrote:
>> 
>> With spectacularly good timing, I’ve finally worked out the last kinks of how to make the triple-solation scheme work in practice.  Or at least I hope I have - it still needs concrete testing.  At least my PowerBook didn’t blow up when I started running it, so it’s probably safe to deploy straight away.
>> 
>> So that’s the big update I put in last night.
>> 
>> I also made a couple of small but significant tweaks to the Codel implementation, bringing it closer to the published ideal behaviour. This seems to have improved my own connection under heavy ingress load, so it’s probably on the right track.
>> 
>> It no longer attempts to vary the trigger point based on queue growth speed, but it *will* now trigger instantly if an entire interval’s worth of traffic arrives in one queue all at once.  The inverse-square-root calculation is also now performed to 32-bit precision, matching the range of the count variable and possibly saving some instructions in the process.
>> 
>> 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 hot’s bandwidth share.


> (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?
> 
> Best Regards
>        M.
> 
> 
>> 
>> Merry Christmas...
>> 
>> - Jonathan Morton
>> 
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] Christmas Cake

[Jonathan Morton]

>>> 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