We are currently optimizing network routing and bandwidth allocation for a web application serving high-concurrency HLS dynamic video streams to client devices.
While general web traffic routes smoothly, we notice occasional buffering spikes on client endpoints during peak traffic bursts when multiple connections request high-bitrate video segments simultaneously.
I would like to get recommendations from experienced network engineers on MikroTik RouterOS setup:
How do you optimally configure PCQ (Per Connection Queue) or CAKE/FQ-CoDel queues in RouterOS to balance video segment downloads fairly among users without introducing bufferbloat?
Are there recommended MANGLE firewall rules to classify and prioritize HLS (.m3u8 / .ts / chunked MP4) media packets over generic HTTP GET traffic?
What is the best strategy for utilizing FastTrack while maintaining precise queue management for streaming media endpoints?
Would appreciate any sample mangle/queue configurations or best practices from anyone managing media-heavy LAN/WISP environments!
Hello,
I’ve been dealing with similar "tasks" for quite some time (around 20 years), and there is one important step that colleagues—myself included, in the past—always overlook. First, you need to sketch out the "Task" as it currently stands using a simple pen or pencil; this allows for appropriate adjustments based on input from the team before selecting a working plan—which should also be sketched out, since changes are often necessary even during implementation due to unforeseen, hidden circumstances. So, do you have such a plan? What does it look like? We need to know this to determine the required hardware and how to configure (optimize) it "properly" to execute the task with the necessary precision. Off the top of my head, I’d suggest that MikroTik offers a very dynamic platform for managing such tasks, though it often suffers from a lack of proper planning. Please clarify your vision—your "dream scenario"—so the team can offer their perspective on it.
At the very least, ensure you are managing direction, traffic, and requirements effectively and strictly in accordance with the specifications. Regards.
PS_X1->
If one could call it that—practical advice:
Whenever possible (and it is highly recommended), do not mix broadcast segments within a single device (router), and do not rely on one device to handle all the traffic—after all, not everyone has the mental capacity to manage a complex configuration. Do not mix traffic with different purposes without at least implementing VLAN segmentation. Do not leave the traffic path to its final destination uncontrolled—MikroTik excels at managing this (avoid dynamic service points whenever possible). When planning, proceed with the mindset that nothing is more important than SECURiTY!
If HLS videos are delivered from the same server/IP as "normal" http, there is no way for a router to identify HLS. It was/is the design goal of HLS to work over existing http infrastructure, so technically it is not a stream but a sequence of normal http file downloads (GET) of video chunks. The client puzzles everything back into a stream for the local display. All a router sees is TCP (or UDP in case of QUIC) connections to port 443 with encrypted payload (TLS/https).
This would require an http load balancer terminating https and handling/prioritizing http GET based on file names and MIME types in http headers (Layer 7). For larger services, HLS requests are usually redirected to 3rd party CDNs (AWS, Akamai, Clouflare, Google, ..).
That is going to be a bit of DIY testing. The late David Täht would suggest putting a Cake or fq-codel queue on the interface leaving the router facing the customers, and then run some tests, watching for spikes to be smoothed out. He has a bunch of posts around the Internet to help you get started.
You could also try LibreQoS between the servers and the customers. It has visualization tools to help you see where TCP congestion might be occurring and what-not.
If it's encrypted in HTTPS, there's no way for a downstream device to do L7 inspection (which would be expensive anyway). Your best bet is to separate HLS media from the rest of the served content in some way: different port numbers, different IP addresses, or completely different hosts (which presumes different IPs, at least internally). That's how I do it for my Sunday broadcasts: apps load their HTML/JS from one URL, then that app loads content from a different hostname.