I am getting ready to implement QOS for a video conferencing. It will be going across my WAN. The links are all 3mb. Does anyone have some sample configs or reccomendations for me to start with? I have never run any QOS.
Hi Smoove,
You may wish to investigate this online Cisco Press Sample Chapter regarding Quality of Service Design Overview:
QoS Requirements of Video
Two main types of video traffic exist: Interactive-Video (videoconferencing) and Streaming-Video (both unicast and multicast).
Each type of video is examined separately.
Interactive-Video
When provisioning for Interactive-Video (video conferencing) traffic, the following guidelines are recommended:
Interactive-Video traffic should be marked to DSCP AF41; excess videoconferencing traffic can be marked down by a policer to AF42 or AF43.
Loss should be no more than 1 percent.
One-way latency should be no more than 150 ms.
Jitter should be no more than 30 ms.
Assign Interactive-Video to either a preferential queue or a second priority queue (when supported); when using Cisco IOS LLQ, overprovision the minimum-priority bandwidth guarantee to the size of the videoconferencing session plus 20 percent. (For example, a 384-kbps videoconferencing session requires 460 kbps of guaranteed priority bandwidth.)
Because IP videoconferencing (IP/VC) includes a G.711 audio codec for voice, it has the same loss, delay, and delay-variation requirements as voice-but the traffic patterns of videoconferencing are radically different from those of voice.
For example, videoconferencing traffic has varying packet sizes and extremely variable packet rates. These are illustrated in Figures 2-2 and 2-3.
Figure 2-2 Videoconferencing Traffic Packet-Size Breakdown
Figure 2-3 Videoconferencing Traffic Rates (384-kbps Session Example)
The videoconferencing rate is the sampling rate of the video stream, not the actual bandwidth that the video call requires. In other words, the data payload of videoconferencing packets is filled with 384 kbps of voice plus video samples. IP, UDP, and RTP headers (40 bytes per packet, uncompressed) need to be included in IP/VC bandwidth provisioning, as does the Layer 2 overhead of the media in use. Because (unlike VoIP) IP/VC packet sizes and rates vary, the header overhead percentage also varies, so an absolute value of overhead cannot be calculated accurately for all streams. However, testing has shown that a conservative rule of thumb for IP/VC bandwidth provisioning is to assign an LLQ bandwidth equivalent to the IP/VC rate plus 20 percent. For example, a 384-kbps IP/VC stream adequately is provisioned with an LLQ of 460 kbps.
NOTE
The Cisco LLQ algorithm has been implemented to include a default burst parameter equivalent to 200 ms of traffic. Testing has shown that this burst parameter does not require additional tuning for a single IP videoconferencing (IP/VC) stream. For multiple streams, this burst parameter can be increased as required.
Streaming-Video When addressing the QoS needs of Streaming-Video traffic, the following guidelines are recommended:
Streaming-Video (whether unicast or multicast) should be marked to DSCP CS4, as designated by the QoS Baseline.
Loss should be no more than 5 percent.
Latency should be no more than 4 to 5 seconds (depending on the video application's buffering capabilities).
There are no significant jitter requirements.
Guaranteed bandwidth (CBWFQ) requirements depend on the encoding format and rate of the video stream.
Streaming-Video is typically unidirectional; therefore, remote branch routers might not require provisioning for Streaming-Video traffic on their WAN or VPN edges (in the direction of branch to campus).
Nonorganizational Streaming-Video applications (either unicast or multicast), such as entertainment video content, may be marked as Scavenger-DSCP CS1, provisioned in the Scavenger traffic class and assigned a minimal bandwidth (CBWFQ) percentage. For more information, see the "Scavenger Class" section, later in this chapter.
Streaming-Video applications have more lenient QoS requirements because they are not delay sensitive (the video can take several seconds to cue up) and are largely not jitter sensitive (because of application buffering). However, Streaming-Video might contain valuable content, such as e-learning applications or multicast company meetings, in which case it requires service guarantees.
The QoS Baseline recommendation for Streaming-Video marking is DSCP CS4.
An interesting consideration with respect to Streaming-Video comes into play when designing WAN and VPN edge policies on branch routers: Because Streaming-Video is generally unidirectional, a separate class likely is not needed for this traffic class in the branch-to-campus direction of traffic flow.
Nonorganizational video content (or video that's strictly entertainment oriented in nature, such as movies, music videos, humorous commercials, and so on) might be considered for Scavenger service, meaning that these streams will play if bandwidth exists, but they will be the first to go during periods of congestion.
End-to-End QoS Network Design: Quality of Service in LANs, WANs, and VPNs
Tim Szigeti, CCIE No. 9794, is a member of the Enterprise Solutions Engineering Design Team at Cisco Systems.
Christina Hattingh is a member of the technical staff in the Multiservice Customer Edge Business Unit of Cisco Systems.
Hope this helps.
Brad Reese BradReese.Com - Cisco Technical Forums
Brad's reply is your best bet. Unfortunately, you asked the timeless question about where to start with QoS and that subject is huge. It's the equivalent of "How do I build a house?" instead of something like "How do I lay down carpet?" The whole is quite large compared to the parts.
Furthermore, you will find plenty of useful "how to information" on the Cisco Systems Video over IP Forum.
Video conferencing and IP/TV:
Brad Reese Cisco Repair
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.