From: Scott M Vermillion (scott_ccie_list@it-ag.com)
Date: Tue Dec 02 2008 - 01:02:08 ARST
Hi Paul,
I suppose it's all a bit hypothetical to those of us without access to the
source code! ;-) This policer is implicit and not well-documented (and
therefore probably not well-understood outside of Cisco dev and maybe TAC
circles). We really don't know what some of the default values associated
with it might be and none of them, to my knowledge anyway, are manually
configurable.
From time to time I get access to some pretty fancy network emulation gear.
Given the time and opportunity, I'd definitely have the motive to build a
traffic profile that was both bursty in nature and, overall, at or very
close to the outgoing line rate. I'd test throughput for baseline. Then
I'd apply a service-policy with a priority class matching the test traffic
profile. The value assigned to the priority-class would be, say, 10% of
outgoing line rate. There would be no traffic falling outside of the
priority-class. Then I'd test again. Be interesting to see the results.
Cheers sir,
Scott
From: paul cosgrove [mailto:paul.cosgrove@gmail.com]
Sent: Monday, December 01, 2008 7:00 PM
To: Scott M Vermillion
Cc: shank shank; CCIE Group
Subject: Re: Priority command
Hi Scott,
Am in complete agreement with all your points, except perhaps one; namely
whether or not priority traffic can ever use the entire link's Bw.
If you are removing packets at a faster rate than you are putting them into
the queue (be it hardware or software) then your queue size must either
contain only a single packet, or be reducing in size. Micro bursts still
need to be greater that the available transmission rate, and for sufficient
duration that the (small) hardware queue fills, in order for them to result
in congestion. For congestion to occur at at less than the interface
clocking speed I think we would need to artificially ensure that traffic
enters the hardware queue at a slower rate, and that traffic exceeding that
rate is buffered, i.e. shape the outbound traffic.
If priority traffic was configured at exactly the output line rate, and sent
into the router at this speed without shaping configured, then it should use
the full interface bandwidth (if the router can handle packets at line
rate). After all, the router sees only bits and inter packet delay.
If I understand you correctly, you are referring to the difference between
the timescales in which a network device detects congestion, and the larger
time frames which we humans are used to dealing with. So with a 100Mbps
interface, and 'priority 100000' the limit is set to 100Mbps, but queueing
and policing functions will operate at shorter intervals than 1 sec. If the
traffic is sent into the router at an average rate of 100Mbps over a second,
but contains microbursts within that, then congestion may still occur.
The inbuilt policer will be checked if a packet is received when there is
congestion, so drops may also occur at short time intervals even if the
total traffic sent over the entire second is less than 1000kb.
According to the command reference, the priority command does allow a small
additional excess over the configured priority value, so it tries to
accommodate small bursts. If the line speed is exceeded long enough for the
hardware queue to fill, congestion may then occur. This would lead to
priority packet drops by the inbuilt policer if packets continue to be
received, and their size + inter packet delay indicate that they exceed the
configured rate. While congestion is occurring the hardware queue will
still be emptied at line rate, and as soon as there is space available I
would expect the software queue would be emptied to fill it. So even with
small bursts above line rate, individual packets being dropped may not cause
the interface output to drop below line rate.
Well that's my best guess anyway.
Paul.
On Mon, Dec 1, 2008 at 11:44 PM, Scott M Vermillion
<scott_ccie_list@it-ag.com> wrote:
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
<http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a008
0160fc1.shtml>
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.
That s
precisely what I was thinking of Paul!
;-)
Now
this whole thing gets
interesting when you really ponder the definition of congestion.
It s
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 haven t 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 TxRing s 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, you d 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