[rbak-nsp] Strict Queuing Vs. Weighted Queuing

Blake Willis blake at ibrowse.com
Sat Nov 9 13:00:21 EST 2013


On 09.11.2013 18:00, redback-nsp-request at puck.nether.net wrote:

> We are going to provide some sort of services to our PPPoE subscribers 
> which
> HTTP browsing has higher priority over HTTP download. We managed to 
> DSCP
> mark the packets. So for example HTTP browsing has mark AF41 and HTTP
> download has mark AF21. We use four-queue approach for QoS policy pwfq 
> which
> is assigned to subscribers session via RADIUS reply-attributes. Also,
> hierarchical QoS of Redback is in place, This is a sample 
> configuration:
<snip>
> qos policy 128SharedUserRx pwfq
>  rate maximum 8192
>  weight 2
>  num-queues 4
>  queue-map Fastweb
>  queue 0 priority 0 weight 100
>  queue 1 priority 1 weight 100
>  queue 2 priority 2 weight 100
>  queue 3 priority 3 weight 100
<snip>
> The point in this configuration is, when two subscribers are connected
> inside of one dot1q pvc, HTTP browsing of one subscriber has priority 
> over
> HTTP download of another one but instead of lowering the rate of 
> download,
> it simply drops all of the packets.

Hi Alireza,

This config is working as expected:  each queue has absolute priority 
over the previous queue, so the lowest priority queues are being 
starved.  If you set up your queue priorities e.g. like so:

queue 0 priority 0 weight 100		!  NC/EF queue gets absolute priority
queue 1 priority 1 weight 80		!  CS3 & 4 get 80% bandwidth
queue 2 priority 1 weight 10		!  CS1 & 2 get 10% bandwidth
queue 3 priority 1 weight 10		!  BE gets 10% bandwidth

Then the traffic classes you want to prioritize will get most of the 
bandwidth, and the two lower priority queues will only get 10% each (and 
thus dequeue at that rate), but they won't be starved of bandwidth when 
the other queues have traffic.

It would also be a good idea to set up a congestion-avoidance-map to use 
WRED to manage the queue congestion control and decrease the size of the 
queues so that you don't needlessly buffer large quantities of "old" 
packets (i.e. more than 2 seconds of buffer is probably not very useful 
in most situations) rather than just dropping them.

Hope that helps,
---
  Blake Willis
  Consulting Network Architect
  iBrowse/L33 Networks


More information about the redback-nsp mailing list