Voice and Video QOS

[carl_townshend]

Hi All
Can anyone tell me what the recommended way to service voice and video on routers these days, it was normal to put voice in the priority queue and video given a minimum bandwidth guarantee.
I see these days people putting both in the priority queue.
What is recommended?
cheers

[balaji.bandi]

yes it all depends what is the organization looking, most of them do voice as priority since it is very sensitive and depends on UDP.

here is some configuration reference :

https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Aug2014/CVD-CampusWiredLANDesignGuide-AUG14.pdf

[Georg Pauwen]

Hello,

below is a generiv policy using LLQ. You can also use 'bandwidth' instead of 'priority'. The syntax is very much platform and IOS dependent. Also, what you match in your classes depends on the exact type of voice and video traffic. At the bottom a link to Cisco's QoS Best Practices, and a table with the various PHB and DSCP values that correspond to each type of traffic:

class-map match-any VIDEO
match dscp cs4
match dscp af41
!
class-map match-any VOICE
match dscp cs3
match ip dscp ef
!
policy-map QOS_OUT
class VIDEO
priority percent 15
class VOICE
priority percent 15
class class-default
fair-queue
!
interface GigabitEthernet1
service-policy QOS_OUT out

https://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd80295aa1.pdf

[carl_townshend]

does the config you posted put them both into the same priority queue, or is that going into 2 different priority queues?

cheers

[Joseph W. Doherty]

"What is recommended?"

A QoS design that meets your service needs. The references provided by the other posters touch on this, by many looking for QoS solutions look for some "cookie cutter" template. Using such often is easy, but can result in an implementation far from ideal, even perhaps detrimental.

In other words, don't get too hung up on what others do. First, again, many don't really do QoS "right", and second, even if they do, what they have might not be suitable for your needs.

That said, in agreement with the intent of the QoS recommendations, generally you want to place VoIP bearer traffic into a LLQ or PQ, to minimize any delay and/or adding jitter. VoIP signally generally ignores latency or jitter issues, but you want to avoid dropping any of its packets. So, it can often be prioritized like BE traffic although with a sufficient bandwidth guarantee to avoid drops. (BTW, often VoIP signally is placed in LLQ or PQ too. This isn't ideal, but if you have sufficient bandwidth it generally doesn't cause any issues as VoIP signally generally consumes little bandwidth.)

For video, it depends whether it's "realtime", like video conferencing, or streaming, like a "movie". The former should be treated much like VoIP bearer, the latter much like VoIP signalling.

As realtime video generally produces much more data than VoiP, and its packets can be larger, mixing the two kinds of traffic in the same LLQ or PQ might degrade VoIP. If this is an issue, you may need to reduce the MTU of the video (providing a better chance to interleave the two kinds of traffic), or break out the video into a separate queue with LLQ or PQ "like" priority (i.e. "yielding" to VoIP bearer).

Some realtime video may provide a flow for the sound separate from the picture. This allows you to preserve/protect the sound quality while the picture might take some hits. I.e. you treat the video voice like VoIP bearer, but the video picture like video streaming. (The reason the video picture may take "hits", unlike true video streaming, it's not buffered the same.)