deltice
commented
2 years ago 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
elludraon
Prerequisites
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.