Quality of Service (QoS)

Bandwidth in data networks, although a limited resource, is generally designed and used in a best effort method: Any retransmissions are in the best case taken care of by the application, or in the case of TCP, by the protocol itself. However, the commercialization of the Internet and applications requiring near real-time network support has driven the need for guaranteeing bandwidth better than best effort.

For example, many organizations require that incoming web requests be given priority over most other traffic—a possible customer that is visiting the web site should not have a “slow” connection to the web server due to email that can wait without the application being affected.

Another application requiring better than best effort routing is a voice application. Voice-over technology and the whole convergence market has created additional pressure on IP technology to support improve QoS support.

There are four common methods used to apply policy to IP traffic: source and/or destination address, source or destination port, service bits in the IP address, and a mixture of the three methods.When bits in the IP address are used, the bits are referred to as Type of Service Bits if the methods described in RFC 791 (or 1349, which modified the original RFC 791 spec) are used. If the bits are used with the methods described by the Differentiated Services working group (//www.ietf.org/html.charters/diffserv-charter.html), the bits are referred to as DS bits.

If the IP address, UDP, or TCP port is used, the traffic policing is referred to as a class of service. Some implementations of QoS policing also allow interface-based policies, which also are considered class of service.

Type of Service: RFC 791 and 795

IP’s original method to provide for traffic is the IP type of service (TOS) field in the IP header which is covered in RFC 791, “Internet Protocol Darpa Internet Program Protocol Specification,” and RFC 795, “Service Mappings.”

The TOS field is eight bits made up of three bits that define precedence, one bit delay, one bit throughput, and one bit for reliability. The remaining two bits were reserved for future use and are set to zero.

Linux Support of TOS

Linux supports setting the TOS bits using filtering under all three packet filtering methods: ipfwadm, ipchains, and netfilter.

Additionally, Linux also can use the appropriate ICMP error messages when a type of service was requested that it should not forward—the network unreachable for the specified IP type-of-service and host unreachable for specified IP type-of-service. Their use, however, should likely just be used within the same autonomous system given that many networks filter out many of the ICMP message types. (Some organizations filter ICMP exclusively.)

Examples of Setting the TOS Bits

The complexity of implementing TOS on Linux is determined by the network design and engineering required in the core network, which will vary depending on the systems supported and complexity. Configuring Linux to set the TOS on packets traversing the Linux router is quite simple after a package that supports configuring the TOS is installed such as ipfwadm, ipchains, or netfilter.

Example with ipchains

Giving priority to web traffic was mentioned at the beginning the this section on QoS, so here is an example of setting the IP TOS for web traffic using ipchains:

/sbin/ipchains -A output -p tcp -d 0/0 80 -j 0x10 

Table 15.3 lists the various values and type of services based upon RFC 1349, “Type of Service in the Internet Protocol Suite” (paragraph 4). The Linux implementation also includes the Must Be Zero bit following the four bits assigned to the TOS for a total of five bits. This is likely one of the most common errors and troubleshooting tasks Linux administrators face when integrating a Linux router into an existing network with TOS support.

As another example, ftp, on the other hand, might need more of an emphasis on reliability, so the following ipchains command would be more appropriate for ftp.

/sbin/ipchains -A output -p tcp -d 0/0 21 -j 0x04 

In Table 15.3 the mnemonics for the various services also are defined. The mnemonic can be used instead of the hexadecimal. For example, this ipchains command is interpreted the same as the preceding command.

/sbin/ipchains -A output -p tcp -d 0/0 21 -j Maximize-Reliability 

ipchains also can inspect the TOS bit to determine what the TOS bit should be mapped to by the packet filter. The parameter for matching this is the -m parameter:

/sbin/ipchains -A output -p tcp -d 0/0 21 -m 0x00 -j Maximize-Reliability 
/sbin/ipchains -A output -p tcp -d 0/0 21 -m 0x02 -j Maximize-Reliability 

Should an ftp session connect to the Linux node and the TOS bits set to 0000 or 0001 (remember the 0001 + 0 binary must be zero bit.), the TOS will be changed to 0x04. If the TOS bits have a 0x08 or 0x10 value then no change will be made to the packet with these rules.

DIFFSERV

As mentioned, DIFFSERV is one of the IETF’s current endeavors to improve quality of service on IP networks—by adding new definition to the interpretation of the TOS bits. The DIFFSERV groundwork has been added to the 2.4 kernel, but the applications to effectively use DIFFSERV are still in development and documentation is very scarce. However, further development of DIFFSERV is likely, (check http://diffserv.sourceforge.net/) so the Linux DIFFSERV is likely the best place to learn of new developments, as well as subscribe to mailing lists covering the Linux implementation of DIFFSERV.

Of course Linux can act as an edge device to a DIFFSERV domain and set the TOS bits according to how the DIFFSERV access router expects to see the bits, which it interprets as DS bits.