From: Scott Morris (swm@emanon.com)
Date: Thu Jan 05 2006 - 18:47:28 GMT-3
You need to remember that a lot of this stuff is just a method of
perspective anyway. :)
So, way back when we only had to deal with IP Precedence values, it was
always looked at that voice data would be IP Prec 5 and Call setup would be
IP Prec 3. These days we're just looking at more festive ways to mark them.
Technically though, since they're picking AF class 3 (ip prec 3), it would
stand to reason that they'd pick the drop probability to give the best
possible chance of survival and delivery! But it really is just a matter of
making the numbers look pretty much the same as what they've always been.
As for your AF21 and AF13 stuff, the order of importance would certainly
depend on how they had things set up on the various queuing strategies. But
EF (IP Prec 5 + other bits) should be treated first, followed by AF4 stuff,
then AF3, then AF2, then AF1, then BE... Mileage my vary, 'cause we're
talking about what logically SHOULD happen and there's no guarantee that
someone didn't program the router badly.
You're also anticipating there's going to be some serious congestion along
the way! Not to mention, will ALL the traffic that you're marking at
different levels go across the same links? And, if you have SLA's setup
guaranteeing particular rates you SHOULD get those rates without any
problems. If you are trying to engineer traffic above and beyond your
guarantees then there may be issues!
When you're outside any it's 0 degrees Celsius or 32 degrees Farenheit, it's
still pretty cold. :) Just perspective.
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Leigh Harrison
Sent: Thursday, January 05, 2006 4:23 PM
To: swm@emanon.com
Cc: 'Chris Lewis'; 'Victor Cappuccio'; 'FORUM'
Subject: Re: QoS AF priorities
Right - let me give you some background to my thinking then.
I'm going to take my QoS exam (as port of my ccvp) next week or the week
after.
In the UK a lot of our wan services are provided by BT (British Telecom) and
in their wan products, they offer QoS.
I spec'd a link for a customer recently for voice over ip and gave 1MB EF
(voice) and 100k af31 (call setup gubbins). I know that Cisco suggest af31
for the call setup.
My question is if I also had some traffic at af21 and af13 (for example)
what would be the order of importance. I know about the drop probabilities
within the classes. Why would you specify one class over the other and why
would cisco specify af31 for call setup ?
PONG!
LH
Scott Morris wrote:
> PING! ;)
>
> ----------------------------------------------------------------------
> --
> *From:* Chris Lewis [mailto:chrlewiscsco@gmail.com]
> *Sent:* Thursday, January 05, 2006 3:02 PM
> *To:* swm@emanon.com
> *Cc:* Victor Cappuccio; Leigh Harrison; FORUM
> *Subject:* Re: QoS AF priorities
>
> Hi,
>
> I guess we hit the crux of the matter when we look at assumptions.
>
> If you assume an interface over 2M, you'll get FIFO by default and
> everything I've been saying applies.
> If you assume an interface under 2M, you'll get WFQ as default, which
> still does not look at drop probabilties as it only looks at
> precedence ( http://www.cisco.com/warp/public/732/Tech/wfq/
> <http://www.cisco.com/warp/public/732/Tech/wfq/> shows the details and
> an example for those interested).
>
> So I think it comes back to requiring more specifics from the question
> Leigh posed. Ball in your court Leigh!
>
> Chris
>
> On 1/5/06, *Scott Morris* <swm@emanon.com <mailto:swm@emanon.com>> wrote:
>
> Well, let's assume you've employed some sort of WFQ mechanism in
> there. The
> whole concept of WFQ involves some weighting! With that, the queuing
> mechanism itself will apply better preference to the higher
> classes (because
> they map to older IP Prec values).
>
> >IF< you are applying drop policies to get the other part working,
> then
> acording to Cisco's web site just turning it on will start
> discarding the
> drop-class 3 stuff when your queue reaches 24 packets. Drop class
> 2 at 28
> packets and drop class 1 at 32 packets. Hence the queue can fill
> up more
> before discarding begins there.
>
> So I guess this is where we have to interpret probability. :) In
> a generic
> WFQ deployment, all things in the same class (IP Prec value) will be
> "weighed" equally, then it just becomes a matter of who goes first.
> Obviously, if you're running MQC and can set up your different
> queues based
> on individual values, then the whole thing almost becomes moot anyway!
>
> But I do agree with you that tuning this stuff is a pain! But
> there are
> still default policies (if left untouched) as pointed out in that
> document.
> But absolutely, you should not be remarking things along the way
> because of
> the induction of new and exciting issues. :)
>
> Like most things with the "knobs" available, if you don't have a
> compelling
> reason and/or understand what the implications are, don't touch
> them! (At
> least in real life! In the lab, only touch them if the lab
> specifically
> asks for it!)
>
> Scott
>
> -----Original Message-----
> From: nobody@groupstudy.com <mailto:nobody@groupstudy.com>
> [mailto:nobody@groupstudy.com <mailto:nobody@groupstudy.com>] On
> Behalf Of
> Chris Lewis
> Sent: Thursday, January 05, 2006 11:48 AM
> To: Scott Morris
> Cc: Victor Cappuccio; Leigh Harrison; FORUM
> Subject: Re: QoS AF priorities
>
> Hello Scott;
>
> I disagree with my undestanding of your post, although I may be
> misinterpreting what has been said :)
>
> With no specific drop policy configured, AF13 is no more likely to be
> dropped than AF41, or vice versa. Just as no specific bandwidth or
> preference is given to these DSCP values if no queuing policy is
> defined.
>
> If a drop policy is configured, the likelyhood of a packet being
> dropped
> will be defined by that policy.
>
> If random detect dscp is configued as the drop policy with no further
> customization the previous link describes the default behavior.
> But in
> summary, each marking has the same probaility of being dropped,
> but some
> become eligible for being dropped at different queue depths. As an
> example
> if the average queue depth in a class for af31 traffic reaches 32
> packets,
> all further af31 packets are eligible to be randomly dropped.
> Whereas for
> af3, packets are eligible to be dropped when the average queue
> depth is 24
> packets.
>
> WRED tuning is a complex problem that depends upon many factors,
> including:
> The offered traffic load and profile
> The ratio of load to available capacity
> The behaviour of traffic in the presence of congestion These
> factors vary
> network by network and are dependent upon services offered and on
> customers
> using those services
>
> Having said that tuning WRED is a nasty and difficult task, it
> does get used
> in production networks. The way this has been used in production
> provider
> networks has been to use different drop profiles for traffic that
> conforms
> to the SLA the customer has signed up to, compared to traffic they
> send that
> exceeds the SLA.
>
> The thinking here is that one does not mark traffic exceeding the
> contract
> to a different class (so don't re-mark a packet exceeding the SLA for
> business data to best efforts for example), as that introduces out of
> sequence issues, what one does is mark exceeding packets with a
> different
> drop probability and configure the drop policy such that all
> exceeding
> packets will be dropped prior to conforming packets in the presence of
> congestion. This is realised in CLI if we design things such that
> DSCP 32 is
> the conforming traffic, and exceeding traffic is marked with DSCP
> 8 (just
> taking those values as examples).
>
> random-detect dscp 8 11 33 1
> random-detect dscp 32 550 600 1
>
> A large gap between the maximum threshold for exceeding packets
> compared to
> the minimum threshold for conforming packets is there to ensure
> that the
> instantaneous queue depth will never reach the minimum threshold
> of the
> conforming traffic and hence exceeding packets will be dropped
> ahead of
> conforming packest at all times.
>
> Chris
>
>
>
>
> On 1/5/06, Scott Morris < swm@emanon.com <mailto:swm@emanon.com>>
> wrote:
> >
> > Actually, it's a bit more interesting than that which may yield some
> > confusion along the way! Now, bear in mind I haven't created a lab
> > with a
> >
> > bunch of traffic and sniffers to really test this out, but....
> >
> > While the document on Cisco's web site (and perhaps their
> > implementation?) states that the first number is a class (1-4)
> (which
> > corresponds to IP Precedence 1-4) and then the second number is
> a drop
> > level, there appears to be confusion on how that part works.
> >
> > Cisco's doc says that's a "drop probability" meaning the higher
> number
> > would yield a higher probability ( e.g. more likely) that the packet
> > would get dropped. Logically that's odd. As you increase in class
> > numbers, you have a better chance of getting access to the link
> during
> > congestion. But as you increase in drop numbers, you have a better
> > chance of getting dropped within your class. Weird.
> >
> > If you look at the RFC 2597, they use some words that are
> contradictory.
> > They use "drop probability" which goes along with Cisco's view, but
> > they also use "drop priority" which would keep the logic similar in
> > that higher
> >
> > number is better no matter which set we're looking at. The example
> > given in the RFC in the Appendix really describes this as a "drop
> > precedence" or "drop priority" which is different.
> >
> > Being that RFC's aren't particularly binding which is where many
> > people get into trouble, I'd suggest paying attention to the Cisco
> > docs and just be aware that it's not working in the manner that you
> > may expect it to! In the class, higher is better. In the drop
> > probability, lower is better. So the order of liklihood to die
> during
> > congestion for Cisco should be:
> >
> > AF13
> > AF12
> > AF11
> > AF23
> > AF22
> > AF21
> > AF33
> > AF32
> > AF31
> > AF43
> > AF42
> > AF41
> >
> > At least according to that document. Perhaps someone on here as
> done
> > some extensive testing in a lab for one of their projects and
> may be
> > able to shed better light onto this. At this point, my view is that
> > it's not logical, but.... Welcome to networking! :)
> >
> > Scott
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com <mailto:nobody@groupstudy.com>
> [mailto:nobody@groupstudy.com <mailto:nobody@groupstudy.com> ] On
> Behalf
> > Of Victor Cappuccio
> > Sent: Thursday, January 05, 2006 8:51 AM
> > To: 'Leigh Harrison'; 'FORUM'
> > Subject: RE: QoS AF priorities
> >
> > Hello Leigh,
> >
> > Maybe this like cold help u a little bit more
> >
> >
>
http://www.cisc.com/en/US/products/sw/iosswrel/ps1834/products_feature_guide
> > 09186a0080080466.html
> >
> > the AFny PHB defines four AF classes: AF1, AF2, AF3, and AF4. Each
> > class is assigned a specific amount of buffer space and interface
> > bandwidth, according to the SLA with the service provider or policy
> > map.
> >
> > Within each AF class, you can specify three drop precedence (dP)
> values:
> > 1,
> > 2, and 3.
> >
> > Assured Forwarding PHB can be expressed as shown in the
> following example:
> >
> > AFny
> >
> > In this example, n represents the AF class number (1, 2, or 3) and y
> > represents the dP value (1, 2, or 3) within the AFn class.
> >
> > In instances of network traffic congestion, if packets in a
> particular
> > AF class (for example, AF1) need to be dropped, packets in the AF1
> > class will be dropped according to the following guideline:
> >
> > dP(AFny) >= dP(AFnz) >= dP(AFnx)
> >
> > where dP (AFny) is the probability that packets of the AFny
> class will
> > be dropped. In other words, y denotes the dP within an AFn class.
> >
> > In the following example, packets in the AF13 class will be dropped
> > before
> >
> > packets in the AF12 class, which in turn will be dropped before
> > packets in the AF11 class:
> >
> > dP(AF13) >= dP (AF12) >= dP(AF11)
> >
> > The dP method penalizes traffic flows within a particular BA that
> > exceed the assigned bandwidth. Packets on these offending flows
> could
> > be re-marked by a policer to a higher drop precedence.
> >
> > An AFx class can be denoted by the DSCP value, xyzab0, where xyz can
> > be 001, 010, 011, or 100, and ab represents the dP value.
> >
> > Also I have this formula that could be usefull for anything
> >
> > 8X + 2Y
> > Af11 == 8(1) + 2(1) = 10
> > Af41 == 8(4) + 2(1) = 34
> >
> > -----Mensaje original-----
> > De: nobody@groupstudy.com <mailto:nobody@groupstudy.com>
> [mailto:nobody@groupstudy.com <mailto:nobody@groupstudy.com>] En
> nombre de
> > Leigh Harrison Enviado el: jueves, 05 de enero de 2006 8:57
> > Para: FORUM
> > Asunto: QoS AF priorities
> >
> > All,
> >
> > I've had a little dig and can't seem to find the answer to my
> question.
> >
> > If you have traffic is the following classes:-
> >
> > af11 af12 af13
> > af21 af22 af23
> > af31 af32 af33
> > af41 af42 af43
> >
> > I know that af41 is top of the shop and af 13 is at the bottom. My
> > question
> > is:-
> >
> > Which order will the packets get dropped off? i.e. will af43 be
> > dropped before af31?
> >
> > I'm not sure if they degrade 41, 42, 43, 31, 32....etc, or if
> they go
> > 41, 31, 21, 11... etc, or any other order.
> >
> > LH
> >
> >
>
> ______________________________________________________________________
>
> > _ Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
>
> ______________________________________________________________________
>
> > _ Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
>
> ______________________________________________________________________
>
> > _ Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>
> ______________________________________________________________________
> _
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Feb 01 2006 - 07:45:47 GMT-3