• I added the bold

    On Mon, Oct 12, 2015 at 11:55 AM, Dave Taht  wrote:
    On Mon, Oct 12, 2015 at 1:47 AM, Jonathan Morton  wrote:

    On 12 Oct, 2015, at 00:30, Dave Taht  wrote:

    so… anyway, this does start some api breakage, also. Anyone else got

    Some of that is definitely wrong.  The rate_overhead parameter needs to be signed, for a start, since some last-mile encapsulations have less overhead than Ethernet.  That’s why I had it as ‘short’ instead of ‘u16’.

    A point being that I am having my life eaten by politics and the rtt
    parameter and the dual hash thing, are the only two things left that
    need to get done in cake so far as I know.

    And it's your code, primarily, and there are plenty of people, willing
    to contribute and - especially - help test.

    We are one last day, one last big push, away from getting this thing
    done. A hackathon with everybody, perhaps, to get there?

  • Thanks for the heads up.

    I doubt I will switch to Linux for cake. CoDel made it into pfSense (thanks to ermal), but upstream FreeBSD rejected it. I am doubtful that cake will ever make it to pfSense. I would love to see it though.

    Some comparisons between cake and our CoDel would be interesting. The IPFire dev will probably be the earliest adopter, for anyone wanting to test with a live-CD router OS.

  • Based on their testing, cake has perfect flow isolation. This means no flow can affect another flow's latency and bandwidth will be evenly distributed. You pretty much will no longer need to classify traffic. VoIP, Games, etc, will auto-magically get low latency all the time. Cake is like fq_Codel on steroids.

    Another cool thing is they support dscp markings which is done as a strict priority. But to keep bad flows from affecting everything else, each priority class gets a maximum bandwidth, which is a percentage of the total. If a flow consumes too much bandwidth, it gets demoted into a lower priority and never promoted back. Of course cake is technically stateless, so once a flow is emptied out of the queue, the priority resets for that flow. Because of how well cake works, this priority system just means high priority packets can maintain sub millisecond latencies while low priority queues may have single digit latencies. Even the bulk flows maintain something around 5ms.

    Cake is like fq_codel where it uses hash buckets and places traffic in a bucket. But because fq_codel has hash collisions, cake added "ways" which allows for up to N hash collisions before two or more flows have to share a bucket. New flows, relative to the hash buckets, get priority. So a sparse flow, like VoIP or a game, get priority over everything else because they packets come in and quickly get dequeued, which empties the bucket. Fat flows linger around and have a backlog allowing cake to continue to track the flow. For flows that linger past a single packet, cake prioritizes the flow with the least consumed bytes. Because of microscale timings and events, this effectively means the bandwidth is evenly distributed.

    Unlike fq_codel, cake does its calculations at the byte level instead of the packet level. Cake is a scheduler, which is also byte based instead of packet based. Cake also has the ability to calculate the additional overhead of various protocols like ADSL's cell framing or PPPOE, when calculating its scheduling. Because N bytes put in the WAN may result in N+M bytes of traffic, and cake wants to make sure your link can handle it.

  • Hey guys any news on cake… ?

  • There have been some takers on the call for testing. There's a been a lot of renewed discussions and testing. There is also a bit of minor polishing, but parameter names, accepted ranges, but the core of Cake seems to be very stable.

  • To be clear, no work is being done to bring cake to pfSense/FreeBSD. Cake is Linux-only for the foreseeable future.

  • Yeah.. we don't even have fq_codel yet.

  • So if we want to run Cake then we will have to build a different Linux server?  FML.  Not having followed Cake and it's development - what is the best flavor to do this with?

  • I'd bet IPFire will be among the first x86 firewall distros to offer it.

  • If it's Linux-only without any roadmap for a *BSD port, why are we even talking about this?  Is the source available?  Is it a simple matter of swapping out headers, library refs & API and recompile for *BSD?

  • @KOM:

    If it's Linux-only without any roadmap for a *BSD port, why are we even talking about this?  Is the source available?  Is it a simple matter of swapping out headers, library refs & API and recompile for *BSD?

    cake is the evolution of codel/fq_codel, something we have talked about quite a bit around here, so it is a somewhat pertinent topic. Yeah, cake probably belongs in the General sub-forum, not here.

    The source-code is available, but cake is deeply entrenched in Linux-only features. I highly doubt we will ever see it.

    We will be getting fq_codel but it will be via limiters (dummynet), and I have no clue whether that means we can properly make use of fq_codel's abilities or not. We primarily use ALTQ for traffic-shaping.

  • Thanks for the deets.  I'd rather they spent the time making the shaper interface less inscrutable than it currently is than adding more shaping algorithms.  I suspect that there are only about 10 people in the entire forum that effectively understand the traffic shaper.  I've spent hours reading up on it, experimenting and asking questions, and I still don't have the confidence in my knowledge that I should.  It's getting to the point where good QoS is not just an enterprise-level feature.  With every home having multiple users with multiple devices, managing bandwidth and contention is very important.  There has yet to be a Hangout that covers the shaper in-depth, and the interface makes most users scratch their heads.

  • It is very disappointing that cake most likely will not be making it's was to PfSense. I have loved PfSense ever since I started running it and ipfire looks like junk to me.

  • @cplmayo:

    It is very disappointing that cake most likely will not be making it's was to PfSense. I have loved PfSense ever since I started running it and ipfire looks like junk to me.

    Cake is not really meant for power users with complex traffiic shaping needs.

    pfSense will be getting fq_codel via it's inclusion in the "limiters" (FreeBSD dummynet) feature. I am unsure how useful it will actually be for us, but it should be 99% as effective as cake.

  • Cake isn't useful for shaping bandwidth. Think of it as an advanced fair queue that evenly distributes bandwidth and advanced flow isolation. It's a near-zero configuration QoS that will make sure high bandwidth applications won't starve your low bandwidth latency/jitter/loss sensitive flows. Cake does have a few things an ISP would like to have. By default, Cake hashes on dstIP+Port, but can be configured to instead hash on srcIP or dstIP. This would allow an ISP to isolate customers from each other and evenly distribute bandwidth among all customers in a stateless way. Stateless is important for scaling reasons. Limiters are great until you have tens or hundreds of thousands of IPs. A new limiter per IP isn't going to work well.

    fq_codel does not has perfect flow isolation. It is susceptible to the "birthday attack" issue. If you have sqrt(hash) of flows, you have a 50% chance that one of the hash buckets contain 2 or more flows. Even at 1024 buckets, fq_codel has a 50% chance that there is a collision. Cake uses "ways" to deal with this. Think cache associativity. Cake can handle up to 8 flows in the same bucket before a true collision occurs. This does not happen in the real world. At even 100,000 TCP flows on a 100Mb link, you still don't get collisions. With even 10,000,000,000 buckets, fq_codel would still have a 50% chance of collision with 100,000 flows, while cake has no collisions and only 256 buckets.

    Many of cake's ideas could be backported to fq_codel. I think that would be awesome, because I like HFSC.

    As a shaper, one important thing that cake does for low speed connections is it calculates in link layer overheads as part of its packet scheduling. This is important for connections like DSL where cell-framing + PPPOE + Ethernet can bloat up a packet's true size quite a bit relative to a 1Mb slow speed.

  • Any news about cake?

  • yeah I would love cake as well, but sadly I cannot see any information on it been ported to dummynet, it looks like nothing is happening for that. :(