From: Scott M Vermillion (scott_ccie_list@it-ag.com)
Date: Mon Dec 01 2008 - 21:44:40 ARST
I would certainly never be one to argue that the Command Reference is
infallible. But if it's to be believed in this specific case, it's quite
explicit on the matter:
"When the device is not congested, the priority class traffic is allowed to
exceed its allocated bandwidth. When the device is congested, the priority
class traffic above the allocated bandwidth is discarded."
http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_n1.html#wp1032
158
I believe similar language is to be found in the relevant Configuration
Guide as well (but I'm off for a run and the sun is setting fast...) Also,
I believe one or two of the trainers have chimed in on this in the past. I
believe it was somebody's contention (don't recall exactly which of them, so
I'm not going to put words in anybody's mouth) that the traffic in excess of
the configured priority rate was sent but sans LLQ treatment, so long as
"congestion" didn't exist on the interface in question. But as I said
yesterday, be careful about making assumptions when it comes to what,
exactly, constitutes "congestion." The above statement/documentation does
not necessarily lead me to believe that the priority class can ever consume
the entire link's BW, because "congestion" can occur within very, very short
time intervals. Again, likely depends on the nature of the traffic (which
is why I'm not convinced that simple ICMP or IPerf testing would be entirely
appropriate, but probably better than nothing at all).
Now this is strictly "router QoS" and does not address Shaped/Shared Round
Robin scheduling mechanisms found on Catalyst switches. In the "Shaped"
flavor of SRR, the PQ is always >shaped< (note: not policed, per se) to the
configured weight, regardless of the presence or absence of traffic in any
of the other queues. In the "Shared" flavor, the PQ is theoretically
allowed to consume the entire link's BW, assuming no other queues require
servicing. That's per my understanding of things from Odom, so I don't have
any readily available official documentation links to post (again, that sun
is setting fast) as far as Catalyst stuff goes - ya'll know where to find
it.
I'm personally not sure that I would want my priority class of traffic being
policed when interface bandwidth was being left on the table. At least not
in all cases, so it would be nice to have the option one way or another.
It's been about a year back, but somebody once brought up the concept of
configuring both a priority and a policing function within the same policy
applied to the same class. IOS allowed that configuration. Don't recall
that any actual IPerf or ICMP testing was done to validate what the
resultant behavior was. My suspicion, since IOS accepted both the
'priority' and 'police' functions, is that the priority class would have
been policed under all circumstances and given LLQ treatment up to the
policed rate. That seems all the more likely when you consider the QoS
order of operations (which places class-based policing just before
CBWFQ/LLQ):
http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080
160fc1.shtml
I'd love nothing more than for someone to post conclusive data, regardless
of whether it upholds or disproves any of what I've had to say here. I may
well set something of my own up in the coming few days. For now, it's off
to the trails while I can still (sort of) see where my feet are falling...
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
shank shank
Sent: Monday, December 01, 2008 1:40 PM
To: CCIE Group
Subject: Re: Priority command
i guess what i was trying to understad that is when the priority command is
applied to certain calss can we think of this as a way to limit the
bandwidth
to that class to whatever bandwidth configured. i thnk this what anthony
confirmed. or is it conditioned on the congestion status of the interface?
________________________________
From: Scott M Vermillion
<scott_ccie_list@it-ag.com>
To: paul cosgrove <paul.cosgrove@gmail.com>
Cc:
Anthony Sequeira <asequeira@internetworkexpert.com>; shank shank
<shankshink@yahoo.com>; CCIE Group <ccielab@groupstudy.com>
Sent: Monday,
December 1, 2008 3:00:46 AM
Subject: RE: Priority command
> The link
mentions that "During
congestion conditions, a priority class cannot use any
excess bandwidth".
Perhaps that is what you are thinking of.
Thats
precisely what I was thinking of Paul!
;-)
Now
this whole thing gets
interesting when you really ponder the definition of congestion.
Its
tempting to think that 129 kbps of traffic presenting to an
interface clocked
at 128 kbps equals/leads to congestion (which it obviously
does) and leave it
at that. But congestion actually occurs
in scenarios where you havent even
reached your interface clock
rate! As I understand things, anyway. For the
purposes of QoS,
congestion means that your TxRing is full and has backed up
into the configured
SW queue(s). Depending on TxRings depth and the
burstiness of the
traffic, it may well fill quickly (and recall that the very
act of configuring
a SW queue on an interface automatically results in its
TxRing being truncated
so as to invoke the SW queue more readily).
So
I
think if you had an interface running at 100 Mbps and you configured a
priority class of 10 Mbps, then presented nothing but the priority class of
traffic to that interface, youd likely see greater than 10 Mbps of
throughput
but less than 100 Mbps, depending on the nature of the traffic itself
(and to
an extent I can see there being platform-specific and interface
type-specific
differences). I would expect the SW queue to be invoked at
some point, the
priority-class to be policed, and then the SW queue to be
released for a
period, so on and so on
(may
just be a good lab to put together at some
point)
-----Original Message-----
From: nobody@groupstudy.com
[mailto:nobody@groupstudy.com] On Behalf Of
Anthony Sequeira
Sent: Sunday,
November 30, 2008 12:25 PM
To: shank shank
Cc: CCIE Group
Subject: Re:
Priority command
Yes - the priority command is used with Low Latency Queuing
(LLQ) and
it specifies the amount of priority bandwidth to provide to a type
of
traffic (typically Voice). This command also causes a POLICING to the
amount of bandwidth specified..
This is a mechanism to guard against queue
starvation for other
traffic forms.
Anthony J. Sequeira, CCIE #15626, CCSI
#23251
Senior CCIE Instructor
asequeira@internetworkexpert.com
Internetwork
Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Outside
US: 775-826-4344
On Nov 30, 2008, at 1:33 PM, shank shank wrote:
> hello,
>
quick question experts: does the priority command apply a
> maximum limit when
specifying a bandwidth? or is it applying the
> minimum bandwidth certain
class can get in the policy?
>
> so does this command priority 100 means that
the maximum bandwidth
> the class will get is 100k?
>
>
> according to this
link
http://www.ciscosystems.com/application/pdf/paws/10100/priorityvsbw.pdf
>
it does both. can anyone clarify this to me. thanks,
>
>
> Blogs and organic
groups at http://www.ccie.net
>
>
This archive was generated by hypermail 2.1.4 : Thu Jan 01 2009 - 12:53:07 ARST