Looking for good QoS/traffic-shaping books.

I am looking for some good books that include or focus on the topic of QoS and/or traffic-shaping.

There is a large amount of good technical information in academic papers and RFCs but those things take me a while to digest. Something more enjoyable, perhaps giving detailed real-world examples why certain traffic-shaping scenarios fail or succeed, is what I am looking for.

Preferrably OS-agnostic or BSD/Linux-centric.


Any book recommendations on this or related topics?
Thanks

There are academic papers that would show practical results. You can also try the linux networking manuals relating to configs and try looking at some network related efforts such as ISPs or even universities that would have a paper or theory or even lecture slides that would explain the things you want. Reading materials from related courses at universities do tend to include good books.

There are QoS on many levels from L2 all the way to L7 and many different ways though only some routers (such as routerOS) or full OS(unix/linux -pfsense and such dont count) will let you try them all out.

It was HFSC packet queueing algorithm and it's dozens cited papers that got me interested in the subject.
I was hoping for a book that was broader, less singularly focused. The application of the algorithm(s), how the real-world differs from simulation, how to attempt better traffic simulations, etc.

I picked up some Cisco books, and I've been surprised by how good they are. Cisco's online technical documents were a constant joy whenever they covered a subject I was researching. They go in to more details than most.

IMO, fq_codel is the most ground-breaking algorithm out there. It is simple for the end-user and it actually just works.


I am obviously missing something, because from my perspective it looks like QoS has been hardly researched for almost a decade. HFSC came out 18 years ago, and it is still the premiere algorithm, according to most. OpenBSD recently adopted HFSC as their only backend algorithm when they dropped ALTQ.


Isn't RouterOS Linux-based? I have always wanted to try out Mikrotik; them and Ubiquiti.

Thats because theres QoS for different things. L2 to L7 as i mentioned, different mediums such as wireless, low bandwidth radios, ethernet, DSL, DOCSIS, different packet sizes and types and applications, multi-user QoS, etc. Different programs work differently so there are many algorithms.

And routerOS is linux based but you dont have access to the linux files or the opportunity to run linux programs/scripts. You may be able to do that on Ubiquiti but routerOS has a lot more features than Ubiquiti. To try out QoS the only choice would be a proper Cisco router+switch, mikrotik routerOS, a full Linux/Unix OS. RouterOS does have its own scripting system though. You cant add or change QoS algorithms in routerOS unless you use scripting to do the job but that would be difficult and with limited performance. The easiest to try would be routerOS while a full linux/unix OS would be better. Cisco would be expensive but i doubt you could add or change algorithms on them though i havent tried a proper Cisco router yet so i cant comment on it. Scripts on routerOS arent properly multicore performance friendly at the moment meaning that certain parts of the script will have to run on the same core and all scripts run on the same core (but not all code within the script run on the same core). aside from routerOS on x86 the fastest dual core PPC routerboard would work well. the CCR1009 is fast enough too in terms of single core performance. Performance depends on how many scripts you run at the same time and how many different components you utilise. Logging uses 1 core, scripting 1 core, firewall and networking- each core per connection so a script utilising different features and components could use multiple cores.

RouterOS also has traffic generator now but requires a very fast routerboard or PC to use it on.

Just to add routerOS has various algorithms for QoS already built in and has more options than other routers even Ubiquiti.

Oh, I get ya. Different protocols. I guess layer-2 stuff is more for inter-LAN than layer-3 QoS, which usually serves best at pinch-points/gateways. I cannot see it being too useful but, granted, I do not know enough to sayhow vital it is or is not. The more the marrier, within reason...

Sadly, I can find no realistic reason to buy "good" hardware, considering that 12Mbit is the fastest thing around here. Slow, cheap hardware and an open-source OS with a powerful, secure networking stack is more than enough overkill.

I would honestly prefer a Linux-based OS for networking, since I already use as my desktop, but iptables is just completely incomprehensible to me. Thankfully, one area where FreeBSD is not stuck in the past is in it's networking functionality.

Cisco does seem to have some killer hardware with a huge amount of QoS algos to choose from.


Until things get more serious, I think iperf, netperf, and netcat will be the only traffic generators I will need for testing traffic-shaping algos between internal hosts.


I am still confused why I see practically zero ground-breaking packet queueing algorithms since ~2000. I assume I am simply out of the loop. Maybe things like OpenFlow or massively integrated virtual-switches for the "cloud". All this virtual crap confuses me.

OpenFlow is for prototyping. You create your own network protocol and use openFlow to try it out.

I suppose using a full OS would be best because of various options you can install and try.

For testing you would have your linux/unix OS as the router and have a bunch of systems/virtual systems as users and to run different applications. The main goal of any QoS system is to work when there are multiple users and applications at the same time.

When testing there are a few fields you can use such as the QoS value within the packet(for both layer 2 and 3). In managed switches that have QoS you basically adjust it using the QoS value (L2 packets with QoS value in them) by changing their priorities. Aside from the traffic generators you mentioned theres also QoS in higher layers such as with http, ssl, ftp and so on which all use either tcp or udp. even torrent is a protocol. There are many factors to consider and hence many different protocols to test aside from the usual TCP/UDP performance testing. Since almost all applications use TCP/UDP you have to look up the networking stack to balance your traffic.

On the low layers only things like VOIP, time etc require QoS for accuracy and stability.

Theres also QoS for specific applications such as if you are running a server you can set that traffic from server at a certain port is given a specific priority or bandwidth or for all traffic from a particular host to be controlled.

QoS is very broad that it is difficult to create a ground breaking algorithm. The one size fits all never works with QoS as each environment is different. Most of the time people just add more links or upgrade the hardware for faster speeds and bandwidths.

Nullity said:

I am looking for some good books that include or focus on the topic of QoS and/or traffic-shaping.

There is a large amount of good technical information in academic papers and RFCs but those things take me a while to digest. Something more enjoyable, perhaps giving detailed real-world examples why certain traffic-shaping scenarios fail or succeed, is what I am looking for.

Preferrably OS-agnostic or BSD/Linux-centric.


Any book recommendations on this or related topics?
Thanks

Click to expand...

Packet scheduling and weighting is a complex situation, and while one will find some academic references, most of the commercial implementations are closely held...

At a fairly high level, for those just joining the conversation...


This is a basic deficit round robin scheduler... it takes the following into consideration... a scheduler handling N flows[a] is configured with one quantum Q_i for each flow. This global idea is that, at each round, the flow i can send at most Q_i bytes, and the remaining, if any, is reported to the next round. In this way, the flow of number i will achieve a minimal long term data rate of \frac{Q_i}{(Q_1+Q_2+...+Q_N)}R, where R is the link rate.

yep... and that is a mature scheduler...

When we look at home/soho routers/AP's - the challenge here is that we've got the WAN interface, 3 to 4 LAN interfaces, and then, in most implementations, a Radio (or two) as LAN interfaces with multiple clients, all demanding their fair share of time - so in a router design for a SOHO AP, we have to consider multiple interfaces, multiple clients, multiple streams and application flows...

So quite literally, the little SOHO router that runs your WiFi - it's a time-machine - it's turning 360 degrees of space and clients on the WiFi, along with a few clients on the LAN (with much better bandwidth each) into Time... when to let the spice flow so to speak...

And that's why big chip companies that work in this space - really don't talk about how they do it... I know some guys that work on this stuff, and trust me, they're pretty smart

Going into 802.11ac Wave2 with MU-MIMO, it's going to be even more complicated...

It does seem like most of the current academic research is either related to wireless or mesh networks, with an occasional focus on efficient power consumption. Though, I think most of those are "no-knobs" algorithms, focusing on general fairness or efficiency rather than user configurable prioritization.

HFSC seems to still be the most powerful scheduler with it's ability to explicitly decouple a flow's per packet transmission delay and bandwidth allocation, which seems to only be useful with VOIP, or other low-bandwidth, low-delay flows. HFSC is a bit too complex for the end user, especially for what it offers, but I personally enjoyed being introduced to idea of considering a flow's delay seperate from a flow's bandwidth. The abstraction of a service-curve is also interesting.



I am more interested in higher level function. How all the seperate flows act most efficiently together as a whole. Like the obvious prioritization of DNS queries, since you cannot connect to an IP without the IP. ACK prioritization is a popular one too. I am hoping there are some interesting, counter-intuitive examples of how overall efficiency changes when you look at everything as a whole instead of individual flows.

Network monitoring or flow monitoring seems to be more towards what I want. I suppose there are few constants in today's networks, so optimization generalizations are rare and to get your network operating most efficiently you just need to know your network as precisely as possible. The data can be used in many of useful ways.


I should probably just buy a book on How to Stop Quantifying Everything, Shutup, and Relax...

Nullity said:

I should probably just buy a book on How to Stop Quantifying Everything, Shutup, and Relax...

Click to expand...

I think we both could use that book, lol...

There's a lot of interesting stuff down that particular rabbit hole, and there's more than a fair amount of traffic shaping happening on the wires, just that most of it is not exposed to the end-user - except when it hits the press like the whole Comcast-Netflix deal did.. it was a lot more than just peering relationships there, someone was actually flow managing the traffic.