QoS Requirements for Voice, Video, and Data

The next step in the process is to identify the detailed requirements for the classes you would create as part of the QoS framework. These characteristics are well defined, and the process involved in their identification is the critical component to ensuring a consistent approach.

To achieve such values, enterprises and service providers must cooperate and be consistent in classifying, provisioning, and integrating their respective QoS solutions.

Additionally, the service provider's network must support a bare minimum of three classes at all interfaces. This is to ensure that the enterprise need not modify or rework its policy to map to the SP policy needlessly or carry the classes within its own classes transparently. These classes must include a real-time class using LLQ, a high-priority data class with CBWFQ's "minimum bandwidth," and a best-effort class.

Four or five classes are preferred, with the minimum requirements for an LLQ class and all but one of the remaining classes supporting minimum bandwidth.

QoS requirements and high-level recommendations for voice, video, and data are outlined in the following sections.

QoS Requirements for Voice

Voice calls, either one-to-one or on a conference connection capability, require the following:

• 150 ms of one-way latency from mouth to ear (per the ITU G.114 standard)

• 30 ms jitter

• 1 percent packet loss

• 150 bps (plus Layer 2 overhead) per phone of guaranteed bandwidth for voice control traffic

The choice of codec has impacts in many areas. The most important is the capacity planning on the network, because the bandwidth consumed in different codecs varies.

When exploring the details of these needs in their work on tight IP SLA, John Evans and Clarence Filsfils wrote that G.114 states that 150 ms of end-to-end one-way delay does not cause a perceivable degradation in voice quality for most use of telephony.

These targets typically include a U.S. coast-to-coast call (equivalent to a Pan-European call) of 6000 km at a propagation speed of 200.000 km/sthus, 30 ms.

Some carriers try to push to the 100-ms target (excellent: 70 ms without propagation).

A usual target is 150 ms (good: 120 ms without propagation).

Enterprise VoIP networks tend to have a looser target250 ms (a decent limit: 220 ms without propagation).

It is also recommended that you look at the consumption of Layer 2 overhead; an accurate method for provisioning VoIP is to include the Layer 2 overhead. Layer 2 overhead includes preambles, headers, flags, cyclic redundancy checks (CRCs), and ATM cell padding. When Layer 2 overhead is included in the bandwidth calculations, the VoIP call bandwidth needs translate to the requirements shown in Table 5-3.

Table 5-3. VoIP Bandwidth Reference Table

Codec	Sampling Rate	Voice Payload in Bytes	Packets per Second	Bandwidth per Conversation
G.711	20 ms	160	50	80 kbps
G.711	30 ms	240	33	74 kbps
G.729A	20 ms	20	50	24 kbps
G.729A	30 ms	30	33	19 kbps

A more accurate method for the provisioning is to include the Layer 2 overhead in the bandwidth calculations, as shown in Table 5-4.

Table 5-4. VoIP Bandwidth Needs with Layer 2 Overhead

Codec	801.Q Ethernet + 32 Layer 2 Bytes	MLP + 13 Layer 2 Bytes	Frame Relay + 8 Layer 2 Bytes	ATM + Variable Layer 2 Bytes (Cell Padding)
G.711 at 50 pps	93 kbps	86 kbps	84 kbps	104 kbps
G.711 at 33 pps	83 kbps	78 kbps	77 kbps	84 kbps
G.711 at 50 pps	37 kbps	30 kbps	28 kbps	43 kbps
G.711 at 33 pps	27 kbps	22 kbps	21 kbps	28 kbps

Sample Calculation

The following calculations are used to determine the inputs to the planning of voice call consumption:

total packet size = (L2 header: MP or FRF.12 or Ethernet) + (IP/UDP/RTP header) + (voice payload size)

pps = (codec bit rate) / (voice payload size)

bandwidth = total packet size * pps

For example, the required bandwidth for a G.729 call (8-kbps codec bit rate) with cRTP, MP, and the default 20 bytes of voice payload is as follows:

total packet size (bytes) = (MP header of 6 bytes) + (compressed IP/UDP/RTP header of 2 bytes) + (voice payload of 20 bytes) = 28 bytes

total packet size (bits) = (28 bytes) * 8 bits per byte = 224 bits

pps = (8-kbps codec bit rate) / (160 bits) = 50 pps

Note

160 bits = 20 bytes (default voice payload) * 8 bits per byte

bandwidth per call = voice packet size (224 bits) * 50 pps = 11.2 kbps

QoS Requirements for Video

The requirements for streaming video, such as IP multicast, executive broadcasts, and real-time training activities, are as follows:

• Four to 5 seconds of latency allowable (depending on the video application's buffering capabilities). No significant jitter requirements.

• Two percent packet loss permissible. Bandwidth required depends on the encoding and the rate of the video stream.

• Video content distribution such as video on demand being replicated to distributed content engines.

• Delay- and jitter-insensitive.

• Large file transfers (traffic patterns similar to FTP sessions).

• Restrict to distribution to less-busy times of day.

• Provision as "less-than-best-effort" data.

The requirements for videoconferencing can be applied as either a one-to-one capability or a multipoint conference.

• 150 ms of one-way latency from mouth to ear (per the ITU G.114 standard).

• 30 ms jitter.

• 1 percent packet loss.

• I-Frames are full-frame samples, whereas P and B frames are differential (or delta) frames. Videoconferencing shares the same latency, jitter, and loss requirements as voice but has radically burstier and heavier traffic patterns.

  A 384-kbps stream can take up to 600 kbps at points rather than provisioning the stream + 60 percent (to accommodate the occasional 600-kbps burst). The video stream includes an additional 20 percent of bandwidth with a burst allowance in the LLQ of 30,000 bytes per 384-kbps stream, as shown in Figure 5-13:

  • Provision LLQ to stream + 20 percent.

    For example, 384-kbps stream 460-kbps LLQ

  • Figure 5-13. Video Stream Sequence

    

    
    

    QoS Requirements for Data

    Following the earlier discussion about the application of traffic identification, there are a few key points to remember about classifying data traffic:

    • Profile applications to get a basic understanding of their network requirements.

    • Perform capacity planning to ensure an adequate bandwidth baseline.

    • Use no more than four separate data traffic classes:

      - Transactional data (mission-critical) ERP, transactional, and high-priority internal applications
      
      

      - Bulk data (guaranteed-bandwidth) Streaming video, messaging, and intranet
      
      

      - Best-effort (the default class) Internet browsing, e-mail, and unclassified applications
      
      

      - Scavenger (less-than-best-effort) FTP, backups, and noncritical applications
      
      

    • Minimize the number of applications assigned to the transactional and bulk data classes (three or fewer are recommended).

    • Use proactive provisioning polices before reactive policing policies.

    These requirements for the data classes are guidelines. They need to take into account many different factors, including the service provider. They must be able to support the number of classes required by the enterprise. As such, they may affect the decision process in the policy's creation.

    Governance plays a key role in identifying and classifying applications. By building a governance checkpoint in the development of new applications, a lot of cycles can be reduced in determining an application's bandwidth needs and its impact on network requirements. The process can pinpoint whether the new application will lead to any network upgrades as well as determine a baseline for the application, which can lead to predictive planning on an incremental yearly basis of adding the application to the network. It allows for better planning, thereby removing the challenge that can be created because of bottlenecks or scaling issues, and the key tenant of running the network as a fairly used business asset.

    A critical factor in the service provider delivery is the SLA, affecting the ability to support delay-sensitive classes, as seen in voice and video requirements. In some cases, other factors preclude the service provider's ability to deliver an SLA against these requirements, such as the geographic location of sites and the interconnections over the service provider network.

    For example, suppose you have a site in a geographically remote location that has a large propagation delay imposed on it because of its location. It may not be possible to meet the requirements for delivery of real-time services to its location. In such cases, there is a trade-off between what is possible for the majority of the corporate sites and that of the remote geographies and their interconnection capability to the rest of the network.