fq_codel or cake available for this?

[dtaht]

Prerequisites

• I have read the Contributing Guidelines.
• I have read the Code of Conduct.

Category

Performance

Priority

Medium

Description

BQL and fq_codel (RFC8290) were designed from the very beginning of the bufferbloat effort (in 2012) to cope with things like rain fade, interference, etc, to dynamically match the available bandwidth to the buffering. The "FQ" (fair queuing) part keeps latencies low for voip and videoconferencing traffic and the codel part dynamically observes the transit rates through the queues and shoots or marks (RFC3168) traffic to get it to slow down.

The wifi version is pretty popular now (in linux for the mt76,mt79, ath9k, ath10k, and ax210 chips), and the ethernet version is ubiquitous - it's the default on nearly all of linux distros, available for all the BSDs, the default on OSX, and iOS. Openwrt and derivatives obsoleted pfifo_fast many years ago, did yocto? (tc -s qdisc show)

The net reductions in latency for many devices can be orders of magnitude. You'll find examples of how well it works all over the web nowadays, notably if you google for flent or rrul you'll find benchmarks of openwrt, linux, mikrotik and many others.

And fq_codel is only 300 lines of code... so did it make it into any terragraph derived devices? That I could test?

Workaround available?

What I observe in the wisp market is that most are using middleboxes to manage the bandwidth - like preseem (fq_codel based), paraqum (cake), libreqos.io (cake) - and while these are useful to manage subscriber plans, don't actually account for the underlying physics, nor the cost of failovers and oversubscriptions. Or we see folk deploying "SQM", which only works well for fixed bandwidths. There has been a lot of work of late on using out of band data to dynamically adjust cake to the available bandwidth, at that middlebox... but...

The best approach was and always has been, to have it running as close to the radio as possible.

[deltice]

The primary supported datapath implementation for Terragraph is using DPDK/VPP, and there aren't any implementations of fq_codel out there for VPP that I am aware of. Due to the nature of the Terragraph architecture and from my initial understanding of fq_codel, I don't think fq_codel could easily be applicable. The most related thing that Terragraph has is policers/classifiers on CPE interfaces and HQoS to manage prioritization of different traffic types.

[dtaht]

I was under the impression that HQOS had been obsoleted, and then resurrected, recently, for intel's PIE implementation: https://doc.dpdk.org/api/structrte__pie.html PIE, should in general, behave better than your typical policer does.

regrettably that looked (to my eye) to be a "textbook" implementation and needing some love and care to be deployable. However, with that infrastructure in place, doing my favorite algos seemed far, far more feasible, and I'm told at least two fq_codel implementations exist today for dpdk that are not open source.

[elludraon]

Yes, it was deprecated; we replaced it with our own VPP HQoS implementation, documented here: https://terragraph.com/docs/developer/VPP_Implementation#hqos-scheduler-tghqos

[dtaht]

It would be really nice if RED died a quick, miserable death in the software implementations at least. It's original designer (van jacobson) has been trying to deprecate it for many, many years, and he and kathie designed codel to replace it. Their paper, from 2012, is here: https://queue.acm.org/detail.cfm?id=2209336

[dtaht]

The IETF also deprecated RED in 2015, here: https://www.rfc-editor.org/rfc/rfc7567.html