> On May 3, 2017, at 7:59 AM, <[email protected]> > <[email protected]> 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@60. Why not do the same for internet speed? 60M@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? _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
