[rbak-nsp] redback-nsp Digest, Vol 36, Issue 7

[Blake Willis]

On 15 Dec 2010, at 18:00,  David Freedman wrote:

> Wondering on the commonly accepted way of shaping L2TP subscribers.
>
> Currently am using a PWFQ policy such:
>
> qos policy RATECAP24M pwfq
>  rate maximum 24576
>  num-queues 4
>  queue 0 priority 0 weight 100
>  queue 1 priority 1 weight 100
>  queue 2 priority 2 weight 100
>  queue 3 priority 3 weight 100
> !
>
> Though I understand that this is achievable with both metering and
> policing policies.
>
> Wondering what the best way to do this is, considering I would rather
> shape than police (i.e be kind to TCP and avoid bandwidth "sawtooth"
> oscillations caused by TCP not backing off)
>
> Was thinking of switching to metering simply to be able to add
> marking to the policy as well.

Hi Dave,

	We use both:  in some places we actually have subscribers with  
metering (for downstream remarking), policing (for upstream  
remarking), and pwfq all on the same subscriber.  The box will mark  
("meter") downstream traffic & then queue it on the same subscriber  
all day long.  The only place where we really got caught here is that  
for metering policy bandwidths lower than about 2mbps, the metering  
"burst" counters really don't work very well at all (the docs do make  
some vague references to this but it's not clear at all; I believe  
it's something to do with the marker's sample period being too  
short).  In my experience the Redback pwfq works extremely well.

	You're right about the TCP backoff issues; in my testing the best  
"user experiences" were with pwfq & a congestion avoidance map with  
good RED settings.  We try to save rate-limiting for use as a sort of  
emergency brake to throttle traffic that would exceed what we'd  
consider normal usage.

	Another area where pwfq has an advantage over rate-limiting is being  
able to set relative weights for the same priority group.  Metering/ 
policing can be configured to a percentage or a raw bandwidth, but  
two queues in the same priority group will be allocated bandwidth in  
a round-robin fashion between one another according to their weights,  
& they can "borrow" unused bandwidth.  Testing has shown this to be  
quite accurate as well, even at lower speeds.

	I'm sure you take this into account already on your network, but it  
bears mentioning for others:  for me an important question to ask  
when deciding whether to rate-limit (setting a fixed rate in  
"metering" downstream or "policing" upstream) or pwfq is the amount  
of queuing resources that the set of subscribers will use; if there  
are 10k subscribers on a card with 8 queues per subscriber, then a  
card that supports 64k queues won't handle it.  It would be necessary  
to rethink the QoS architecture so that the design could be  
accomplished with 4 queues & some metering rate-limiters instead.

	Best of luck.  Take care & talk to you soon.

  -Blake

---
  Blake Willis
  Network Architect
  iBrowse
  blake at ibrowse dot com