Disabling WRED

[mats.brynolf]

Disabling WRED

I'm running QoS on my 6509 with WS-X6748-GE-TX which I'm only running IPTV (UDP stream) in queue 2 marked as af41, nothing else.

I don't see any point in running WRD since I'm not competing with any other traffic in that queue. Should I disable WRED on queue 2 with [no wrr-queue random-detect 2] or should I leave it on with [wrr-queue threshold 2 100 100 100 100 100 100 100 100]

[Davy Ad]

hi ,

I will advice you to leave it on in case you need it in future , since you said you are not competing with any other traffic in that queue.

HTH

DAK

[johnlloyd_13]

i agree with dak, i would also say just leave it as it is. you don't want to use tail-drop when congestion occurs. you still have your class-default traffic (routing update traffic, snmp, etc) to compete with for interface bandwidth (also consider this constraint, if it's low or high-speed link)

[Joseph W. Doherty]

Generally, WRED is a negative, not a benefit, to most non-TCP traffic. The reason being, the purpose of early drop it to indicate to a flow to slow its tranmission rate before tail drop. Most non-TCP flows do not ramp-up/down their tranmission rates based on drops.

With typical video streaming traffic such as IPTV, you want to avoid any drops, although since its not "real-time", it usually continues to work well even with queuing delays (due to application stream buffering). I.e. insure queuing priority is such that IPTV's average bandwidth is provided, increase queue depths, if necessary, to avoid IPTV queuing drops.

PS:

Not certain without reviewing 6748 QoS features, but the card might not support actual WRED but WTD instead. If true, you sill want to avoid drops for this type of traffic.

[mats.brynolf]

Thanks for all good feedback.

Yes, packet drops is definitely something we want to avoid with IPTV. So I'm going to run with wrr-queue threshold 2 100 100 100 100 100 100 100 100 to ensure no packets gets dropped, but still have WRED enabled for future needs.

Cheers