From: Scott Morris (swm@emanon.com)
Date: Thu Jan 05 2006 - 15:08:10 GMT-3
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
This archive was generated by hypermail 2.1.4 : Wed Feb 01 2006 - 07:45:47 GMT-3