Diffserv Linux Improvement Overview

In my efforts to improve QoS possibilities under Linux by fully implementing RFC4594 I’ve come to understand why it hasn’t been tried.

(See git repo at https://github.com/dtaht/Diffserv for the test implementation which attempts to update RFC4594 for modern conditions in the home and business. The scripts therein will clearly show why I’m suggesting some of these new iptables (and/or tc) matches and targets.)

Adequate DSCP classification rules can number in the hundreds using straightforward existing iptables methods, or thousands with existing tc methods. Where iptables is like programming in symbolic assembler, tc is like coding in machine language.

In early testing of an iptables version, my first attempt cut the performance of a given router from ~140Mb/sec to 42Mb/sec.

And yet: it seems very possible to make DSCP classification highly performant as the 6 bit value therein maps conveniently into 64 bit bitmaps.

So many problems can be solved by some new iptables or tc matches and targets.

So here are my thoughts. Perhaps code to do some of this sort of stuff already exists out of tree?

RFC4594 rigorously attempted to avoid making any given traffic class predominant over another - EF traffic is suggested to be limited to 30% of available bandwidth, for example - the goal was to produce fairness between flows, as is mine. I’d like to be able to listen to internet radio, while others in my family are uploading to facebook, watching movies from netflix, and making phone calls and playing games.

In reading the following discussion it is very useful to have the relevant rfc, and the manual pages for iptables and ip6tables and tc handy. Some familiarity with all this concepts is required as well as a mental model as to how the Linux networking stack actually functions. For a large diagram of the below chart, see http://l7-filter.sourceforge.net/PacketFlow.png

You’ll note it elides the complexities of the various tc qdiscs, filters, and policers, and the complexities of the networking device drivers themselves. A flow diagram of each would also take pages to describe!

Anyway, it is interesting and useful to try classifying your own traffic using the diffserv_dbg script as provided in the Diffserv repository. I would appreciate a look at your results (particularly the ANT packets overall, and icmpv6 packets) via

iptables -v -t mangle -L
ip6tables -v -t mangle -L 
iptables -t filter -L
ip6tables -t filter -L

in order to see why, in part, I feel extensive classification is more necessary today than ever before.

The largest problem with the design as it stands is that the initial classification rules should probably take place within the tc subsystem. The problem there is that tc is even more primitive than iptables. A subsequent version of this proposal will attempt to use tc to solve many of these problems.

To edit this page, submit a pull request to the Github repository.
RSS feed

Recent News & Articles

Mar 12, 2017 Wiki page
Make-Wifi-Fast Project
Mar 10, 2017 Wiki page
What Can I Do About Bufferbloat?
Feb 10, 2017 Wiki page
More about Bufferbloat
Dec 27, 2016 Wiki page
RRUL Chart Explanation

Find us elsewhere

Bufferbloat Mailing Lists
#bufferbloat on Twitter
Google+ group
Archived Bufferbloat pages from the Wayback Machine


Comcast Research Innovation Fund
Nlnet Foundation
Shuttleworth Foundation

Bufferbloat Related Projects

Congestion Control Blog
Lede Project (OpenWrt)
Flent Network Test Suite
The Cake shaper

Network Performance Related Resources

Jim Gettys' Blog - The chairman of the Fjord
Toke's Blog - Karlstad University's work on bloat
Voip Users Conference - Weekly Videoconference mostly about voip
Candelatech - A wifi testing company that "gets it".