Heavy Networking | August 25, 2017
Show 354: Future Of Networking With Fred Baker
Ethan
Banks
Greg
Ferro
Listen, Subscribe & Follow:
The Future of Networking series continues with guest Fred Baker, a Cisco Fellow and longtime network engineer and IETF chair.
Greg and Fred discuss the history and future of QoS, adaptive queue management (AQM), and other techniques for dealing with bandwidth limitations and congestion.
They also discuss Fred’s vision for how networking will change over the next five years, including the impact of IoT.
Fred Baker has been working in the industry since 1978 and has been involved with many routing standards, including OSPF 2. He is currently the IETF chair of the IPv6 Operations group.
This episode was recorded live at IETF 99. Thanks to Huawei, which covered travel and accommodations to enable the Packet Pushers to attend and record some shows to spread the news about what the IETF is up to.
Share this episode
Hi, great show as always. Please share the IPv6 report mentioned in the show.
Thanks
Report at https://www.internetsociety.org/what-we-do/internet-technology-matters/ipv6
I heard Fred talk years ago (1998?) at Networkers. He was great. Looking forward to listening to him again after all these years.
Nice of Fred not to disagree with the assertion that QOS is an exception or a niche use case 😎
My recollection of our conversation is that he broadly agrees with that view.
I wish QoS was not an exception, because you can’t always have enough bandwidth for the traffic you want to move. Fred worked closely with the AQM working group to author multiple RFCs recently – and moving house – as the interviewer did – is NOT always feasible. Saying that satellite links, overbuffered dsl or cable modems, and wifi and lte are not important and are not going to stay important, that ultimately everyone will have enough bandwidth, all the time… doesn’t solve the problem. HE did – finally – 10 minutes into the interview, start talking about codel and pie in the context of not having to rate limit folk.
https://tools.ietf.org/wg/aqm/
I think fred (and the interviewer) thinks of QoS as leveraging diffserv markings, and makes a more clear distinction between that and aqm (and fair queue-ing) than I do.
If we limit the discussion to discussing diffserv markings, then I tend to agree, mostly. 🙂
Heres a bit of recent work about applying fq_codel to wifi:
https://www.usenix.org/system/files/conference/atc17/atc17-hoiland-jorgensen.pdf
And here is a combined qos/aqm/shaper/fair queuing algorithm in increasing deployment that is targetted at end users and ISPs.
https://www.bufferbloat.net/projects/codel/wiki/CakeTechnical/
I tend to think either of these algorithms will work really well in the one to two packet world of IOT discussed above.
Hi Dave
I was referring to Network QOS which doesn’t work. The challenge of scaling QOS in the network devices, plus creating a end-to-end schema is largely pointless and doesnt’ generate any meaningful results. And the for the cost of managing QOS you can upgrade the bandwidth a lot cheaper.
When we spoke in the past, I came away with the view that these address the problems of end point QOS in terms of pacing the TCP flow at the source/destination ?
I will argue that having a “background” level of service (CS1) could work, (and cake is targetted at small domains) – but like y’all, I’m pretty pessmistic about all the other definitions in diffserv, which, again, I think we all equate to the word “QoS” now.
However, based on the results thus far of pacing and BBR and so on… as encouraging and as helpful as they are – fq and aqm anywhere there are big to smaller transitions in bandwidth, is far, far superior to big dumb buffers. And of the two, FQ is more important, but both are needed in a world of wireless jitter and wildly varying bandwidth.
But, me being me, I just get the code into linux, and make sure it’s on by default (as it is in lede), or easily configurable (dozens ofproducts now sport something like “SQM”), and only occasionally get a paper done like the wifi paper above. It’s always my hope to get a doubting thomas interested enough to go install a lede box in front of a comcast cablemodem, or DSL – or (it takes heftier cpu to do fiber) – and try these algorithms there.
Even on fiber, we can eliminate jitter (two orders of magnitude) for sparser flows, and hold (via aqm) induced latency below 10ms on the fatter ones. Here’s a 100Mbit test on sonic fiber gpon network in SF:
http://www.taht.net/~d/sonic_106_cake_vs_default.png
Hey Greg, you are saying that qos is an exception and that in most case you can just throw bandwidth at the problem.
I would agree in the US and part of Europe but for most of the rest of the world the average bandwidth is still between 2 and 10 mbps.
Reference: https://en.m.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speeds
What are your thoughts on that ?
Ps: great show and content.
I ve found a more up to date analysis from Akamai here: https://www.akamai.com/fr/fr/multimedia/documents/state-of-the-internet/q1-2017-state-of-the-internet-connectivity-report.pdf
Some country have better bandwidth than in 2015 but the average for China is still only 7 Mbps.