[rbak-nsp] Strict Queuing Vs. Weighted Queuing

[Alireza Soltanian]

Hi everybody

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:

 

qos queue-map Fastweb

num-queues 4

  queue 0 priority 0 1 2 

  queue 1 priority 3 4 

  queue 2 priority 5 6 

  queue 3 priority 7 

!

qos policy 128SharedUserRx pwfq 

 ! max queue depth 4064 and max queue number 8

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

!

card ge-10-port 3

port ethernet 3/2

qos rate maximum 950000

qos policy queuing Total_Port_3_2

dot1q pvc 4013 profile MARK-COS encapsulation 1qtunnel 

  qos rate maximum 474366

  qos weight 1853

  qos policy queuing GROUP#3

  dot1q pvc 4013:905 profile MARK-COS encapsulation pppoe 

   qos rate maximum 49300

   qos weight 339

   qos policy queuing CO1

 

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. If we use weight mode instead of
Stricked mode in QoS policy configuration, this behavior will not be
happened.  We want to have this behavior:

1)      HTTP Browsing has higher priority

2)      HTTP Download rate has lower rate but it is not dropped.

 

Is there anybody who has experience in working with Stricked/Weighted mode?

 

Thank you

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/redback-nsp/attachments/20131109/6066ec4d/attachment.html>