Re: [aqm] Last Call: <draft-ietf-aqm-fq-codel-05.txt> (FlowQueue-Codel) to Experimental RFC

[Bob Briscoe <[e-mail]>]

David,

Quick reply for now...

DualQ and DCTCP is a separate issue to this question, because it has 
only just started development.
That's why I only mentioned PIE & FQ_CoDel, which have been maturing for 
some time.

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).

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 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.

If that muddies the marketing message, well then seriously consider 
marketing PIE instead. There is no room for "not invented here" in this 
decision.
Otherwise, FQ_CoDel will get bad press later. Then, after riding the 
hype curve of coolness it will fall over the cliff of disillusionment.



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/