> On June 1, 2015 at 6:49 PM "jsullivan@xxxxxxxxxxxxxxxxxxx" > <jsullivan@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On June 1, 2015 at 6:37 PM Dave Taht <dave.taht@xxxxxxxxx> wrote: > > > +> > <snip> > > > Interesting. We do a lot of video work and hence UDP. For heavily mixed > > > environments with high bandwidth and sometimes high latency, is fq_codel > > > still > > > the preferred leaf qdisc or should we be investigating sch_fq? Thanks - > > > John > > > > The answer is too nuanced to fit into the margins of this email. :) > > > > I believe FAR more research and development work is needed on low > > latency udp or current-ly using udp - applications. Most of the > > industry focus is (and has always been) on making tcp perform well - > > and me, well, it is obvious that we are going to lose the existing > > phone system in under 2 decades - and we need to replace it with a > > (hopefully better) internet, add videoconferencing, and make other > > highly interactive apps like games co-exist with netflix. > > > > > > But: > > > > What exactly do you mean by leaf qdisc in this question? > > > > Latency happens at the bottleneck links to the largest extent, but > > there is also latency that accrues within a machine at various layers > > in the stack. you need to find and improve the bottlenecks, which is > > something of a wackamole exercise. > > > > My principal concern (today) with the potential wide deployment of > > sch_fq (over fq_codel) is > > that sch_fq generates a unique internal id per new flow which is not > > sufficiently resistant to DDOS attacks for my taste. sch_fq has > > "improved" lately with some protection for that, but it disables the > > distinct per-flow-fq-advantage sch_fq brought to the party in the > > first place, but, (on the gripping hand) may well be the closest thing > > to the right thing for your application mix! Try it! report back! :) > > > > fq_codel is faster and safer in a wider range of environments than > > anything else we got. Safety is an important feature... > > > > Other ideas at the protocol layer for "things with cookies" - would be > > nice - like, (the now impossible to implement) rfc6013 - and Quic is > > quite promising - these ideas strike me as a long term answer to the > > bcp38 and DDOS problem, but those ideas need to move into voip > > transactions. > ><snip> By leaf I mean that we typically use HFSC as our qdisc to shape our latency very accurately. We then put fq_codel as the leaf qdisc on its classes. Thanks - John -- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
