From: Chris Lewis (chrlewiscsco@gmail.com)
Date: Thu Jan 05 2006 - 13:47:56 GMT-3
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