Quality of Service (QoS) is a family of evolving Internet standards that provides ways to give preferential treatment to certain types of IP traffic. With the proper support for QoS along a route, this can ameliorate the effects of variable queueing delays and congestion that contribute to poor network performance. AIX provides host support for QoS to classify outbound traffic into distinct classes of service and to announce and establish resource reservations as requested by client applications.
QoS can be used by an institution to deploy and enforce network policies governing the use of network bandwidth. With QoS, an AIX host can:
The QoS support in AIX provides the following functions:
The QoS subsystem for AIX consists of four components:
Note: The QoS support for AIX is based on a set of evolving Internet standards and draft standards currently under development by the Internet Engineering Task Force (IETF) and its various working groups. This technology will become more consistent and well defined as these standardization efforts progress within the IETF. It is also important to note that QoS is an emerging Internet technology that is just beginning to be deployed within the Internet. There are many benefits of QoS at all stages of deployment. However, true end-to-end services can only be realized when QoS support exists all along a particular route.
The QoS models for the Internet are open standards defined by the IETF. There are two Internet QoS models currently being standardized within the IETF: integrated services and differentiated services. These two Internet QoS models augment the traditional best-effort service model described in RFC 1812.
Integrated Services (IS) is a dynamic resource reservation model for the Internet described in RFC 1633. Hosts use a signaling protocol called Resource ReSerVation Protocol (RSVP) to dynamically request a specific quality of service from the network. QoS parameters are carried in these RSVP messages and each network node along the path installs the parameters to obtain the requested quality of service. These QoS parameters describe one of two currently defined services, guaranteed service and controlled-load service. An important characteristic of IS is that this signaling is done for each traffic flow and reservations are installed at each hop along the route. Although this model is well-suited for meeting the dynamically changing needs of applications, there exist some significant scaling issues that imply it cannot be deployed in the network in which single routers handle many simultaneous flows.
Differentiated Services (DS) removes the per-flow and per-hop scalability issues, replacing them with a simplified mechanism of classifying packets. Rather than a dynamic signaling approach, DS uses bits in the IP type of service (TOS) byte to separate packets into classes. The particular bit pattern in the IP TOS byte is called the DS codepoint and is used by routers to define the quality of service delivered at that particular hop, in much the same way routers do IP forwarding using routing table lookups. The treatment given to a packet with a particular DS codepoint is called a per-hop behavior (PHB) and is administered independently at each network node. When the effects of these individual, independent PHBs are concatenated, this results in an end-to-end service.
Differentiated services is being standardized by an IETF working group, which has defined three PHBs: the Expedited Forwarding (EF) PHB, the Assured Forwarding (AF) PHB group, and the Default (DE) PHB. The EF PHB can be used to implement a low latency, low jitter, low loss, end-to-end service such as a virtual leased line (VLL). AF is a family of PHBs, called a PHB group, that is used to classify packets into various drop precedence levels. The drop precedence assigned to a packet determines the relative importance of a packet within the AF class. It can be used to implement the so-called Olympic service, which consists of three classes: bronze, silver, and gold. The DE PHB is the traditional best-effort service model as standardized in RFC 1812.
The following RFCs and Internet drafts describe the standards on which the AIX QoS implementation is based.
| RFC 2474 | Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers |
| RFC 2475 | An Architecture for Differentiated Services |
| RFC 1633 | Integrated Services in the Internet Architecture: an Overview |
| RFC 2205 | Resource ReSerVation Protocol (RSVP) |
| RFC 2210 | The Use of RSVP with IETF Integrated Services |
| RFC 2211 | Specification of the Controlled-Load Network Element Service |
| RFC 2212 | Specification of Guaranteed Quality of Service |
| RFC 2215 | General Characterization Parameters for Integrated Service Network Elements |
| draft-ietf-diffserv-framework-01.txt, October 1998 | A Framework for Differentiated Services |
| draft-ietf-diffserv-rsvp-01.txt, November 1998 | A Framework for Use of RSVP with DIFF-serv Networks |
| draft-ietf-diffserv-phb-ef-01.txt | An Expedited Forwarding PHB |
| draft-ietf-diffserv-af-04.txt | Assured Forwarding PHB Group |
| draft-rajan-policy-qosschema-00.txt, October 1998 | Schema for Differentiated Services and Integrated Services in Networks |
| draft-ietf-rap-framework-01.txt, November 1998 | A Framework for Policy-based Admission Control[25] |
| draft-ietf-rap-rsvp-ext-01.txt, November 1998 | RSVP Extensions for Policy Control |
Note: QoS is an emerging Internet technology that is just beginning to be deployed within the Internet. There are many benefits of QoS at all stages of deployment. However, true end-to-end services can only be realized when QoS support exists all along a particular route.
QoS for AIX is packaged with bos.net.tcp.server. This fileset must be installed in order to use QoS. To use the RAPI shared library, bos.adt.include must also be installed.
QoS can be started or stopped through SMIT with the smit qos fast path or with the mkqos and rmqos commands.
To disable the QoS subsystem now and on the next system restart:
/usr/sbin/rmqos -B
To enable the QoS subsystem now only:
/usr/sbin/mkqos -N
See the command descriptions for mkqos and rmqos for the startup and removal command flags.
The policyd and rsvpd daemons are configured through the /etc/policyd.conf and /etc/rsvpd.conf configuration files, respectively. These configuration files must be edited to customize the QoS subsystem to the local environment. QoS will not work properly with the supplied example configurations.
The RSVP agent is required if the host is to support the RSVP protocol. The /etc/rsvpd.conf configuration file is used to configure the RSVP agent. The syntax of the configuration file is described in the sample configuration file installed in /etc/rsvpd.conf.
interface 1.2.3.1
interface 1.2.3.2 disabled
interface 1.2.3.3 disabled
interface 1.2.3.4
{
trafficControl
}
rsvp 1.2.3.1
{
maxFlows 64
}
rsvp 1.2.3.4
{
maxFlows 100
}
The above example illustrates a possible RSVP configuration in which the AIX hosts has 4 interfaces (virtual or physical) given by the 4 IP addresses, 1.2.3.1, 1.2.3.2, 1.2.3.3, and 1.2.3.4.
Interface 1.2.3.1 has been enabled for RSVP. However, traffic control has not been specified and incoming RSVP RESV messages do not cause resource reservation within the AIX TCP subsystem. This interface can support a maximum of 64 simultaneous RSVP sessions.
Interfaces 1.2.3.2 and 1.2.3.3 have been disabled. The RSVP agent cannot use this interface to transmit or receive RSVP messages.
Interface 1.2.3.4 has been enabled for RSVP. In addition, it can install resource reservations into the AIX TCP subsystem in response to an RSVP RESV message. This interface may support up to 100 RSVP sessions.
Any other interfaces present on the host but not mentioned explictly in /etc/rsvpd.conf will be disabled.
The policy agent is a required component of the AIX QoS subsystem. The /etc/policyd.conf configuration file is used to configure the policy agent. The syntax of this configuration file is described in the sample configuration file installed in /etc/policyd.conf.
In the following example, a premium service category is created and used in the tcptraffic policy rule. This service category has a maximum rate of 110000 Kbps, a token bucket depth of 10000 bits, and an outgoing IP TOS value of 11100000 in binary. The tcptraffic policy rule gives this premimum service to all traffic with source IP address given by 1.2.3.6, destination address 1.2.3.3, and destination port in the range 0 to 1024. This rule is only in effect from 8:00am to 11:00pm in the local time zone.
ServiceCategories premium
{
PolicyScope DataTraffic
MaxRate 110000
MaxTokenBucket 10000
OutgoingTOS 11100000
}
ServicePolicyRules tcptraffic
{
PolicyScope DataTraffic
Direction Outgoing
Permission Allowed
ProtocolNumber 6 # tcp
TimeOfDayRange 8:00-23:00
SourceAddressRange 1.2.3.6-1.2.3.6
DestinationAddressRange 1.2.3.3-1.2.3.3
DestinationPortRange 0-1024
ServiceReference premium
}
The following statements set up a default service category and use it to restrict the UDP traffic flowing from interfaces 1.2.3.1 through 1.2.3.4 to IP addresses 1.2.3.6 through 1.2.3.10, port 8000.
ServiceCategories default
{
PolicyScope DataTraffic
MaxRate 110000
MaxTokenBucket 10000
OutgoingTOS 00000000
}
ServicePolicyRules udptraffic
{
PolicyScope DataTraffic
Direction Outgoing
Permission Allowed
ProtocolNumber 17 # udp
SourceAddressRange 1.2.3.1-1.2.3.4
DestinationAddressRange 1.2.3.6-1.2.3.10
DestinationPortRange 8000-8000
ServiceReference default
}
The example configuration below can be used to download rules from an LDAP server using the distinguished subtree name,
ou=NetworkPolicies,o=myhost.mydomain.com,c=usto lookup the policies on the LDAP server host.
ReadFromDirectory
{
LDAP_Server 1.2.3.27
Base ou=NetworkPolicies,o=myhost.mydomain.com,c=us
}
The qosstat command may be used to display status information about the installed and active policies in the QoS subsystem. This information may be useful to you in determining where a problem exists if you are troubleshooting your QoS configuration. qosstat can be used to generate the following report.
Action:
Token bucket rate (B/sec): 10240
Token bucket depth (B): 1024
Peak rate (B/sec): 10240
Min policied unit (B): 20
Max packet size (B): 1452
Type: IS-CL
Flags: 0x00001001 (POLICE,SHAPE)
Statistics:
Compliant packets: 1423 (440538 bytes)
Conditions:
Source address Dest address Protocol
192.168.127.39:8000 192.168.256.29:35049 tcp (1 connection)
Action:
Token bucket rate (B/sec): 10240
Token bucket depth (B): 1024
Peak rate (B/sec): 10240
Outgoing TOS (compliant): 0xc0
Outgoing TOS (non-compliant): 0x00
Flags: 0x00001011 (POLICE,MARK)
Type: DS
Statistics:
Compliant packets: 335172 (20721355 bytes)
Non-compliant packets: 5629 (187719 bytes)
Conditions:
Source address Dest address Protocol
192.168.127.39:80 *:* tcp (1 connection)
192.168.127.40:80 *:* tcp (5 connections)