Bob: Look. To me the time for discussing this was on the AQM list, months ago. I see no reason to drag all these cc's in. There is an awful lot of context and old business here, and you've said two things that really ticked me off. On Wed, Mar 23, 2016 at 12:37 PM, Bob Briscoe <research@xxxxxxxxxxxxxx> wrote: > David, > > Quick reply for now... > > DualQ and DCTCP is a separate issue to this question, because it has only > just started development. This is true and I'm sorry I dragged it into it. "cake", on my side is pretty far along, and we are making serious headway on fixing wifi of late. Perhaps I'll be able to give a talk about the issues in wifi we've almost fixed by ietf berlin. I have most of a blog written around todays' wonderful dataset. > That's why I only mentioned PIE & FQ_CoDel, which have been maturing for > some time. I do not know of any substantial deployments of pie as yet. I'm looking forward to seeing DOCSIS-pie shipped and tested sometime in the next year or so. > > Safe means "without unintended side-effects". The word doesn't alter its > meaning when the thing in question is really cool in other respects. > > If a teleworker is using a VPN for their everyday work from home, and every > time their kids upload or download an elephant they squeeze all the VPN > traffic to nearly nothing, that is enough to require a support call, and > explanation of how to switch FQ_CoDel to a safer (but less performant) AQM > (such as PIE, say). Your assertion that in this case performance would be squeezed to nearly nothing is incorrect. In the case of a single upload vs a vpn, life converges to half for each, rapidly. In pie, less rapidly. In the overbuffered field of today's non-buffer managed ISP environments, they converge in 10s of seconds, or more. In the case of that kid torrenting madly, both pie and fq_codel share the link in roughly the same proportions as the number of extant flows, with fq_codel only, having a tighter definition of a flow and converging faster. In either case, today, without some form of queue management, that kid doing an upload is generally going to hose the link entirely and make dad mad in the first place. ... You and I share a focus in opposite ways, you'd like to selectively gain priority (without diffserv) via some means, I'd like to selectively lose priority (without diffserv). To me your focus is a game theory fail - if someone wins, someone has to lose, and at in the latter case... well... see section 6.3 of the draft for the cite there. I felt that research was important (which is why it is cited in the draft, and I would not mind if it made pie's and yours), but at least in my case I'm pretty sure how to go about getting less priority than a fq+aqm'd system will want to give you, just haven't got around to resuming the work... (after proving to my satisifaction that uTP was mostly doing the right things anyway)... and still... for those that like knobs, we suggest a 3 tier diffserv system in the draft and cake has it built in. And I HATE diffserv. ... As for considering one technology more "safe" than the other.... We've already shown in detail how badly the single queue aqms respond to bursts of mixed traffic in particular, and the damage GRO is causing. The current state of seeing 2+ seconds of bufferbloat on so many link types is decidedly *unsafe*. But the internet still seems to keep working despite all that... > This is not an academic argument. There are a few billion people using the > Internet. Even if 0.01% are hit by one of the listed limitations, that's a I look forward to pleasing the other 99.99 percent and reducing their support calls. Hell, I'd settle for just 10 or 20 million more this year, that's still well behind the growth curve of the internet itself. Doesn't seeing a billion new devices deploy in the last few years without sane queue management, bother you? > huge volume of support calls. This is why it is important to use the word > "safe" precisely. Yes, FQ_CoDel has awesome performance. But it is awesome > and unsafe in certain circumstances. I wish you had raised your objections to this part of the language in draft long before it hit last call. There are plenty of drafts extant (ecn benefits being the one that still sticks in my craw) - where I raised my objections during the process, then gave up. > If that muddies the marketing message, well then seriously consider > marketing PIE instead. It's just one of several competing experimental RFCs at this point. Near as I can tell, we're going to ship them all at the same time. Can't we get some hardware built and let the market decide? > There is no room for "not invented here" in this > decision. I resent this. I have as even-handedly as possible treated every new advancement in this field with as much scientific integrity as I could muster... and went and tested the hell out of it, whenever I could. as for bufferbloat.net's efforts: We've published all the source code, all the (flent.org) benchmark code, made all the code available widely for anyone to try for under 50 bucks worth of hardware that can be reflashed with openwrt (well, 54 dollars on amazon, for the edgerouter X), and begged interested parties to try *every* bufferbloat-fighting technology we have. I jumped all over pie when it came out, helped polish the code, added ecn support, and got it out there so it could be tested by as many as possible, as soon as possible. I thought fq_pie was pretty neat. I'd fiddle with your latest stuff if you'd just fix dctcp's behaviors vs loss. I love the work on BQL and on fixing TCPs, like pacing in sch_fq. My principal interest is in ending bufferbloat in my lifetime via any means possible. And I did not, and do not, intend to make a career out of it. If I, personally, can just get to where a few more pieces of gear can be bought off the shelf with stuff that has the products of the AQM wg in it - hopefully including wifi, 3g, and homeplug! - I can go back to things I consider far, far, far more interesting. and... Jeebus, it's just one experimental RFC. > Otherwise, FQ_CoDel will get bad press later. Then, after riding the hype > curve of coolness it will fall over the cliff of disillusionment. We'll see. Never in my life have I seen a set of ideas so enthusiastically adopted by those that have adopted it, with so few complaints. The only things that bother me at this point are behaviors below ~2mbit sans tuning, and the ecn support, for which we have research ongoing in cake that we can easily fold back into fq_codel if we need to. > > > Bob > > > > On 22/03/16 04:41, Dave Taht wrote: >> >> 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. > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ >