ToS/DSCP byte in IP packets

Update: be sure to read comment #3 below from Dave Täht. Apparently the Bufferbloat project has made a lot of progress on good router queuing and there’s a lot for me to learn about, including fq_codel and CeroWRT.

Interesting thing in Transmission’s Bittorrent client’s docs

peer-socket-tos: String (default = “default”) Set the ​Type-Of-Service (TOS) parameter for outgoing TCP packets. Possible values are “default”, “lowcost”, “throughput”, “lowdelay” and “reliability”. The value “lowcost” is recommended if you’re using a smart router, and shouldn’t harm in any case.

The Type-of-Service byte is the second byte in an IP header. It is not widely implemented, and has a tangled history. Is it useful?

The bottom six bits are for DSCP, Differentiated Services (aka DiffServ). This allows an IP packet (or the program controlling it) to request a certain level of routing service quality. There’s various things to request; low jitter, best effort delivery, and a couple of means of defining priority classes. I don’t know how well supported these bits are, the Wikipedia entry makes it sound like it’s not entirely unknown. Linux IPTables has rules for setting DSCP classes. The Bufferbloat wiki has some discouraging notes on implementation. Windows 7 claims to support it, but looks wonky. Someone found a Comcast bug in their DSCP data that was harming download speeds.

The top two bits are used for ECN, a way for the router to signal to a TCP stack that it should slow down without actually dropping packets. I think ECN is not practically useful in today’s Internet, too many clients don’t implement it and too many routers don’t use it (or any form of queue management). But I could be wrong. /proc/sys/net/ipv4/tcp_ecn is 0 (not enabled) in my Tomato/Shibby router even though I’ve turned QoS on.

My conclusion on a quick read is these bits are not usefully deployed, too much stuff doesn’t support them. Too bad; it’s exactly what a home network router needs to cooperatively share a network. So much of TCP/IP QoS work was abandoned because it doesn’t work with hostile peering relationships. But I really do trust and control my home router and I wish it could do more to manage bandwidth.

6 thoughts on “ToS/DSCP byte in IP packets

  1. so cool! great post. i’m a sucker for protocol geekery – at least implementing and dissecting, if not the standards body part :/ – so i love forgotten vestigial easter eggs like this.

  2. I just wish it were more than vestigal. Most of my knowledge of this stuff goes back to a 1999 class on TCP/IP taught by Hari Balakrishnan. Which was amazing, but now 15 years old. But AFAICT very little has progressed when it comes to Internet QoS; no ECN, no RED, no meaningful use of ToS flags. In some ways I think that’s a worse problem than the lack of IPv6 adoption.

  3. The Diffserv document I did was an attempt to find ways to do what we wanted with diffserv. As you can tell, that effort was less than successful!! – but by identifying the traffic types we specifically wanted to optimize, we realized that a fast/sparse + slow/bulk dual queue fair queuing system would do the job without classification. It’s called “fq_codel” , which went into linux 3.5, and is shipping in openwrt, dd-wrt, ipfire, pfsense, and multiple rebranded products such as streamboost now.

    You can still “trust” diffserv within your home to the gateway, so if you wanted to manage outgoing torrent flows better (in addition to fq_codel), there is a three bin qos system in cerowrt called “SQM”, which works on nearly every linux system shipped today.

    use something like that on your edge gateway, mark your torrent traffic as CS1, and stop worrying about it.

  4. What a fantastically useful comment Dave, thank you so much for coming here and sharing it. I get the impression the Bufferbloat project has made a lot of progress. CeroWRT looks very impressive. Is there some good overview article for technical users that explains it all? Most of what I’ve found are details of specific experiments (like yours), I’d love an overview for folks who understand network but aren’t closely involved with Bufferbloat development.

  5. For ethernet, and dsl it’s all over but the standardizing – Just a few bits of coding here and there[1]. Cable modems, almost, not quite yet, the PIE aqm went into DOCSIS 3.1. Wifi and various forms of wireless – barely started.

    I gave a bunch of talks about queueing mechanisms, I’m still happiest with the modena one:

    As for fq_codel for technical readers, there are now two internet drafts pending with the ietf.

    and this is substantially updated from the original ACM queue article

    Goal in life here is for this stuff to just be on by default, to need no tuning, and no knowledge on the part of the end user – however a few lines of code need to get dropped into *everything*.

    example, today, I finished up the fixes to the beaglebone black:

    I like to think cerowrt’s SQM system is easy to understand and port to other linux systems, but the closest I’ve come to describing it is in this unfinished draft:

    and this critique of wondershaper:

    [1] only a few lines of code need to go into hundreds of thousands of different kinds of devices to fix, deployed in the billions, growing by 10s of millions per day. All with bad latency and queuing characteristics…

  6. Wow, thanks for the links. And all your time and effort, it sounds like a huge improvement. I had no idea the BufferBloat project had gotten so far. Great work!

Comments are closed.