Putting Voice and video in priority queue per Medianet?

[jkeeffe]

In several places in Medianet documentation, Campus QoS Design At-a-Glance for instance, the recommendation is to put not only voice (EF) but also Broadcast Video (CS5) and Realtime Interactive Video (CS4) in the Priority Quese, taking no more than 33%.

Doesn't this have the potential of large video packets affecting voice calls especiall of lots of video packets enter the queue between voice packets? Doesn't the priority queue handle all packets the same? Or does it destinguish between EF and other markings and give more priority to voice?  That doesn't make sense.

[szigeti]

This is correct (voice and video are recommended to be serviced by a strict priority queue in medianet campus networks). While the concern noted above (of video packets affecting voice if serviced by the same PQ) may be relevant in some WAN/VPN scenarios it's not as significant in a campus context.

A few points may help clarify the reasons behind this recommendation:

1) The main reason for campus QoS policies is to control--not latency (which is fixed) nor jitter (which is negligible in GE/10GE campus networks)--but packet loss. As pointed out in the first paragraph of the referenced document (Medianet Campus QoS At-A-Glance):

http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampusaag.html

The primary role of QoS in medianet campus networks is not to control latency or jitter (as it is in the WAN/VPN), but to manage packet loss. In GE/10GE campus networks, it takes only a few milliseconds of congestion to cause instantaneous buffer overruns resulting in packet drops. Medianet applications—particularly HD video applications—are extremely sensitive to packet drops, to the point where even 1 packet dropped in 10,000 is discernable by the end-user.

2) The recommendation actually originates--not from Cisco, but--from RFC 4594, which states that Broadcast Video and Realtime Interactive flows MAY be provisioned with a EF PHB (i.e. a strict priority queuing service)

3) Flows assigned to the PQ (voice and/or video) are all recommended to all be controlled by Admission Control mechanisms, which will prevent the queue from overrunning and causing drops

4) Since typical Catalyst switching platforms have a limited number of hardware queues (such as 4 or 8), assigning such realtime and highly-drop sensitive flows into other non-PQs may introduce drops which can be noticed by end users; this is especially true if other contending flows assigned to the same queue are unbounded (i.e. not goverened by Admission Control mechanisms)

5) In the end, it's important to keep in mind that this is simply a design recommendation--not a mandate. It's beneficial to be aware of the considerations and tradeoffs involved; however, if an administrator prefers to assign these flows to a non-PQ, that's their perogative.

HTH.

-tim