[Cake] Recomended HW to run cake and fq_codel?

Pete Heist peteheist at gmail.com
Wed May 3 03:15:42 EDT 2017


> On May 3, 2017, at 7:59 AM, <erik.taraldsen at telenor.com> <erik.taraldsen at telenor.com> wrote:
> 
>> It’s an interesting question: what can be done as an ISP? Essentially it boils down to the fundamentals 
>> of deploying AQM- finding where the queues are forming and placing fq_codel or Cake at the 
>> bottleneck links, preferring “hardware” queue management like BQL or in the case of WiFi the ath9k’s 
>> driver in LEDE, over soft rate limiting, where possible. When soft rate limiting, the rate limiting strategy 
>> and chosen rate are the most CPU intensive and finicky parts of deploying AQM.
> 
> What I see as short term posibiliteis for us as ISP's is to push our vendors to include this as a part of the feature set.  We also could do better with the maketing.  Lets steal an idea from the Video area.  HD is often written as 1080P at 60.  Why not do the same for internet speed?  60M at 80ms.  Where the @80ms would be the larges latency in either direction that queue management would introduce?  (This of cource introduces the risk of artificialy tuning the @xxms to low and ending up with strict policing)

True, in the same way max throughputs have been pushed up various ways, I wouldn’t want to see a latency war where ‘pfifo limit 2’ is being deployed, and yet I like the idea of spreading awareness about the importance of latency. When I hear users ask “is it stable?”, I think latency is a big part of what they’re asking about without realizing it. There’s a certain “latency stress" that comes when clicking a link on the web and not getting an immediate response. I wonder if anyone has studied that.

>> - I don't understand why ADSL modem vendors don’t just bake BQL-like functionality right into their 
>> devices so they can ship AQM without the need for soft rate limiting. AQM is so effective on ADSL's 
>> upstream that it seems it would just make a lot of sense. For that matter, why not on the DSLAM as well 
>> to shape the customer’s downstream, if that’s also a bottleneck?
> 
> I think most ISP's handle shaping on the BRAS level rather than on the DSLAM, as DSLAM's in general have very limited shaping/qos capabilities.

That makes sense. I’ve never worked with provider side ADSL equipment so I lumped it all under the term “DSLAM”, not knowing what a BRAS was before. :) 

Another option for ISPs (failing AQM support in the devices, and instead of deploying devices on the customer side), could be to provide each customer a queue that’s tuned to their link rate. There could be an HTB tree with classes for each customer and Cake at the leafs. Knowing each customer’s link rate (assuming it’s not variable) you’d set HTB’s rate to something less than that. There would be work to do as each customer is added and removed, but at least it would be transparent to them. AQM is best done at egress where packets originate, so I’m not sure how well it would work in practice.

What’s usually used for an ADSL provider’s backhaul, fiber?


More information about the Cake mailing list