Re: QoS for PPPoE / ADSL

Hey Dale, many thanks for the additional explanation, I needed it!

With regards to LLQ, this will always go first. So with a little or a lot
of traffic, either way you have protected yourself. Also what may be
helpful to you is that LLQ will begin to police and drop traffic if it
thinks there is congestion and the amount of traffic has exceeded the
configured value for the LLQ. If no congestion then no policing.

A lot depends on your configs, but with the example I gave:

LLQ could potentially take up to 75% of the configured bandwidth for the
interface. The remaining 25% would be used for important traffic from the
router, and then divided between the other classes, in my example the
class-default.

So, ... kind of back to the problem you face ... how to tell the interface
that it is congested so that the configured values have the desired effect?
Second question to ask is: how to know exactly what you need for your LLQ or
your policies?

I really look to the experience and expert advice from others, but my
thoughts would be to:

Create a class for your LLQ. You need to know what kind of service you want
this class to get when you configure this. Then configure
bandwidth-estimate for this one class and monitor this class. This will
return a bandwidth estimate value for you so that you can meet the service
levels you defined. In this case, you defined these for the LLQ.

Knowing this value will help get an idea of what you need, and also for when
you want the LLQ to begin droping and policing. If you are not worried
about the other traffic as much, you can play with the interface bandwdith
command to achieve the behavior you want. What value should this be, I hear
ya ... In this case, you can begin to drop the LLQ traffic so that it does
not take to much, and as such I would configure it to be something that also
allows for LLQ to begin policing. Also, since the router can still send
more, no worries on limiting yourself with a mis-config.

Fair-queue and wred for the class default works well for most class-default
traffic IMO.

With all of this said (sorry for writing a book), I feel lilke this is kind
of 'a poor man's method'. You may decide to ping the folks at
corvil.comand see if they have a solution for you. These folk are
really good.

SNMP does not help much IMO ... traffic bursts at the msec intervals, and
monitoring and graphing traffic even at the 1 second interval does not
really capture this, and or, you may miss some important bursts. You can
not afford that and you need to get a little deeper.

I would suggest to look for the bandwidth estimate feature and or a 3rd
party product like the ones offered by Corvil. Net scout and others might
have something too ... I really do not know about them other than their good
reputation.

Sorry if I 'missed' it with this response, and I HTH ya Dale,

Andrew Lee Lissitz

On Sun, May 10, 2009 at 4:28 AM, Dale Shaw <dale.shaw_at_gmail.com> wrote:

> Hi Andrew,
>
> The reason I'd like to be able to trigger congestion through the use
> of a parent shaper is that many QoS features don't activate unless the
> interface is experiencing congestion. Since the interface over which
> the PPPoE session is established is clocked at 100Mbps, none of the
> queueing configuration is going to work when my upstream offered data
> rate exceeds the line sync rate -- "IOS says: you're trying to send
> 1.3Mbps of data upstream, via a 100Mbps interface -- you've got HEAPS
> of room!". Of course, there'll be evidence of the problem in upper
> layer protocols, and some transports will respond better than others.
>
> So I can configure LLQ and CBWFQ all day long, but unless IOS thinks
> the interface is experiencing congestion, none of the configuration is
> going to take effect.
>
> The solution is to configure a parent shaper that shapes all outbound
> to a specified rate (in my case, say, 1.2Mbps), and this is where I
> don't think a 'static' configuration is ideal.
>
> Regarding LLQ.. I see what you're saying, but remember that the
> in-built policer function only activates under congestion. Without
> congestion, the LLQ can chew up as much bandwidth as is available,
> potentially introducing a problem if there's a burst of traffic in
> another class. This is a good reason to configure a policer explicitly
> for the LLQ.
>
> I've decided to graph my upstream (and downstream, while I'm at it)
> sync speeds for a week or two, so that I can settle on a sensible
> 'shape average' value for the parent shaper. I'm going to use SNMP
> with Cacti to do it, rather than any kind of dynamic method based on
> IOS scripting (although that would be 'way cool').
>
> cheers,
> Dale
>
> On Sun, May 10, 2009 at 12:43 PM, ALL From_NJ <all.from.nj_at_gmail.com>
> wrote:
> > I have not done this scenario myself, so I don't suppose my response will
> be
> > as helpful as another. Appreciate this question Dale as it made me look
> up
> > a few things I had forgetten that I forgot. Thx!
> >
> > Oh well ... hope these comments help.
> >
> > For LLQ you should configure what you need and that's that. What does
> your
> > traffic need for the LLQ? Ok ... so ... configure it, guarantee it, and
> > you are cool (always!). If the line rate fluctuates, and you do not
> have
> > enough for your LLQ, then you need a diff line. Sorry for stating the
> > obvious ...
> >
> > For the other traffic, my intial thoughts are that configuring the
> > class-default for wred is probably all you need. The other traffic will
> > battle it out in the individual queues, and traffic will be dropped when
> > needed.
> >
> > LLQ for your important stuff, and wred for the rest. The important
> traffic
> > will get through and the other traffic will "come and go" as available
> > bandwidth provides.
> >
> > Hope this is not too far off or too simplistic of an approach. Further,
> I
> > look forward to hearing yours and the other expert's opinions. Kindest
> > regards,
> >
> > Andrew
>

-- 
Andrew Lee Lissitz
all.from.nj_at_gmail.com
Blogs and organic groups at http://www.ccie.net