8.4. Quality of Service
Quality of Service, or QoS as 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 300 milliseconds, a normal
flow of conversation is possible. When delay exceeds 500
milliseconds, it becomes difficult to avoid interrupting each
other. Beyond one second, normal conversation becomes extremely
awkward.
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.
8.4.1. TCP, UDP, and SCTP
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.
8.4.1.1. Transmission Control
Protocol
The Transmission Control Protocol (TCP) 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 is going to tend to cause more
problems than it solves.
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
paramountbut 20 years of cellular telephony has trained us to
tolerate a few lost packets.
TCP's high processing overhead, state
management, and acknowledgment of arrival work well for
transmitting large amounts of data, but it simply isn't efficient
enough for real-time media communications.
8.4.1.2. User Datagram Protocol
Unlike TCP, 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 get there or not. Since UDP itself does not offer any
kind of guarantee that the data will arrive, it achieves its efficiency by spending very
little effort on what it is transporting.
|
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.
|
|
8.4.1.3. Stream Control Transmission
Protocol
Approved by the IETF as a proposed 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.
Some of the goals of SCTP were:
-
Better congestion-avoidance techniques
(specifically, avoiding Denial of Service attacks)
-
Strict sequencing of data delivery
-
Lower latency for improved real-time
transmissions
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.
8.4.2. Differentiated Service
Differentiated service, or 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.
8.4.3. Guaranteed Service
The ultimate guarantee of QoS is provided by the
PSTN. For each conversation, a 64-kbps channel is completely
dedicated to the callthe 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.
8.4.3.1. MPLS
Multiprotocol Label Switching (MPLS) is 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 to make the best use of network
resources. Additionally, information can be associated with a label
to prioritize packet forwarding.
8.4.3.2. RSVP
MPLS contains no method to dynamically establish
LSPs, but you can use the 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.
8.4.4. Best Effort
The simplest, least expensive approach to QoS is
not to provide it at allthe "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 in this
environment.
|