<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Quality of Service</title><link rel="stylesheet" href="styles.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.69.1" /><link rel="start" href="index.html" title="Asterisk™: The Future of Telephony" /><link rel="up" href="asterisk-CHP-8.html" title="Chapter 8. Protocols for VoIP" /><link rel="prev" href="asterisk-CHP-8-SECT-3.html" title="Codecs" /><link rel="next" href="asterisk-CHP-8-SECT-5.html" title="Echo" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Quality of Service</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="asterisk-CHP-8-SECT-3.html">Prev</a> </td><th width="60%" align="center">Chapter 8. Protocols for VoIP</th><td width="20%" align="right"> <a accesskey="n" href="asterisk-CHP-8-SECT-5.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="asterisk-CHP-8-SECT-4"></a>Quality of Service</h2></div></div></div><p>Quality of Service, or <span class="emphasis"><em>QoS</em></span> as <a id="ch08_qos" class="indexterm"></a>it’s more popularly termed, refers to the challenge of
delivering a time-sensitive stream of data across a network that was
designed to deliver data in an ad hoc, best-effort sort of way. Although
there is no hard rule, it is generally accepted that if you can deliver
the sound produced by the speaker to the listener’s ear within 150
milliseconds, a normal flow of conversation is possible. When delay
exceeds 300 milliseconds, it becomes difficult to avoid interrupting each
other. Beyond 500 milliseconds, normal conversation becomes increasingly
awkward and frustrating.</p><p>In addition to getting it there on time, it is also essential to
ensure that the transmitted information arrives intact. Too many lost
packets will prevent the far end from completely reproducing the sampled
audio, and gaps in the data will be heard as static or, in severe cases,
entire missed words or sentences. Even packet loss of 5 percent can
severely impede a VoIP network.</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="asterisk-CHP-8-SECT-4.1"></a>TCP, UDP, and SCTP</h3></div></div></div><p>If you’re going to send data on an IP-based network, it will be
transported using one of the three transport protocols discussed
here.</p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="asterisk-CHP-8-SECT-4.1.1"></a>Transmission Control Protocol</h4></div></div></div><p>The Transmission Control Protocol (TCP)<a id="I_indexterm8_tt1141" class="indexterm"></a><a id="I_indexterm8_tt1142" class="indexterm"></a> is almost never used for VoIP, for while it does have
mechanisms in place to ensure delivery, it is not inherently in any
hurry to do so. Unless you have an extremely low-latency
interconnection between the two endpoints, TCP will tend to cause more
problems than it solves.</p><p>The purpose of TCP is to guarantee the delivery of packets. In
order to do this, several mechanisms are implemented, such as packet
numbering (for reconstructing blocks of data), delivery
acknowledgment, and re-requesting lost packets. In the world of VoIP,
getting the packets to the endpoint quickly is paramount—but 20 years
of cellular telephony has trained us to tolerate a few lost
packets.<sup>[<a id="asterisk-CHP-8-FN-8" href="#ftn.asterisk-CHP-8-FN-8">113</a>]</sup></p><p>TCP’s high processing overhead, state management, and
acknowledgment of arrival work well for transmitting large amounts of
data, but they simply aren’t efficient enough for real-time media
communications.</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="asterisk-CHP-8-SECT-4.1.2"></a>User Datagram Protocol</h4></div></div></div><p>Unlike TCP,<a id="I_indexterm8_tt1143" class="indexterm"></a><a id="I_indexterm8_tt1144" class="indexterm"></a> the User Datagram Protocol (UDP) does not offer any
sort of delivery guarantee. Packets are placed on the wire as quickly
as possible and released into the world to find their way to their
final destinations, with no word back as to whether they got there or
not. Since UDP itself does not offer any kind of guarantee that the
data will arrive,<sup>[<a id="asterisk-CHP-8-FN-9" href="#ftn.asterisk-CHP-8-FN-9">114</a>]</sup> it achieves its efficiency by spending very little
effort on what it is transporting.</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title"><a id="asterisk-CHP-8-NOTE-45"></a>Tip</h3><p>TCP is a more “socially responsible” protocol because the
bandwidth is more evenly distributed to clients connecting to a
server. As the percentage of UDP traffic increases, it is possible
that a network could become overwhelmed.</p></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="asterisk-CHP-8-SECT-4.1.3"></a>Stream Control Transmission Protocol</h4></div></div></div><p>Approved by the IETF as a proposed<a id="I_indexterm8_tt1145" class="indexterm"></a><a id="I_indexterm8_tt1146" class="indexterm"></a> standard in RFC 2960, SCTP is a relatively new
transport protocol. From the ground up, it was designed to address the
shortcomings of both TCP and UDP, especially as related to the types
of services that used to be delivered over circuit-switched telephony
networks.</p><p>Some of the goals of SCTP were:</p><div class="itemizedlist"><ul type="disc"><li><p>Better congestion-avoidance techniques (specifically,
avoiding Denial of Service attacks)</p></li><li><p>Strict sequencing of data delivery</p></li><li><p>Lower latency for improved real-time transmissions</p></li></ul></div><p>By overcoming the major shortcomings of TCP and UDP, the SCTP
developers hoped to create a robust protocol for the transmission of
SS7 and other types of PSTN signaling over an IP-based network.</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="asterisk-CHP-8-SECT-4.2"></a>Differentiated Service</h3></div></div></div><p>Differentiated service, or<a id="I_indexterm8_tt1147" class="indexterm"></a> DiffServ, is not so much a QoS mechanism as a method by
which traffic can be flagged and given specific treatment. Obviously,
DiffServ can help to provide QoS by allowing certain types of packets to
take precedence over others. While this will certainly increase the
chance of a VoIP packet passing quickly through each link, it does not
guarantee anything.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="asterisk-CHP-8-SECT-4.3"></a>Guaranteed Service</h3></div></div></div><p>The ultimate guarantee of QoS is provided by the PSTN. For each
conversation, a 64 Kbps channel is completely dedicated to the call; the
bandwidth is guaranteed. Similarly, protocols that offer guaranteed
service can ensure that a required amount of bandwidth is dedicated to
the connection being served. As with any packetized networking
technology, these mechanisms generally operate best when traffic is
below maximum levels. When a connection approaches its limits, it is
next to impossible to eliminate degradation.</p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="asterisk-CHP-8-SECT-4.3.1"></a>MPLS</h4></div></div></div><p>Multiprotocol Label Switching (MPLS) is<a id="I_indexterm8_tt1148" class="indexterm"></a><a id="I_indexterm8_tt1149" class="indexterm"></a> a method for engineering network traffic patterns
independent of layer-3 routing tables. The protocol works by assigning
short labels (MPLS frames) to network packets, which routers then use
to forward the packets to the MPLS egress router, and ultimately to
their final destinations. Traditionally, routers make an independent
forwarding decision based on an IP table lookup at each hop in the
network. In an MPLS network, this lookup is performed only once, when
the packet enters the MPLS cloud at the ingress router. The packet is
then assigned to a stream, referred to as a Label Switched Path (LSP),
and identified by a label. The label is used as a lookup index in the
MPLS forwarding table, and the packet traverses the LSP independent of
layer-3 routing decisions. This allows the administrators of large
networks to fine-tune routing decisions and make the best use of
network resources. Additionally, information can be associated with a
label to prioritize packet forwarding.</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="asterisk-CHP-8-SECT-4.3.2"></a>RSVP</h4></div></div></div><p>MPLS contains no method to dynamically establish LSPs, but you
can use the <a id="I_indexterm8_tt1150" class="indexterm"></a><a id="I_indexterm8_tt1151" class="indexterm"></a>Reservation Protocol (RSVP) with MPLS. RSVP is a
signaling protocol used to simplify the establishment of LSPs and to
report problems to the MPLS ingress router. The advantage of using
RSVP in conjunction with MPLS is the reduction in administrative
overhead. If you don’t use RSVP with MPLS, you’ll have to go to every
single router and configure the labels and each path manually. Using
RSVP makes the network more dynamic by distributing control of labels
to the routers. This enables the network to become more responsive to
changing conditions, because it can be set up to change the paths
based on certain conditions, such as a certain path going down
(perhaps due to a faulty router). The configuration within the router
will then be able to use RSVP to distribute new labels to the routers
in the MPLS network, with no (or minimal) human intervention.</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="asterisk-CHP-8-SECT-4.4"></a>Best Effort</h3></div></div></div><p>The simplest, least expensive approach to QoS is not to provide it
at all—the “best effort” method. While this might sound like a bad idea,
it can in fact work very well. Any VoIP call that traverses the public
Internet is almost certain to be best-effort, as QoS mechanisms are not
yet common<a id="I_indexterm8_tt1152" class="indexterm"></a>
in this environment.</p></div><div class="footnotes"><br /><hr width="100" align="left" /><div class="footnote"><p><sup>[<a id="ftn.asterisk-CHP-8-FN-8" href="#asterisk-CHP-8-FN-8">113</a>] </sup>The order of arrival is important in voice communication,
because the audio will be processed and sent to the caller ASAP.
However, with a jitter buffer the order of arrival isn’t as
important, as it provides a small window of time in which the
packets can be reordered before being passed on to the
caller.</p></div><div class="footnote"><p><sup>[<a id="ftn.asterisk-CHP-8-FN-9" href="#asterisk-CHP-8-FN-9">114</a>] </sup>Keep in mind that the upper-layer protocols or applications
can implement their own packet-acknowledgment systems.</p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="asterisk-CHP-8-SECT-3.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="asterisk-CHP-8.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="asterisk-CHP-8-SECT-5.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Codecs </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Echo</td></tr></table></div><div xmlns="" id="svn-footer"><hr /><p>You are reading <em>Asterisk: The Future of Telephony</em> (2nd Edition for Asterisk 1.4), by Jim van Meggelen, Jared Smith, and Leif Madsen.<br />
This work is licensed under the <a href="http://creativecommons.org/licenses/by-nc-nd/3.0/">Creative Commons Attribution-Noncommercial-No Derivative Works License v3.0</a>.<br />
To submit comments, corrections, or other contributions to the text, please visit <a href="http://oreilly.com/catalog/9780596510480/">http://www.oreilly.com/</a>.</p></div></body></html>
