cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
579
Views
0
Helpful
1
Replies
Beginner

QoS - LLQ w/Policing (Re-marking)

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

------

1 REPLY 1
Highlighted
Engager

Re: QoS - LLQ w/Policing (Re-marking)

You don't need LLQ for video. Just providing guaranteed bandwidth is already sufficient.

This is deduced from my own experience with such conferences over an international WAN.

class Video

bandwidth percent 25

(or something like that.)

You can even police this rate to prevent congestion.

Please also consider using a lower value for LLQ voice. It is almost certain that you don't need 18%, rather use 10% or so.

The lower the better, LLQ is causing considerable drops on other queues if the volume becomes too high.

regards,

Leo

CreatePlease to create content
Content for Community-Ad
FusionCharts will render here