I don't even know where to start bob. This part of the language has been in the draft for 2 years, and you are the only person to object that I can recall. It's an experimental RFC. By "safe" we mean that deploying it, within the guidelines, won't break anything to any huge extent to enormous benefits. "unsafe", for example, would be promoting use of dctcp while it still responds incorrectly to packet loss. Verses your decades long quest for better variable rate video, we've had over a decade of the bufferbloat problem to deal with on all traffic, particularly along the edge, and even after solutions started to appear in mid 2012, we haven't made a real dent in what's deployed, except for the small select group of devs, academics, ISPs, and manufacturers willing to try something new. I'd like to imagine things are shifting to the left side of the green line here, but under load, most users are still experiencing latency orders of magnitude in excess of what can be achieved http://www.dslreports.com/speedtest/results/bufferbloat?up=1 I've been testing the latest generation of wifi APs of late, and the "best" of them, under load, in a single direction, has over 2 seconds at the lower rates. Applying any of these algorithms to wifi is proving hard, and it's where the bottlenecks are shifting to at least in my world, where the default download speed is hovering at around 75mbit, and wifi starts breaking down long before that is hit. ... I tore apart that HAS experiment you cited here: https://lists.bufferbloat.net/pipermail/bloat/2016-February/007198.html - where I was, at least, happy to see fq_codel handle the onslought of dctcp traffic, gracefully. (It makes me nervous to have such tcps loose on the internet where a configuration mistake might send that at the wrong people. fq_codel, "safe" - not, perhaps, optimal - in the face of dctcp.) my key objections to nearly all the experiments on your side are non-reproducability, no competing traffic (not even bothering to measure web PLT in that paper, for example), no competing upload traffic, and no inclusion of the typical things that are latency sensitive at all (voip, dns, tcp neg, ssl neg, etc). with competing download and upload traffic, fq_codel *dramatically* improves the responsiveness and utilization of the link, for all traffic. Above 5mbits pretty much the only thing that matters for web traffic is RTT, the google cite for this is around somewhere. I tend to weigh low latency for every other form of traffic... today... over marginal improvements in a contrived video download scenario someday. As for pie vs fq_codel, despite making pie widely available (for example, it's shipped in the ubuntu 15.10 release) and just as easily configurable in the sqm-scripts as fq_codel and cake are, it's been very difficult to get users to stick with it for a decent a/b test. This is perhaps the best comparison of the two I know of: http://burntchrome.blogspot.com/2014/05/i-dont-like-this-pie-more-bufferbloat.html The best hope I have for a set of subjective QoE experiences, is perhaps this summer we'll have real pie and fq_codel capable modems and be able to do a blind "taste test". The pie that we have to play with is not enough like the draft to trust the results from. We're still screwed in that the CMTSes are not fixed and in most of my test sites, download bufferbloat is experienced more often than upload, in one by a factor of 6000x1, so we need to compare three things - default cmts behavior down + pie/fq_codel up. And with the cmts throttled down (as we do it today) via htb + pie/fq_codel. My core sadness in the flowqueue codel draft is that we spend way more time talking about the caveats than the observed benefits. In the case of torrent traffic, utp (especially) works well for me, on my workloads. I run through a vpn all day without bothering to do anything special about it. GF uploads big fat images all day without ever bothering me. The gamers on campus are generally happy. (The only prioritization I do is dns traffic). The HUGE benefit of having the fq-aqm tech in place is how much better it is than anything that exists in the field. I cannot remember the last non-wifi buffering event I've had on any streaming media, nor the last time netflix paused. I can't remember the last time I got annoyed in a ssh or mosh shell. I hold videoconferences on a high rate conference bridge (60mbit down/8 up) all the time on a 75mbit link with "cake" while testing other stuff... but that is perhaps just me and a rag-tag group of people that have bothered to actually install and configure the software, and their workloads. Without more implementations of all these bufferbloat fighting technologies, made deployable, with more people trying them, we're not going to get anywhere. There's still billions of boxes left to deploy and a long tail of deployed gear that will probably last 10 years or more.