Hey folks,
I'm trying to decide which implementation is more applicable for my enviornment. Here is the background:
I work in an organization which uses a fair amount of event based video. Video would be considered a critical application. With the advent of new codecs and encoder/decoders I'm worried that placing a max bandwidth (under congestion) on an LLQ Video class might cause issues if we have an unexpected increase in video surpassing bandwidth limitations (think about 1080p under congestion).
I'm considering three possible solutions for the Video class (though I think one may not be supported):
------
Option 1: Running two priority queues, one Voice one Video:
class Voice
priority percent 18
class Video
priority percent 15
With this option you will impose a hard-limit on Video (and we don't have CAC capability) and so undercongestion anything above 15% will be tail dropped. It is possible to burst the 15% using the high end HD codecs and using multiple video systems (no unified CAC).
------
Option 2: Running 1 priority queue for voice and then a normal class for Video w/DSCP mark down.
class Voice
priority percent 18
class Video
police cir percent 15
conform-action transmit
exceed-action set-dscp-transmit 42
class class-default
fair-queue
random-detect dscp-based
With this option, under congestion, you guarentee 15% minimum bandwidth to video but provide for DSCP re-marking down into the class-default above that rate--so if you burst the 15% for the duration of a teleconference... you likely will not drop Video traffic (AF41 will be rather high in the class-default). Unfortunatley the 15% is not LLQ and therefore is scheduled statistically along with all other queues. I understand this solution emulates PQ QoS but using DSCP-WRED it's a little more difficult to completely starve the lower DSCP traffic.
------
Option 3 (IS THIS EVEN SUPPORTED?): Running 2 priority queues, one for Voice one for Video and imposing a policing marker on the Video LLQ.
class Voice
priority percent 18
class Video
priority percent 16
police cir percent 15
conform-action transmit
exceed-action set-dscp-transmit 42
class class-default
fair-queue
random-detect dscp-based
With this option (If it's even supported) then you could theoretically police to a specified rate while still benefitting from LLQ scheduling. It seems to be a compromise of the two. The priority percent for Video is 16 intentially so that the 15% policer would be activated first (if it works in this manner).
Does anyone know if this is supported and/or what the ramifications are?
Any advice or recommendations are welcome.
-Jeremy
------
