From: paul cosgrove (paul.cosgrove@gmail.com)
Date: Mon Dec 01 2008 - 23:59:37 ARST
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
> 160fc1.shtml<http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080160fc1.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
> >
> >
> _______________________________________________________________________
> >
> Subscription information may be found at:
> >
> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at
> http://www.ccie.net
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at
> http://www.ccie.net
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
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