From: Chris Lewis (chrlewiscsco@gmail.com)
Date: Thu Jan 05 2006 - 17:01:51 GMT-3
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/ 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> 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] 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> 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 ] 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] 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