[Cake] Bandwidith rate by host instead of global while using [dual-]srchost and [dual-]dsthost

Dave Taht dave.taht at gmail.com
Mon Jun 11 16:17:19 EDT 2018


On Mon, Jun 11, 2018 at 12:54 PM, Stephen Hemminger
<stephen at networkplumber.org> wrote:
> On Mon, 11 Jun 2018 21:44:25 +0200
> Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>
>> Michel Blais <michel at targointernet.com> writes:
>>
>> > Hi all,
>> >
>> > Is it possible while using srchost, or dual-srchost, and dsthost, or
>> > dual-dsthost, to do a bandwidth limitation by host instead of global ? From
>> > what I read, seem like not.
>>
>> No, not currently (as Dave said). I do believe it would be possible to
>> extend the current architecture to support this, though. Basically,
>> making the number of tins configurable to an arbitrary number and making
>> it possible to set individual bandwidths on them should do the trick. A
>> TC filter could then be used to assign traffic to the right tin based on
>> whatever information is available.
>>
>> However, I don't think the current way of finding the next tin to
>> service is going to scale to an arbitrary number of tins, so this
>> probably needs to be changed before such a configuration is really
>> feasible...
>>
>> -Toke
>
> Making cake into a version of HTB is not necessarily a good idea

Not the plan. But arguably, we'd need a list of requirements from a
major head-end
vendor or DPI co (like sandvine) to even try to address the ISP side
of the universe.

I long ago ran out of motivation and money to continue working on
bufferbloat. It's fixed enough,
for those that care. It's on enough devices (more every day) now to
give those that succeed some market advantage.

Heaving cake over the transom is the "last" thing. And after 18
versions in the last round, toke's fried, I'm fried, everybody's
fried. I'm very happy it started cracking 40gbits, stumped at the bug
stopping us.

I do long for the day where I could buy a cable modem, dsl device, can
bus, ont, gpon, wireless router, enode-b, etc, etc off the shelf,
clearly  marketed with bufferbloat-related fixes - and ISPs will
supply default gear that worked "right", etc, etc that all did the
right thing... but I figure that's going to take explicit market
demand, regulation, or a miracle - or all three. And a decade. Or
more.

I *am* going to washington DC week after next for the lanman2018
presentation of cake, and perhaps I'll find a way to raise some hell
with the FCC, congress, or the FTC (suggestions wanted), but...




-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619


More information about the Cake mailing list