Differentiated Services (DiffServ) was invented to provide a simple and scalable quality of service (QoS) mechanism for IP networks. Differentiated Services can, for example, be used to provide low latency for delay-sensitive network traffic such as voice while providing simple best-effort service to other services such as web traffic or file transfer.
This showcase presents an example network that employs DiffServ to provide preferential service to voice over other types of traffic.
About Differentiated Services¶
The INET User’s Guide, among many other resources, contains a good overview of Differentiated Services. If you are unfamiliar with the concept, we recommend you to read that first, because here we provide a summary only.
Differentiated Services classifies traffic entering a DiffServ domain into a limited number of forwarding classes, and encodes the forwarding class into the 6-bit DSCP field of the IP header. The DSCP field will then determine the treatment of packets (resource priority and drop priority) at intermediate nodes. In theory, a network could have up to 64 (i.e. 2^6) different traffic classes using different DSCPs. In practice, however, most networks use the following commonly defined per-hop behaviors:
Default PHB typically maps to best-effort traffic.
Expedited Forwarding (EF) PHB is dedicated to low-loss, low-latency traffic.
Assured Forwarding (AF) PHBs give assurance of delivery under prescribed conditions; there are four classes and three drop probabilities, yielding twelve separate DSCP encodings from AF11 through AF43.
Class Selector PHBs provide backward compatibility with the IP Precedence field.
As EF is often used for carrying VoIP traffic, we’ll also configure our example network to do that.
We will simulate one direction of a VoIP telephone call over the Internet while background traffic is present. Background traffic will be heavy enough to cause congestion in the first-hop router and impair voice quality at the receiver. Then we will use DiffServ to prioritize voice over background traffic to improve voice quality and reduce latency.
The following image shows the layout of the network:
In our setup,
voipPhone1 will transmit VoIP packets to
client will generate background traffic towards
internet node represents the Internet. We set the capacity of the link
internet deliberately low, to 128kbps,
so we can more easily saturate it and demonstrate the effects of congestion on voice quality.
To make the example more realistic,
voipPhone1 will transmit the actual
contents of an audio file as VoIP traffic, and
voipPhone2 will record the
received audio into a WAV file. By playing back the WAV file produced by the
simulation, we can directly assess voice quality.
The background traffic will be constant bit rate UDP traffic. Note that we use UDP instead of TCP because congestion control algorithms present in TCP make it difficult to cause congestion with it.
Configuration and Behavior¶
The showcase contains three different configurations:
VoIP_WithoutQoS: The queue in the router’s PPP interface is overloaded and packets are dropped.
VoIP_WithPolicing: The VoIP traffic is classified as EF traffic and others as AF. AF traffic is rate limited using Token Bucket to 70% of the link’s capacity.
VoIP_WithPolicingAndQueuing: This is the same as the previous configuration, except the router’s queue is configured so that EF packets are prioritized over other packets, so lower delays are expected.
The router’s PPP interface contains the key elements of Differentiated
Services in this network: a queue (
queue) and a traffic conditioner (
If both of them are used, the layout of the interface looks like the following:
configurations, INET’s TrafficConditioner module is used in the
router’s PPP interface to achieve the required policing.
In TrafficConditioner, the
mfClassifier submodule is used for
separating packets of different flows for marking with different DSCP values.
It contains a list of filters that identifies the flow and determines their classes.
Each filter can match the source and destination address, IP protocol
number, source and destination ports, or ToS of the datagram. The first
matching filter determines the index of the out gate. If no matching
filter is found, then the packet will be sent through the
gate. The filters that are used in this showcase can be found in the
<filters> <filter destAddress="voipPhone2" protocol="udp" destPort="1000" gate="0"/> <filter destAddress="server" protocol="udp" destPort="5001" gate="1"/> <filter destAddress="server" protocol="udp" destPort="5002" gate="2"/> </filters>
For example, the VoIP packets, which can be recognized by their
voipPhone2 and UDP destination port 1000, are
marked as EF traffic.
The DSCP field of the packets is then set by the modules named
differentiated handling of the marked packets is then achieved by
metering the traffic with the token bucket based meters
defaultMeter, and dropping or reclassifying packets that do not
conform to the traffic profile. In particular, excess AF traffic will be
sent to the
dropper module. Metering parameters are configured in
[Config WithPolicing] description = "Diffserv traffic conditioning is turned on in the ppp interface of the router" **.router.ppp.egressTC.typename = "DiffservTrafficConditioner" **.efMeter.cir = "70%" **.efMeter.cbs = 50KiB **.defaultMeter.cir = "30%" **.defaultMeter.cbs = 2KiB **.defaultMeter.ebs = 4KiB
DiffservQueue, offered by INET, is an example queue that can be used
in interfaces of Differentiated Services core and edge nodes to support
AFxy and EF per-hop behaviors. The incoming packets are first classified
classifier module according to their DSCP field previously
set in the traffic conditioner. EF packets - these are the VoIP packets
in this case - are stored in a dedicated queue, and served first when a
packet is requested. Because they can preempt the other queues, the rate
of the EF packets should be limited to a fraction of the bandwidth of
the link. Limiting is achieved by metering the EF traffic with a token
bucket meter and dropping packets that do not conform to the traffic
profile configured in the
[Config WithQueueing] description = "A DiffservQueue is added to the ppp interface of the router" **.router.ppp[*].ppp.queue.typename = "DiffservQueue" **.router.ppp.ppp.queue.interfaceTableModule = "^.^.^.interfaceTable" **.router.ppp[*].ppp.queue.efMeter.cir = "70%" **.router.ppp[*].ppp.queue.efMeter.cbs = 5000B
We examine the results of the three different configurations listed above.
As a reference, you can listen to the original audio file by clicking the play button below:
As expected, the quality of the received sound using the
VoIP_WithoutQoS configuration is very low:
The jaggedness in the received audio is because approximately half
of the VoIP packets sent by
voipPhone1 are dropped by DropTailQueue
in the output interface of the router.
The delay of the VoIP packets also is very high, approximately 2.5 seconds, which is way too much compared to a real phone call. The following plot shows the delay of each VoIP packet:
The dropouts you hear can also easily be observed if we zoom into the timeline of the received audio using Audacity:
With Traffic Policing¶
In this configuration, we use a traffic conditioner inside the router’s PPP interface. The following (edited) video, captured from the simulation, shows the classification and the differentiated handling of the packets in the traffic conditioner.
We can see that VoIP packets (
SILENCE) are classified as
EF traffic, while the packets generated by
client are classified as
AF traffic. As a result, the data rate of the VoIP traffic increases and
no VoIP packets are dropped.
The changes result in better sound quality. Dropouts can now only be observed at the beginning of the recording:
The following plot shows the delay of the VoIP packets:
Although the delay of the packets is much less than it was with the previous configuration (0.3s instead of 2.5s), it is still very high for IP telephony.
The dropout problem that was present throughout the whole transmission using the first configuration is successfully eliminated, as we can see if we take a look at the audio track:
With Traffic Policing and Priority Queuing¶
VoIP_WithPolicingAndQueuing configuration, the router’s queue
is configured to prioritize EF packets over other traffic.
The following video shows how the different types of packets are handled:
Note that the
priority module always prefers
efQueue; it only takes packets
from the other queues (via
efQueue is empty.
The fact that EF packets face shorter queues and have priority reduces their latency. Some delay still remains, of course, but the best audio quality could be reached with this configuration. The initial dropouts that were present in the previous configuration are almost inaudible now.
As seen from the next plot, the delay of voice packets has been reduced to about 0.11s: