Saturday, January 8, 2011

The Mess that is QoS in the IP Header

If there's a group of people out there that should be drug out into the street and shot it's the jackasses that designed QoS classification and marking in the IP . More specifically, the jackasses that decided we needed multiple definitions of the same bits and different bits at different layers. I sometimes wonder if the only reason that QoS classification and marking is this way is so that vendors, like Cisco, can test you on it.

At any rate, things are the way they are and we must learn it. 

If you recall from my previous post on the structure of the IP header, we have 8 bits, known as the Type of Service (ToS) Byte. Originally specified in RFC 791, the ToS Byte defined as bits 0-2 being IP Precedence (IPP) and bits 3-5 specifying special handling for delay, throughput, and reliability respectively. The final 2 bits were reserved for future use. Here's the exact text from RFC 791, with reliability spelled wrong and everything:

           Bits 0-2:  Precedence.
           Bit    3:  0 = Normal Delay,      1 = Low Delay.
           Bits   4:  0 = Normal Throughput, 1 = High Throughput.
           Bits   5:  0 = Normal Relibility, 1 = High Relibility.
           Bit  6-7:  Reserved for Future Use.

              0     1     2     3     4     5     6     7
           |                 |     |     |     |     |     |
           |   PRECEDENCE    |  D  |  T  |  R  |  0  |  0  |
           |                 |     |     |     |     |     |

          111 - Network Control
          110 - Internetwork Control
          101 - CRITIC/ECP
          100 - Flash Override
          011 - Flash
          010 - Immediate
          001 - Priority
          000 - Routine
As near as I can tell, Bit 6 was later defined as “Cost” in RFC 1349

This is all fine, but in practical use only the IPP bits were ever really used and the other bits were doing nothing. Since no one likes waste, a bunch of folks got together and decided to redefine these bits into something a little more “useful”. Hence, Differentiated Services (DiffServ) was born.

RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, redefines these 8 bits into a more scalable, useful format while retaining backwards compatibility with the IPP portion of the previous ToS definition. Diffserv uses the first 6 bits, called Differentiated Services Code Points (DSCP), and reserves the last 2 for future use.

The idea in DiffServ is to define traffic into “classes” that can then be handled accordingly at each hop of a packets journey, that is to say each class can have a Per Hop Behaviour (PHB). RFC 2475 defined the original PHB's: Class Selector (CS). These CS PHBs are fully backwards compatible with IPP and are defined as follows:

           CS PHB       IPP
           CS7 111000   111 Network Control
           CS6 110000   110 Internetwork Control
           CS5 101000   101 CRITIC/ECP
           CS4 100000   100 Flash Override
           CS3 011000   011 Flash
           CS2 010000   010 Immediate
           CS1 001000   001 Priority
           CS0 000000   000 Routine
Looking at this I think to myself “Great, WTF was the point since you have exactly the same thing you had before?”. Other than “backwards compatibility I can't seem to find any good reason for this purely semantical change. If you know by all means enlighten me.
However, we're not done here. Why would we stop with 2 (albeit identical) definitions of the 8 bits used for QoS classification and marking in the IP Header? We must have more, and more we shall have!
RFC 2597 “Assured Forwarding PHB Group” offers another way to define the 6 bits of the DS field created in RFC 2474. With Assured Forwarding (AF) there is four classes defined that network admins may assign various levels of resources to (bandwidth, queuing priority, etc) and within each class are 3 levels of drop precedence. This gives us 12 new DSCP values to classify and mark traffic with. The general format used for AF PHBs is AFxy where x is one of the 4 classes and y is one of the 3 drop precedence values.
I think my favourite part of this AFxy notation is the consistency the creators used. A high x value implies better treatment, while a higher y value implies worse treatment. Pure genius.
Yes, that was sarcasm.
AF PHBs can also be expressed in decimal values in addition to the AFxy notation. This is a simple conversion of the binary behind each AF PHB into decimal and not anything really sinister. If you look at the 6 bits used, they are represented like this:
3 bits for the x value, 2 for y, and the last bit is always 0. If you take AF11, the “first” AF PHB as an example it would look like so:
If you convert the entire 6 binary digits together into decimal the value is 10. Put this all together and you get:
           AF11 = 001010 = 10
The best part is you don't actually have to do the manual binary conversion in all of this. All of this can be summed up into one simple little formula:
           8x+2y = decimal value
           8(1)+2(1) = decimal value
           8 + 2 = 10
At least one part of this whole mess makes sense and works well.
This gives us IPP, CS, and AF. Do you think we have enough? No, of course you don't. You wanted more so you're going to get more.
RFC 2598 “An Expedited Forwarding PHB” gives us, as the name implies, one last PHB: Expedited Forwarding (EF). EF PHB was created to be a “special” PHB with a specific purpose, and I'll quote the RFC here to define that purpose.
           The EF PHB can be used to build a low loss, low latency, 
           low jitter, assured bandwidth, end-to-end service through 
           DS domains.
What this really means to us is that we have an explicit PHB for the likes of voice and video. Since the RFC describes EF as receiving priority queuing, but also being policed as to not consume all a link's bandwidth, you can start to see where “priority queuing” in the Cisco world was derived from.
EF is recommended in RFC 2598 to have a codepoint value of 101110, which is decimal 46.
In an effort to make sense of all this nonsense I've put all of these into a table with “like” values in the same row. Hopefully this helps to show which DSCP are equal to which, and how those values map back to the original IPP values. 

AF PHB Binary Decimal CS PHB Binary IPP Name Binary

CS0 0 Routine 0
AF11 1010 10 CS1 1000 Priority 1
AF12 1100 12
AF13 1110 14

16 CS2 10000 Immediate 10
AF21 10010 18

AF22 10100 20
AF23 10110 22

24 CS3 11000 Flash 11
AF31 11010 26

AF32 11100 28
AF33 11110 30

32 CS4 100000 Flash Override 100
AF41 100010 34

AF42 100100 36
AF43 100110 38

40 CS5 101000 Critical 101
EF 101110 46

48 CS6 110000 Internetwork Control 110

56 CS7 111000 Network Control 111
And that, folks, is QoS Classification and Marking in the IP Header.

No comments:

Post a Comment