Home » QoS » QoS Guidelines For VoIP and Data

QoS Guidelines For VoIP and Data

Implementing QoS VoIP (Design Parameters).
Following are the key QoS requirements for implementing VoIP
1. Voice Traffic has to be marked as DSCP EF
2. Packet Loss should not be more than 1%.
3. One-way latency should not be more than 150 ms
4. One-way Jitter should be less than 30 ms
5.  21 to 320 kbps of guaranteed priority bandwidth is required per call – this depends on the sampling rate, VoIP Codec and L2 media overhead.
VoIP traffic should be marked as DSCP EF (46) and assigned strict-priority servicing at each node.
The voice Quality is directly affected by these 3 QoS quality factors
1. Loss
2. Latency
3 Jitter

Loss:
QoS requirement for VoIP implementation needs that the loss should not be more than 1 % . There are a few ways to conceal the loss and mask the effects of lost VoIP packets.  Packet Loss Concealment (PLC)  is one of such techniques whose implementation depends on the type of the codec.

There are two types of codecs
1. waveform codec
2. frame-based codec

What waveform codecs do is to replay the last received sample with increasing attenuation at each repeat; the waveform does not change much from one sample to the next. This technique can be effective at concealing the loss of up to 20 ms of samples.
In Frame-based codecs, the packetization interval determines the number of frames to be carried in a single packet.
Low Bit Rate, frame-based codecs shuch as G.729 and G.723 use sophisticated PLC techniques that can conceal unto 30-40ms of loss with tolerable quality.

Latency:
The goal is to not have more than 150 ms of one-way, end-to-end (from mouth to ear) delay for telephony applications. This 150ms tagged is specified in ITU standard G.114 .
This delay can extend unto 200 ms without impact on the voice quality.
If the end to end delay becomes too long then conversation begins to sound like the two parties are talking over a satellite link.

Jitter:
Jitter Buffers change the async packet arrivals into sync by turning the variable network delays into constant delays at the end systems.
Late or out of order packets are discarded. Jitter buffers can be Fixed and if a jitter buffer is set too large then there will be more end-to-end delay. If the Jitter Buffer is set to low then buffer underflow or overflows can occur, in underflow the buffer is empty and does not have any packets to be played when codec needs to play out a sample, and in overflow the buffer will be full and will not accommodate the next arriving packet. both of these situations will result in voice quality degradation.
The solution is to implement adaptive jitter buffers which dynamically tune the jitter buffer size to the lowest acceptable value.

End-to-End QoS Network Design: Quality of Service for Rich-Media & Cloud Networks (2nd Edition) (Networking Technology)

Provisioning Guidelines for VoIP Bandwidth.
The bandwidth that VoIP streams consume (in bits per second) is calculated by adding the VoIP sample payload (in bytes) to the 40-byte IP, UDP, and RTP headers plus the Layer-2 overhead, and  multiplying this value by 8 (to convert it to bits), and then multiplying again by the packetization rate (default of 50 packets per second)

Codec @ PPS Packetization Interval Voice Payload in Bytes Bandwidth Per Conversation(Flow) for Different Protocols
Ethernet PPP MLP Frame-Relay with FRF.12
G.711@ 50 PPS 20 ms 160 93 kbps 84 kbps 86 kbps 84 kbps
G.729A @ 50 PPS 20 ms 20 37 kbps 28 kbps 30 kbps 28 kbps
G.711 @ 33 PPS 30 ms 240 83 kbps 77 kbps 78 kbps 77 kbps
G.729A @ 33 PPS 30 ms 30 27 kbps 21 kbps 22 kbps 21 kbps

Call Signaling Traffic:
Call-Signaling traffic should be marked as DSCP CS3 per the QoS Baseline
150 bps (plus Layer 2 overhead) per phone of guaranteed bandwidth is required for voice control traffic; more may be required, depending on the Call-Signaling protocol(s) in use.

Originally, Cisco IP Telephony equipment marked Call-Signaling traffic to DSCP AF31. However, the assured forwarding classes,  were intended for flows that could be subject to markdown and aggressive dropping of marked-down values. Marking down and aggressively dropping Call-Signaling could result in noticeable delay to dial tone (DDT) and lengthy call-setup times.
Therefore, the QoS Baseline changed the marking recommendation for Call-Signaling traffic to DSCP CS3 because Class-Selector code points,  are not subject to such markdown and aggressive dropping as Assured Forwarding Per-Hop Behaviors are.
Most Cisco IP Telephony products use the Skinny Call-Control Protocol (SCCP) for Call-Signaling. Skinny is a relatively lightweight protocol and, as such, requires only a minimal amount of bandwidth protection

Other Call-Signaling protocols include (but are not limited to) H.225 and H.245, the Session Initiated Protocol (SIP), and the Media Gateway Control Protocol (MGCP). Each Call-Signaling protocol has unique TCP and UDP ports and traffic patterns that should be taken into account when provisioning QoS policies for them.

Generic Traffic Types and Summary of their QoS Metric Requirements per Cisco

Voice Traffic
1. Traffic should have constant Bit Rate.
2. One way latency should be less than 150 msec
3. One way Jitter variation should be within 30 msec
4. One way packet Loss should be less than  1%
5. The bandwidth for Voice traffic should be approximately 106 kbps per call
(Refer to the Voice Codec Bandwidth calculator at Cisco.com for more accurate results)
6. The bandwidth for Voice control traffic should be 150 bps + L2 overhead per call.

Implementing QoS For Data. (Design Parameters).
The QoS baseline for Data has 4 main classes of data traffic
1. Best Effort
2. Bulk Data
3. Interactive Data
4. Mission Critical Data

Best Effort Data:

Best Effort class is the default class and all traffic which is not selected for preferential treatment will default to this class.
QoS Guidelines for Best Effort Class:
1. Best-Effort traffic should be marked to DSCP 0.
2. Atleast 25% of the bandwidth should be assigned to this class, as a majority of applications will default to this calss.

Bulk Data:

Build data class is for applications that are relatively non interactive and not drop sensitive. Applications such as FTP, email, DB synchronization or replication fall into this category.
QoS Guidelines for Bulk Data Class:
1. Bulk Data traffic should be marked to DSCP AF11; excess Bulk Data traffic can be marked down by a policer to AF12 or AF13.
2. Bulk Data traffic should have a moderate bandwidth guarantee but should be constrained from dominating a link

Interactive or Transactional Data:

This class includes traffic which is client/server based and messaging traffic.
QoS Guidelines for Interactive and Transactional Class:
1. Transactional Data traffic should be marked to DSCP AF21; excess Transactional Data traffic can be marked down by a policer to AF22 or AF23.
2. Transactional Data traffic should have an adequate bandwidth guarantee for the interactive, foreground operations

Locally Defined Mission Critical Data:

This is locally defined per organizations business requirements and can be different from one organization to another.
QoS Guidelines for Mission-Critical Class:
1. Locally-Defined Mission-Critical Data traffic should be marked to DSCP AF31; excess Mission-Critical Data traffic can be marked down by a policer to AF32 or AF33.
2. Locally-Defined Mission-Critical Data traffic should have an adequate bandwidth guarantee for the interactive, foreground operations


 

Incoming search terms for the article:

Leave a Reply