# Verifying end-to-end QoS marking

A not so easy process about QoS involves the verification of end-to-end QoS marking: are the marks maintained through the all network?

Before going deep, let’s recap how an IP packet can be marked:

• The IP field reserved for QoS is 8 bits long and it’s called TOS (Type of Service).
• RFC791 defines 3 bits for IPP (IP Precedence) and 3 bit for traffic characteristics (Delay, Throughput and Reliability). 2 MBZ bits (Must Be Zero).
• RFC1349 updates RFC791 and define 3 bits for IPP, 4 bits for TOS (Delay, Throughput, Reliability and Cost) and 1 MBZ bit. In this RFC “Type of Service” is referred to the 8 bits field in the IP header, and “TOS” is referred to the 4 bits field inside the 8 bits “Type of Service” field.
• RFC2474 defines another way to use the ToS field: 6 bits for DSCP and 2 MBZ bits. RFC4594 defines how DCP bits can be used: DF (Default Forwarding), AF (Assured Forwarding), EF (Expedited Forwarding) or CS (Class Selector).

More QoS related RFC exists, but they are out of the scope of this very short document.

ToS (int) ToS (hex) ToS (bin) IPP TOS DSCP (PHB) DSCP (int) DSCP (bin)
0 0x0 000 000 0 0 0 - Routine 0000 - Normal Service DF (CS0) 0 000000
32 0x20 001 000 0 0 1 - Priority 0000 - Normal Service CS1 8 001000
40 0x28 001 010 0 0 1 - Priority 0100 - Maximize Throughput AF11 10 001010
48 0x30 001 100 0 0 1 - Priority 1000 - Minimize Delay AF12 12 001100
56 0x38 001 110 0 0 1 - Priority 1100 - Minimize Delay and Maximize Throughput AF13 14 001110
64 0x40 010 000 0 0 2 - Immediate 0000 - Normal Service CS2 16 010000
72 0x48 010 010 0 0 2 - Immediate 0100 - Maximize Throughput AF21 18 010010
80 0x50 010 100 0 0 2 - Immediate 1000 - Minimize Delay AF22 20 010100
88 0x58 010 110 0 0 2 - Immediate 1100 - Minimize Delay and Maximize Throughput AF23 22 010110
96 0x60 011 000 0 0 3 - Flash 0000 - Normal Service CS3 24 011000
104 0x68 011 010 0 0 3 - Flash 0000 - Normal Service AF31 26 011010
112 0x70 011 100 0 0 3 - Flash 1000 - Minimize Delay AF32 28 011100
120 0x78 011 110 0 0 3 - Flash 1100 - Minimize Delay and Maximize Throughput AF33 30 011110
128 0x80 100 000 0 0 4 - Flash Override 0000 - Normal Service CS4 32 100000
136 0x88 100 010 0 0 4 - Flash Override 0000 - Normal Service AF41 34 100010
144 0x90 100 100 0 0 4 - Flash Override 1000 - Minimize Delay AF42 36 100100
152 0x98 100 110 0 0 4 - Flash Override 1100 - Minimize Delay and Maximize Throughput AF43 38 100110
160 0xa0 101 000 0 0 5 - CRITIC/ECP 0000 - Normal Service CS5 40 101000
184 0xb8 101 110 0 0 5 - CRITIC/ECP 1100 - Minimize Delay and Maximize Throughput EF 46 101110
192 0xc0 110 000 0 0 6 - Internetwork Control 0000 - Normal Service CS6 48 110000
224 0xe0 111 000 0 0 7 - Network Control 0000 - Normal Service CS7 56 111000

Within the same AF class, higher DSCPs have an higher drop probability (AFX1 = low, AFX2 = medium, AFX3 = high). Lower AF class should have a low drop probability (AF1X < AF2X < AF3X < AF4X).

IPP and TOS are no more used, but for completeness here the TOS table:

TOS Service
0 0 0 0 Normal Service
X X X 1 Minimize Monetary Cost
X X 1 X Maximize Reliability
X 1 X X Maximize Throughput
1 X X X Minimize Delay

## Why so many values?

Currently DSCP is the most used QoS model, but each network tool can take input using a specific format.

## Analyzing packets

Let’s assume we want to check if received packets are correctly market. We want to analyze EF and AF1 class. On Linux, tcpdump takes decimal ToS values:

# tcpdump -n -v 'icmp and (ip[1] & 0xfc == 184 or ip[1] & 0xfc == 56 or ip[1] & 0xfc == 48 or ip[1] & 0xfc == 40)'


The Linux ping command also takes decimal ToS:

# ping -Q 184


Cisco routers take the binary ToS:

#ping
Protocol [ip]: