A Handbook for Successful VOIP

8/3/2019 A Handbook for Successful VOIP

1/13

Copyright NetIQ Corporation 2001. 1

Contents

Measuring Call Quality

Objectively...................................2Testing VoIP Call Quality ..........5Getting your Data Network

Ready for VoIP............................6Summary ...................................12Copyright Information .............13

A Handbook forSuccessful VoIPDeployment: Network

Testing, QoS, and Moreby John Q. Walker, NetIQ Corporation

[email protected]

Deploying Voice over IP (VoIP) successfully in a data networkhas some unexpected pitfalls. In previous papers, weveexplored how to do a Voice Readiness Assessment [1] andlooked at focused planning and design tips [2,3]. This paperdescribes changes you can make to improve how a data network

handles VoIP traffic that is, how you can reduce one-waydelay, jitter, and data loss for VoIP traffic, while retaining theperformance of your other business-critical networkapplications.
mailto:[email protected]:[email protected]:[email protected]


2/13


Data networks havent traditionally been re-ported on using a single metric, since there aremany factors to consider. Yet, in thetelephony world, a single number is typicallygiven to rate voice call quality. Voice over IP(VoIP) is a data network application; thequality of VoIP conversations needs a single

metric upon which to benchmark, trend, andtune.

Call quality measurement has traditionallybeen subjective: picking up a telephone andlistening to the quality of the voice. Theleading subjective measurement of voicequality is the MOS (mean opinion score) asdescribed in the ITU (International Telecom-munications Union) recommendation P.800[4]. MOS comes from the telephony worldand is the widely accepted criterion for callquality

In using MOS with human listeners, a groupof people listen to audio and give their opin-ion of the call quality. This certainly workswell, but asking people to listen to calls overand over can be difficult and expensive to setup and execute. You can also guess that itsinconvenient to have a bunch of peoplestanding around each time you make a tuningadjustment. The good news is that the humanbehavioral patterns have been heavilyresearched and recorded. The ITU P.800 stan-dard describes how humans react what score

they would give as they hear audio withdifferent aspects of delay or datagram loss.

Measuring Call QualityObjectively

Considerable progress has been made in es-tablishing objective measurements of callquality. Various standards have beendeveloped:

PSQM (ITU P.861) / PSQM+: PerceptualSpeech Quality Measure

MNB (ITU P.861): Measuring NormalizedBlocks

PESQ (ITU P.862): Perceptual Evaluationof Speech Quality

PAMS (British Telecom): PerceptualAnalysis Measurement System

The E-model (ITU G.107)

PSQM, PSQM+, MNB, and PESQ are part of asuccession of algorithm modifications startingin ITU standard P.861. British Telecomdeveloped PAMS, which is similar to PSQM.The PSQM and PAMS measurements send areference signal through the telephony net-work and then compare the reference signalwith the signal thats received on the otherend of the network, by means of digital signalprocessing algorithms. Several traditionalvoice measurement tools have implementedPSQM and PAMS measurements.

These measurements are good in test labs foranalyzing the clarity of individual devices; forexample, it makes sense to use PSQM to de-

scribe the quality of a telephone handset.Vendors that implement these scoring algo-rithms all map their scores to MOS.

However, these approaches are not really wellsuited to assessing call quality on a data net-work in an enterprise. Theyre based in theolder telephony world, so the data network istreated as a big analog black box. They re-quire invasive hardware probes, which youneed to purchase and deploy before beginningVoIP measurements. The models used are notbased on data network issues, so they cant

map back to the network issues of delay, jitter,and datagram loss. Their output doesntdirect the network staff how to tune. Also,they arent suited to the two-waysimultaneous flows of a real phone conversa-tion, and they dont scale to let you evaluatethe quality of hundreds or thousands ofsimultaneous calls.

ITU recommendation G.107 [5] defines the E-model. The E-model is a complex formula;the output of an E-model calculation is a sin-gle score, called an R factor, derived from

delays and equipment impairment factors.Once an R factor is obtained, it can be mappedto an estimated MOS. R factor values rangefrom 100 (excellent) down to 0 (poor); a MOScan range from 5 down to 1. An estimatedMOS can be directly calculated from the E-models R factor.


3/13


Figure 1. R factor values from the E-model are shown on the left, with their corresponding MOS values on the

right. The likely satisfaction level of human listeners is shown in the middle.

Software, like NetIQs Chariot, test call qualityby generating real-time transport protocol(RTP) streams that mimic VoIP traffic. TheRTP traffic flows between two endpoints in adata network. Each time a test is run,measurements are collected for the one-waydelay time, the number of datagrams lost, thenumber of consecutive datagrams lost, and theamount of variability in the arrival time of thedatagrams (known as jitter). These measure-ments capture in a MOS whats important forvoice quality: how the two people at the twotelephones perceive the quality of their con-versation.

We recommend using the E-model for doing

voice-readiness testing of a data network. TheE-model provides a powerful and repeatableway to assess whether a data network is readyto carry VoIP calls well. The E-model showsus that there are two ways that a digitizedvoice signal is impaired as it passes through adata network. It is impaired by delay and it isimpaired by the equipment that sits betweenthe talker and the listener. For VoIP, thisequipment is the codecs at the two ends andeverything in the data network that sits be-tween them. To improve voice quality, weneed to reduce the impairments that occur.Lets look at each kind of impairment sepa-rately: delay impairment and equipment im-pairment.

Delay Impairments

Four components comprise the total one-waydelay between a talker and a listener:

Propagation DelayThe physical distance between the twoends of the data network determines howlong it takes to propagate a signal betweenthem. This delay is proportional to thespeed of light, that is, the time needed bythe physical signal as it passes throughcopper, optical, or wireless media. Theresmuch more propagation delay betweenNew York City and Sydney than there isbetween New York City and Boston.

Transport DelayEvery networking device between thetalker and listener introduces some delay.It takes time to get through every router,firewall, traffic shaper, and other device

on the route. For some devices, like hubs,this delay is relatively constant. For otherdevices, particularly routers, the delay canincrease as the amount of other traffic andcongestion increase in a network.

Packetization DelayCodecs take time to convert analog signalsto digital packets and vice versa. A high-speed codec like G.711 does this packeti-zation quickly, in about one millisecond.Low-speed codecs take much longer, sincethey do compression to reduce the packet

size. Codecs in the G.723 family introduce67.5 milliseconds of delay as they convertfrom analog signals to digital packets.


4/13


Codec NominalData Rate

(kbps)

PacketizationDelay (ms)

G.711 64.0 1.0

G.729 8.0 25.0

G.723.1m 6.3 67.5

G.723.1a 5.3 67.5

Figure 2. Common voice codecs and the one-way

delay they introduce.

Jitter Buffer DelayWhen theres a lot of variation in the arri-val time of VoIP datagrams, a jitter bufferis introduced to smooth the playback.Rather than converting VoIP packets di-rectly back to analog as they arrive, one ortwo packets are held in memory at thelisteners side. The codec there retrievesits next packet to convert from the jitterbuffer, so it is always one or two packetsbehind. When some delay occurs, thecodec can be playing from the currentpacket in memory, not waiting for apacket to arrive. When excessive delayoccurs, however, packets may need to besimply discarded, to make way for thenext arriving packet.

Packetization and jitter buffer delay; they are

decided at the time you deploy your VoIPequipment. You decide on which codec to useand you decide the size of the jitter buffer.The other two delay components can betuned, to some degree, to reduce the one-waydelay. Although you cant decrease the abso-lute propagation time between New York Cityand Sydney, there may be detours in the routebetween them. You might see that the VoIPdatagrams are not taking a direct routebetween the two locations and tune thenetwork for a more direct route. Transportdelay is the most variable delay component,

and one most amenable to tuning. You canreadily determine the latency at each hopunder low-load conditions and see where themost time is being spent. You can also look atthe latency under heavy-load, high-stressconditions, and tune the amount of delayintroduced by congestion and other traffic.

Equipment Impairments

Many test tools are available in the telephonymarketplace to determine how the quality ofanalog audio signals are impaired. These areuseful when working with the analog portionof the signal path, for example, how good the

handset sounds.Our focus here, though, is on the data net-work. Impairment of the digitized signal in adata network occurs in just two ways. It canoccur in the codecs, when the A-to-D and D-to-A conversions occur, and it can occur be-cause of lost datagrams in the data network.Everything between one codec and the other istreated as one big, analog black box that de-grades the audio signal to some degree.

Codec ImpairmentLow speed codecs impair the quality of

the audio signal much more than high-speed codecs, because they compress thesignal. Fewer bits are sent, so the receiv-ing side does its best to approximate whatthe original signal sounded like. Thefollowing table shows how much thecodec impairment subtracts directly fromthe R factor, which starts at 100 and can godown to 0.

Codec NominalData Rate

(kbps)

Amountsubtracted from

the R factor

G.711 64.0 0

G.729 8.0 11

G.723.1m 6.3 15

G.723.1a 5.3 19

Figure 3. Common voice codecs and their how they

directly impair audio quality.

Data Loss ImpairmentVoIP packets are sent using RTP, the real-

time transport protocol. Although everyRTP datagram contains a sequence num-ber, there isnt enough time to retransmitlost datagrams. Any lost datagram im-pairs the quality of the audio signal.There are two primary reasons why RTPdatagrams are lost in a data network:


5/13


1) theres too much traffic, so datagramsare discarded during congestion

2) theres too much delay variation, sodatagrams are discarded because theyarrive at the listeners jitter buffer toolate or too early

There are a couple of patterns to datagram

loss. The simplest is when theres a more-or-less random loss. Theres general, con-sistent congestion in the network, so oneor two datagrams are lost occasionally.The other pattern is when packets are lostin bursts, say five or more at a time.Humans perceive that bursts of loss im-pair signal quality much more than therandom loss of a packet or two.

So, the issues in improving voice quality comedown to three:

reducing total one-way delay in eachdirection,

reducing delay variation (which leads toexcess jitter, and hence packet loss), and

reducing overall packet loss (especiallybursts of loss).

Testing VoIP CallQuality

The process of examining a data network tosee if its ready to support good-quality voicesignals is called doing a VoIP ReadinessAssessment. A VoIP Readiness Assessmentis usually done in stages, starting with a sim-ple test and getting more advanced:

1. One call: determine the voice quality of asingle call, in two directions

2. Many calls: determine the voice quality ofeach call, during peak call volume

3. Many calls on a busy network: determinethe voice quality of each call, during peakcall volume with heavy background traffic

In assessing your networks readiness forvoice, the first step is to determine how wellthe network handles one VoIP conversation.If the MOS estimate indicates low voicequality, its time to stop and consider yournext steps. Your data network needs to

change before you can deploy VoIP success-fully. Do you want to do the network equip-ment upgrades and tuning necessary to carrythe VoIP traffic well?

If the VoIP assessment indicates the networksready now, youll want to understand itscapacity to see how many calls can be sup-

ported. Ask your local PBX managementteam for details on the peak number telephonecalls, when these occur, and what the call du-ration is. Use these details to create a morecomplex assessment. Replicate the test setupcreated for doing a single call. Run the test fora one-minute period, a few times during theday where your research shows heavy activ-ity. Test five conversations at a time for aminute; what happens to the MOS estimates?Next try ten, then twenty concurrentconversations. Plot the results on a graph; you

should start to see the point where, as thenumber of calls increases, the quality de-creases. Dont kill your data network duringprime time by stress testing its capacity.However, start to form the graphs showinghow many conversations can be supportedwith good quality.

Understand the results at each of the threestages of VoIP Readiness Assessment beforemoving on to the next. Whats the quality ofeach concurrent VoIP conversation? If thequality is low, what underlying network

attribute contributes most to the reducedquality: one-way delay, jitter, random packetloss, and/or bursts of packet loss?

If, after completing the third stage examining the peak number of calls duringheavy network usage the assessment indi-cates the voice quality will be acceptable,youre ready to proceed with your VoIPdeployment.

However, in our experience, its likely yourdata network wont deliver the call quality

you would like. In fact, a recent estimate pre-dicted that 85% of todays router-based datanetworks are not ready for toll-quality VoIPcalls. The rest of this paper describes the stepsneeds to consider for upgrading and tuningthe network.


6/13


Getting your DataNetwork Ready for VoIP

If the call quality you determined in yourVoIP Readiness Assessment is not okay, de-termine what the problems are and wheretheyre located. Whats the biggest cause ofthe poor call quality: one-way delay, jitter,packet loss, or a combination of all three?Where are the most likely bottlenecks?

There are a variety of improvements that canbe made to an existing data network to im-prove the call quality. Choices include addingmore bandwidth, upgrading or replacingexisting network equipment, laying out yournetwork architecture in an improved manner,

reconfiguring or tuning the network for QoS,or a combination of these.

Bandwidth

Bandwidth consumption by VoIP calls ishigher that it appears at first. The G.729codec, for example, has a data payload rate of8 kbps. Its actual bandwidth usage is higherthan this, though. When sent at 30ms inter-vals, its payload size is 30 bytes per datagram.To this add the 40 bytes of RTP header (yes,the header is bigger than the payload) and anyadditional layer 2 headers. For example,Ethernet adds 18 more bytes. Also, there aretwo concurrent G.729 RTP flows (one in eachdirection), so double the bandwidth con-sumption youve calculated so far. Heres atable showing a truer picture of actual band-width usage for four common codecs.

Codec NominalDataRate

(kbps)

DataBytes per

30mspacket

TotalData-gram

Size(bytes)

Combinedbandwidth for2 flows (kbps)

G.711 64.0 240 298 158.93

G.729 8.0 30 88 46.93

G.723.1m 6.3 24 82 43.73

G.723.1a 5.3 20 78 41.60

Figure 4. Common voice codecs and the LAN bandwidth requirements for a two-way VoIP conversation. Total

datagram size includes a 40-byte IP/UDP/RTP header and an 18-byte Ethernet header.

You can see quickly a good rule of thumb:estimate 160 kbps bandwidth usage for eachVoIP conversation using the G.711; estimateabout 50 kbps when using one of the low-speed codecs.

Use the peak number of calls to determine rawbandwidth requirements for concurrent VoIPcalls. If you want to support 10 concurrentVoIP calls using the G.711 codec with no si-lence suppression, youll need about 1.6 Mbpsof bandwidth to support these calls on a given

network segment (10 x 158.93kbps the totalbandwidth consumption of the two RTPflows). Add this additional bandwidth re-quirement to the existing bandwidth usage ofthe network to set the new base requirement.

There are four tuning techniques worth ex-ploring to conserve and ration bandwidth:compressed RTP, silence suppression, framepacking, and call admission control.

Compressed RTP headers save bandwidth byreducing the number of bytes in RTP data-grams. VoIP traffic uses RTP to encapsulatethe speech frames. RTP header compression(called cRTP) is used among routers in thenetwork backbone. It can reduce the 40-byteRTP headers to a tenth of their original size,halving the bandwidth consumed when usinglow-speed codec. In streaming video, in con-trast, the payload is often ten times the size ofthe header, so compression may not be

noticeable. Enable it when theres a link onthe route bandwidth lower than 500 kbps. So,why not always use cRTP? It adds latency,increasing the transport delay component ofthe one-way delay.

Silence suppression saves bandwidth bymaking the payload smaller. In most tele-phone conversations, there are times whenone speaker or the other (or both) are silent.


7/13


During silence, its not necessary to send fullpackets; a much smaller packet can be sent,indicating that is silence during the period. Byenabling silence suppression at each end ofthe conversation, 50% of the payloads cantypically small.

Frame packetization can save bandwidth by

putting multiple packets of audio informationinto one datagram. This means that only oneIP/UDP/RTP header is necessary, instead ofone for each audio packet. Delay is increased,though, since the datagram cant be sent untilmultiple packets have been generated. Also,the loss of a single datagram can mean the lossof multiple audio packets, further eroding thecall quality.

Using call admission control lets you avoidhaving too many concurrent VoIP conversa-tions. If your WAN bandwidth only supports

two VoIP calls well, you want to avoid a thirdcall. Call manager software can limit thenumber of concurrent conversations to a pre-defined number, to avoid overloading slowlinks.

These four techniques may help, but it mayultimately come down to the fact that youneed to have bigger pipes. Look for the slow-est links or the links where there is the mostcontention for bandwidth. Many delay anddata loss problems can be solved by havinglots of available bandwidth, to accommodatethe VoIP conversations and the otherconcurrent network transactions effortlessly.

Equipment Upgrades

Upgrading or replacing your local networkequipment may give you the boost you need,without buying additional bandwidth fromyour service provider. The latest, fastestequipment often can increase bandwidth, de-crease latency, and increase capacity. Here aresome upgrades to consider:

Hubs can often be bottlenecks in a heavily-used LAN. Consider replacing hubs withmodern high-speed switches. Recent switchesare also much better at handling IP multicasttraffic than those of a few years ago; be sure tosee if the combination of old switches and IPmulticast could be massively throttling youravailable LAN capacity.

Routers operate using queues for the arrivingand departing traffic. Routers always seem tofunction better with lots of RAM. Doubling ortripling a routers RAM may be a cost-effectiveupgrade.

Modern hardware-based firewalls have muchhigher capacities than some older, software-

based models. Firewalls are often bottlenecks,greatly increasing transport delay as theyreach their limits.

Network backbones can become the bottle-necks over time. Is the backbone now theplace where traffic slows down during peakusage periods? Is it time to consider the newoptical switches and routers?

Network Architecture

Will laying out the network and the users

differently help improve the key VoIPmeasurements? This is obviously a big step.Consider changing the layout of your datanetwork for situations like these:

Could shorter, more direct routes be taken byVoIP conversations, reducing their propaga-tion and transport delays? For example, doyou have traffic going from New York Citythrough San Diego back to Florida?

Fewer hops can reduce the accumulatedtransport delay. VoIP traffic is much more

sensitive to the number hops than traditionalTCP transactions. Do you have VoIP flowstaking 30 or 40 hops from end to end? Couldthe number of hops be reduced by some re-engineering of the network?

Clustering of traffic patterns means findingout what users are using what network appli-cations, and where theyre located. Is thereunnecessary data traffic flowing on the samelinks as critical VoIP traffic? Could servers bepositioned closer to clients, reducing backbonetraffic? Could firewalls be placed differently?

QoS and Tuning

Network devices and applications havepowerful techniques available for dealing withthe sharing of network resources, collectivelyreferred to as Quality of Service (QoS). QoStechniques work by handling traffic in differ-ent classes differently. Two things have tooccur to make QoS work:


8/13


Classify - What kind of traffic is this?

Handle - How should this traffic betreated?

Networks with no QoS handle all traffic asbest-effort the network devices do theirbest to deliver frames from senders to theirreceivers. But, all traffic is not created equal.

When congestion occurs in a network, shouldsome traffic be given premium treatment forexample, should the payroll data be treatedbetter than VoIP audio traffic?

Also, what is the handling treatment the pre-mium traffic should receive guaranteedbandwidth, a guaranteed route, or higherpriority during congestion? For each class oftraffic, what should occur as it traverses anetwork? Should it be given high priority orlow priority? Should it get a guaranteedamount of bandwidth or guaranteed latency?

During congestion, should it be treated as lesslikely to be discarded? Does it require aguaranteed route across the network?

Configuration changes to enable the handlingare made to network devices at the edges andin the middle of a network. However, theresults of the configuration changes are seenby the end users of the applications. Thiswide separation of cause (configurationchanges) and effect (end-to-end behavior) isone of the challenges of setting up QoSsuccessfully.

Classifying is usually done at the edge of anetwork; handling is usually done in the mid-dle. Decisions about classifying and handlingtraffic are the important business decisionsinvolved with deploying QoS. Lets look atthese a bit more.

Deciding How to ClassifyTrafficNetwork traffic needs to be identified in someway to classify it. For example, some net-worked applications can be readily identifiedbecause they use a unique port number; incontrast, applications which use dynamicports are hard to identify solely by looking atport numbers. Here are seven ways IP trafficcan be classified:

DiffServ/TOS bitsGive marked traffic a certain priority tothe edge and middle of the network?

RSVP signalingReserve resources for a long-runningconnection?

Port numbers and addressesGive applications identified by the portnumbers or network addresses betterhandling?

RTP header informationTreat audio better than video?

Data contentTreat binary data like GIF files better thantext strings?

Data rateTreat low volume traffic better than highvolume?

Buffer sizeGive small frames higher priority thanlarger frames?

Well examine each of these in detail in thissection.

Traffic classification can be done at the edge ofa network, in the middle of a network, or atthe networked applications themselves.

Devices that classify at the network edgeare common today. Edge devices, such astraffic shapers, bandwidth managers, orfirewalls, provide central points of ad-ministration. You can secure the edgedevices and apply a consistent set oftraffic rules at the places where mosttraffic passes.

Traffic classification in the middle of thenetwork is also common, but the devicesusually have less knowledge about thetraffic. Routers, for example, may classifytraffic based on flow rates per connection,queuing conditions, and packet sizes.

End users and applications themselvesrarely are trusted to classify traffic. Iftheyre given a choice, most users wanttheir traffic to receive premium handling.Sophisticated billing methods, that is,ways to charge a premium for traffic given

premium handling, are needed for all net-work users. Thus, applications generallyclassify their own traffic only when theapplications know how to make the rightsettings, their users are trusted in theapplications they use, and all networkdevices on the route honor the applicationsettings.


9/13


DiffServ/TOS Bits in IP Frames

The second byte in the header of every IPframe can be used to mark priority. This byteis known by two different names:

In early TCP/IP specs, it is called theType of Service (TOS) byte, described in

RFC 791. In more recent TCP/IP specs, it is referred

to as the Differentiated Services (DS)field, described in RFC 2474.

Both terms, TOS byte and DS field, refer to thesame eight bits. In both definitions, the lasttwo bits of this byte are reserved, so its onlythe first six bits that are interesting. In theTOS definition, these six bits are separatedinto two three-bit fields. In the DiffServ (DS)definition of this byte, the first six bits are

treated as a codepoint. Three of the sixty-fourpossible bit settings have been defined to date.Although only three codepoints are definedtoday in the RFC, you can set any of the 64possible values.

DS Field DS Codepoint name Description

000000 Best Effort The default setting for most IP

traffic today.

011000 Assured Flow (AF), or

Controlled Load

Intended to classify streaming

traffic.

101000 Expedited Flow (EF), orGuaranteed

Intended to classify high prioritytraffic. Used by VoIP gateways to

mark VoIP traffic.

Figure 5. Codepoint definitions of the DiffServ field. Microsofts term Controlled Load is the same as the IETF

term Assured Flow; Microsofts term Guaranteed is the same as the term Expedited Flow.

The TOS/DiffServ bits are used in variousways to classify network traffic; here are someexamples:

To signal to edge devices

For example, traffic shapers can identify a

particular type of incoming traffic by itsport number, then set the DiffServ bits ineach datagram as it passes the trafficalong.

To explicitly affect the DiffServ priorityhandling in routers

DiffServs Assured Flow and ExpeditedFlow codepoints can be used to markstreaming and high priority traffic,respectively.

To signal precedence to routers

In the router technique known asWeighted Fair Queuing (WFQ), the valueof the precedence bits is multiplied by theeffective bit rate, to increase the priority ofthe marked frames.

Ciscos Voice over IP (VoIP) devices setthe DS field to EF. This is probably theone consensus recommendation of QoSand VoIP the VoIP traffic should have

the DS field set to 101000 in every data-gram and the network devices should beconfigured to handle this setting withhigher priority.

RSVP Signaling

The Resource Reservation Protocol (RSVP)reserves resources to meet requirements forbandwidth, jitter, and delay on a particularconnection through a series of routers.

RSVP adds new IP control flows from end-to-end. These IP frames instruct intermediaterouters to reserve a portion of their resources(bandwidth, queues, and so on). Applicationsuse RSVP by making additional calls to theirunderlying TCP/IP stacks. The TCP/IP stackscommunicate with the first router on theirroute, which, in turn, communicate with theother routers on the route. It takes a while toset up the separate control flow, which itselfcreates extra network traffic.

RSVP is best used within buildings, on a cam-pus, or with a privately-owned WAN. Itworks well when network connections arelong in duration (like streaming video) andwhen only a few connections at a time requirereserved resources.


10/13


RSVP setup is complex at the API and at thedevices in the network. Microsoft offersapplications a way to make RSVPreservations, via its generalized quality ofservice (GQOS) API. GQOS [7] is available onWindows 98, Me, and 2000; it exposes about10 parameters to be used in building a

resource reservation.

Port Numbers and Addresses

DiffServ and RSVP are new contenders in therollout of IP QoS techniques. In contrast, asimpler technique is simply to look at the portnumbers and addresses in a frame to decidehow it should be classified. Many networkdevices, particularly those at the edge of thenetwork, already use some form of inspectionof port number and addresses.

The destination port number is whats used in

most classification decisions. Trafficclassification can also be done based on thesource or destination address in a frame.

Inspect the source address when you wantto classify all the traffic coming from acertain computer. For example, you canuse the source address of the sender ofmulticast streaming traffic to classify itstraffic.

Use the destination address to classify thetraffic going to a certain server, forexample.

RTP Header Information

The real-time transport protocol (RTP) is usedto send data in one direction with noacknowledgment. The 12-byte RTP header,which sits inside a UDP datagram, contains atimestampso the receiver can reconstructthe timing of the original dataand asequence numberso the receiver can dealwith missing, duplicate, or out-of-orderdatagrams. RTP is frequently used forsending streaming audio and video, whetherto one receiver (unicast) or to multiplereceivers (multicast).

The protocol handles the real-timecharacteristics of multimedia applicationswell. Streaming applications differ fromtraditional data applications in the re-quirements they place on the sender, thereceiver, and the network. When streamingaudio or video, its okay to lose some data

but you dont want large gaps (losing data,however, is unacceptable for your payroll dataapplication).

Multimedia applications set the values in theheader of each RTP datagram. One of thosevalues is the RTP Payload Type. Networkdevices use the RTP Payload Type to classify

RTP traffic and hence to handle it differently.For example, you might configure a router togive audio traffic (value MPA, which standsfor MPEG audio) smoother handling thanvideo traffic (value MPV, which stands forMPEG video). There are RTP payload typevalues defined for each of the codecs wevediscussed: PCMU for G.711 in the USA,PCMA for G.711 in Europe, G729 for theG.729 codec, and G723 for the G.723 family ofcodecs.

Data ContentSome modern network devices can look deepinto the data content of frames to decide howit should be classified. They often examineURLs, to decide how to classify Web traffic.

Data Rate

A simple way to classify traffic is by its datarate. For example, a common handlingtechnique known as Weighted Fair Queuing(WFQ) avoids starvation of low-volume trafficby boosting its priority compared to high-

volume traffic.Applications themselves can control how fastdata is sent at two levels of granularity: oneach individual API Send call, or on eachconnection.

Buffer Size

Traffic can be classified by the size of thebuffers used in the data transfer. For example,devices in the middle of a network can beconfigured to give small frames improvedhandling over large frames. This technique is

based on the assumption that small frames arepart of short transactions where responsetime is important whereas large frames areused in file transfers where response time isless important.

Applications can control the buffer size oneach API Send and Receive call. However, thebuffer size on an API Receive call commanddoes not influence the network traffic; it only


11/13


influences how many Receive calls are madeto the protocol stack.

The default buffer size corresponds to thedefault size most frequently used with theprotocol stack on each operating system. ForTCP, its generally around 32K bytes; for UDP,its around 8K bytes.

Deciding How to Handle EachClass of TrafficAfter deciding how the network traffic is to beclassified, you need next to decide how eachclass of traffic is to be handled. Is a given classof traffic of traffic to be given higher priorityor lower priority? Should one class be lesslikely to be discarded than another class?Should classes of traffic get guaranteedamounts of bandwidth or guaranteed latency?

The techniques for handling traffic fall intothree categories, based on queuing, flow rate,or paths:

Queue-basedThe routers on the path manipulate theirqueues of outgoing traffic toaccommodate classes of traffic differently.Examples include RSVP (resourcereservation protocol), WFQ (weighted fairqueuing), LFI (link fragmentation andinterleaving), LLQ (low latency queuing),RED (random early detection), and WRED

(weighted random early detection).Rate-based

Rate-based handling is generally done bytraffic shapers or bandwidth managers atthe edge of a network. They assurecertain classes of traffic flow at a certainrate. Theyre often used to limit traffic toconsume no more than a specifiedamount of bandwidth. For example, youmight limit Web traffic (classified byseeing port number 80) to less than 500kbps of throughput on a given link.

Path-basedSome classes of traffic take preferred pathsthrough an IP network, compared to othertraffic that just takes the best effort path.The most common technique is MPLS(multi-protocol label switching), wheretraffic is identified at the edge of anetwork and forwarded on different pathsdepending on its classification.

Setting up QoS in a NetworkIts surprisingly difficult to get QoS set up tofunction well in a network. Lets look at someof the reasons:

Deciding which traffic is in each class isoften a political decision.

Network IT staff lack of knowledge andexperience.

Much of QoS is new technology and therearent many good tips and techniquesbroadly available.

Many QoS schemes and parameters existtoday.

Each QoS scheme has its own terminologyand tuning peculiarities, which are new tomost network personnel.

There are lots of device interconnections

and interactions.

Many network devices and applicationsare potentially involved. Mismatches indevice setup can occur at any of them.The large cross-product of potentialproblems makes setup particularly error-prone. See some of Ciscos manuals onVoIP and QoS [8] for more details.

QoS handling is imperceptible under lightload.

QoS effects can generally only be observed

against heavy traffic that is, under stressconditions. QoS testing requires acongested network

to detect its behavior,

to see if its configured right,

to show some classes getting im-proved handling,

to see if it still works right aftermaking any change, and

to see if youre getting the premiumhandling you paid for.

Configuring network devices one-at-a-time,by hand, is so error-prone it is essentially outof the question for most large networks.Fortunately, a new set of tools policy-basednetwork management software offers theusability needed to make QoS tenable.


12/13


Summary

The process of getting VoIP deployedsuccessfully on your data network can becomea straightforward decision tree.

Run a VoIP Readiness Assessment. Look

carefully at call quality, from one call to themaximum number of expected calls at peaknetwork usage across a range of locations.

If the call quality is okay and the other trafficis relatively unaffected, great it avoids lots ofcomplexity. Start your VoIP deployment.

If the call quality is not okay, determine whatthe problems are and where theyre located.What is most influencing the poor quality:one-way delay, jitter, packet loss, or acombination of all three? Can a simple change

in the VoIP configuration options, such as thechoice of codec, improve the call qualitysufficiently? Where are the most likelybottlenecks?

Now, look at the costs of making the requirednetwork improvements. Choices includeadding more bandwidth, upgrading orreplacing your existing equipment, laying outyour network architecture in an improvedmanner, reconfiguring or tuning the networkfor QoS, or a combination of these.

This is a just the start of a decision tree for anetwork administrator, because the costs ofthese different choices are not equal. Addingmore bandwidth may be a recurring expense,upgrading the hardware may be a capitalexpense, and QoS may appear to be free, but itusually has a high cost in personnel time.

Look at the costs in as much depth as you canand decide whether you want to proceed withmaking the network changes. Its an iterativeprocess of making the most cost effectiveimprovements a step at a time, then repeatingthe VoIP Readiness Assessment to see ifyoure reaching your goal in terms of call

quality.If your estimate of the costs to make the datanetwork ready for VoIP appear too high, thisis a good time to look at your VoIPdeployment plan again. You should have agood understanding of what it will take, soyou have some choices:

you can decide how to budget its costintelligently at the right time in the future,

you can increase your current budget andproceed considering this a suitable long-

term investment, or you might approach the VoIP deployment

in a stepwise manner, doing some partsnow and some parts later.

About the Author

John Q. Walker II is the director of networkdevelopment at NetIQ Corporation. He was afounder of Ganymede Software Inc., which be-came part of NetIQ in spring 2000. He can bereached [email protected].

Acknowledgments

Gracious thanks to the readers who helpedimprove this paper: Aimee Doyle, ConleySmith, and Carl Sommer.

For More Information

1. Using Chariot to Evaluate Data Network for VoIP Readiness, John Q. Walker and Jeff Hicks, NetIQCorporation, Spring 2001, http://www.netiq.com/products/chr/whitepapers.asp

2. Checklist of VoIP Network Design Tips, John Q. Walker, NetIQ Corporation, April 2001,http://www.netiq.com/products/chr/whitepapers.asp

3. What You Need to Know Before You Deploy VoIP, Scott Hamilton and Charles Bruno, TollyResearch, April 2, 2001, http://www.netiq.com/products/chr/whitepapers.asp

4. ITU-T Recommendation P.800, Methods for subjective determination of transmission quality.

5. ITU-T Recommendation G.107, The E-model, a computational model for use in transmissionplanning.

6. Differentiated Services (DS) field, RFC 2474, http://www.ietf.org/rfc/rfc2474.txt
mailto:[email protected]:[email protected]://www.netiq.com/products/chr/whitepapers.asphttp://www.netiq.com/products/chr/whitepapers.asphttp://www.netiq.com/products/chr/whitepapers.asphttp://www.netiq.com/products/chr/whitepapers.asphttp://www.netiq.com/products/chr/whitepapers.asphttp://www.netiq.com/products/chr/whitepapers.asphttp://www.ietf.org/rfc/rfc2474.txthttp://www.ietf.org/rfc/rfc2474.txthttp://www.ietf.org/rfc/rfc2474.txthttp://www.netiq.com/products/chr/whitepapers.asphttp://www.netiq.com/products/chr/whitepapers.asphttp://www.netiq.com/products/chr/whitepapers.aspmailto:[email protected]


13/13


7. Microsofts Generic Quality of Service (GQOS) spec,http://msdn.microsoft.com/library/default.asp?ShowPane=false&URL=/library/psdk/gqos/qosstart_2cdh.htm

8. Cisco IP Telephony QoS Design Guide, Cisco Systems,http://www.cisco.com/univercd/cc/td/doc/product/voice/ip_tele/avvidqos/avvid.pdf

Copyright InformationNetIQ Corporation provides this document as is without warranty of any kind, either express or implied, including,

but not limited to, the implied warranties of merchantability or fitness for a particular purpose. Some states do not

allow disclaimers of express or implied warranties in certain transactions; therefore, this statement may not apply to

you. This document and the software described in this document are furnished under a license agreement or a non-

disclosure agreement and may be used only in accordance with the terms of the agreement. This document may not

be lent, sold, or given away without the written permission of NetIQ Corporation. No part of this publication may be

reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, or

otherwise, with the prior written consent of NetIQ Corporation. Companies, names, and data used in this document

are fictitious unless otherwise noted. This document could include technical inaccuracies or typographical errors.

Changes are periodically made to the information herein. These changes may be incorporated in new editions of the

document. NetIQ Corporation may make improvements in and/or changes to the products described in thisdocument at any time.

1995-2001 NetIQ Corporation, all rights reserved.

U.S. Government Restricted Rights: Use, duplication, or disclosure by the Government is subject to the restrictions as

set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause of the DFARs

252.227-7013 and FAR 52.227-29(c) and any successor rules or regulations. AppManager, the AppManager logo,

AppAnalyzer, Knowledge Scripts, Work Smarter, NetIQ Partner Network, the NetIQ Partner Network logo, Chariot,

End2End, Pegasus, Qcheck, OnePoint, the OnePoint logo, OnePoint Directory Administrator, OnePoint Resource

Administrator, OnePoint Exchange Administrator, OnePoint Domain Migration Administrator, OnePoint Operations

Manager, OnePoint File Administrator, OnePoint Event Manager, Enterprise Administrator, Knowledge Pack,

ActiveKnowledge, ActiveAgent, ActiveEngine, Mission Critical Software, the Mission Critical Software logo,

Ganymede, Ganymede Software, the Ganymede logo, NetIQ, and the NetIQ logo are trademarks or registered

trademarks of NetIQ Corporation or its subsidiaries in the United States and other jurisdictions. All other company

and product names mentioned are used only for identification purposes and may be trademarks or registered

trademarks of their respective companies.
http://msdn.microsoft.com/library/default.asp?ShowPane=false&URL=/library/psdk/gqos/qosstart_2cdh.htmhttp://msdn.microsoft.com/library/default.asp?ShowPane=false&URL=/library/psdk/gqos/qosstart_2cdh.htmhttp://msdn.microsoft.com/library/default.asp?ShowPane=false&URL=/library/psdk/gqos/qosstart_2cdh.htmhttp://www.cisco.com/univercd/cc/td/doc/product/voice/ip_tele/avvidqos/avvid.pdfhttp://www.cisco.com/univercd/cc/td/doc/product/voice/ip_tele/avvidqos/avvid.pdfhttp://www.cisco.com/univercd/cc/td/doc/product/voice/ip_tele/avvidqos/avvid.pdfhttp://msdn.microsoft.com/library/default.asp?ShowPane=false&URL=/library/psdk/gqos/qosstart_2cdh.htmhttp://msdn.microsoft.com/library/default.asp?ShowPane=false&URL=/library/psdk/gqos/qosstart_2cdh.htm

A Handbook for Successful VOIP

Documents

Transcript of A Handbook for Successful VOIP