From: Lee Carter (l2carter@yahoo.com)
Date: Sat Jun 25 2005 - 13:41:33 GMT-3
Chris,
I think we are mixing up the term congestion but are
basically saying the same thing.
http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080103eae.shtml
The link above talks about the differences of Priority
versus Bandwidth statements within MQC.
So, Bandwidth reserves a minimum amount
and Priority reserves a maximum amount
As for when they are actively being enforced. My
understanding is that priority is always in affect,
meaning that if two packets arrive at the same time
then the priority traffic goes first (I realize if
there are zero packets in the queue then it doesn't
really matter). But if two packets arrive at the same
time that are part of different "bandwidth" classes
they are FIFO queued.
So would you say if there is one packet in the
tx-queue and one in the software queue than the
interface is at 100% utilization... I would suspect
not.
But if the circuit is over 75% utilized then the
bandwidth statements kick in and make sure each class
is allotted it's minimum amount of bandwidth by
cycling thru the different queues allowing specific
amounts of traffic through and the priority queue
doesn't take more than it's maximum amount of
bandwidth but will put it's packets first over all
others until it has reached it's maximum amount of
allocated bandwidth.
As for the lab is concerned I don't think it really
matters how they are in affect but rather what wording
will clue you in on weather to use priority/bandwidth
ect.
Thanks,
Lee
--- "Chris Lewis (chrlewis)" <chrlewis@cisco.com>
wrote:
> Lee, the simple way to look at it is without
> congestion, the incoming
> packet is always first in line :) to say that the
> priority command takes
> effect when there is no congestion is incorrect.
> With no queue, there is
> no opportunity to jump a packet to the top of the
> queue. One cannot get
> better latency than an interface with no congestion.
> In fact this is the
> way that some major service providers in the US
> ensure quality of
> service in their cores, they simply over-provision
> bandwidth so that
> congestion never happens and do not configure any
> priority queueing.
>
> Remember that the priority or bandwidth commands
> only take effect prior
> to the Tx-ring on the interface, once a packet
> enters the Tx-ring, no
> re-ordering takes place.
>
> As a packet travels through a router, it will
> progress through the
> following:
>
> Classification
> Per class policy (this is where the priority or
> bandwdith commands take
> effect)
> Frame relay traffic shaping (if configured)
> FIFO Tx-ring (one exception to this is that in some
> IOS, VoIP packets
> bypass FRTS)
>
> The issue to be concerned with in real world designs
> relating to the
> Tx-ring is that if it is full with data packets, you
> cannot jump a voice
> packet ahead of them, so the size of the Tx-ring
> defines the worst case
> latency you experience on an interface.
>
> Here are some notes on the Tx-ring
>
> tx-ring is a FIFO queue providing buffering before
> the hardware line
> driver - allowing interface driver to maximise
> throughput
> The shorter the tx_ring, the shorter the potential
> worst-case delay that
> will be experienced through that interface during
> congestion
> if set too short, the driver might not be able to
> maintain line rate -
> dependent upon the forwarding performance of the
> interface driver
> tx_ring tuning can therefore be a trade-off between
> maximising
> throughput and minimising the possible queuing delay
> incurred during
> interface congestion
> IOS self-tunes tx-ring based upon interface rate
> Only configure the tx_ring less than the default
> value where the default
> does not satisfy the required delay constraints
> Use the largest tx-ring-limit that still satisfies
> the delay
> requirements
> Generally recommended that tx-ring-limit = 2 is the
> minimum value used
>
> I also do not follow your comments on the 75% value.
> That is the default
> amount of bandwidth you can allocate using
> bandwdith, or priority, it
> does not relate to queueing. The definition of
> congestion is that there
> is a packet to send, but the lTx-ring is full,
> implying the line is
> already at 100% utilization.
>
> Cheers
>
> Chris
>
> -----Original Message-----
> From: Lee Carter [mailto:l2carter@yahoo.com]
> Sent: Friday, June 24, 2005 11:25 PM
> To: Chris Lewis (chrlewis); John Matus; lab
> Subject: RE: QOS question/clarification: bandwidth,
> priority, shape,
> police
>
> Ok,
>
> I have a comment for task 3
>
> "3) provide at most this amount of band during times
> of congestion =
> priority Priority means put this stuff at the top of
> the queue, this
> only takes effect when there is congestion, as of
> course, without a
> queue, you have no packets to re-order. As part of
> the priority command,
> there is a natural policer action, such that if
> there is congestion, no
> more than the specified rate will be treated with
> priority (ie jumped to
> the front of the
> queue) and any excess is dropped."
>
> Doesn't priority take affect at ALL times.. Even if
> there is NO
> congestion. (doesn't it set aside a TX queue and a
> priority queue)
>
> My understanding was that priority is a low latency
> queue that always
> moves the packet to the front of the line before any
> other packet is
> allowed in the TX queue. However, if a pakcet is
> already there then the
> priority queue must wait until the first packet is
> de-queued and then it
> is placed directly into the tx queue before any
> other traffic. (hence
> the importance of fragmentation on links less than
> 768k)
>
> This behavior is in affect ALL the time not just
> when thre is
> congestion. This is how you 'guarantee' a low
> latency network queue for
> a particual type of traffic.
>
> Now for the bandwidth parameter.. it doesn't take
> affect until the
> interface is at 75% congestion. Which can be tricky
> for production or
> the LAB because your documentation may show that you
> have a 64k link but
> if you don't but the bandwidth statement on the
> interface the default
> maximum speed is used and 75% of a T1 is totally
> different than 75% of a
> 64k link on a T1 port.
> I suspect you would loose lab points on the lab if
> you forgot your
> bandwidth statements.
>
> HTH
>
> Lee
>
>
>
>
> > Some slightly different perspectives in-line
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com
> > [mailto:nobody@groupstudy.com] On Behalf Of John
> Matus
> > Sent: Friday, June 24, 2005 9:22 PM
> > To: lab
> > Subject: QOS question/clarification: bandwidth,
> priority, shape,
> > police
> >
> > ok, i'm pretty sure that i've got this stuff
> covered but i'm sometimes
>
> > suprised at what kinds of answers labs have to
> specific qos quetions.
> > here are my pseudo-axioms.
> > 1) police coming in, shape going out
> > In general, yes, but outbound policiing is also
> possible and could be
> > a requirement if the question is worded such tha
> anything over a given
>
> > rate is dropped or something similar.
> > 2) provide at least this amount of band during
> times of congestion =
> > bandwidth
> > 3) provide at most this amount of band during
> times of congestion =
> > priority Priority means put this stuff at the top
> of the queue, this
> > only takes effect when there is congestion, as of
> course, without a
> > queue, you have no packets to re-order. As part of
> the priority
> > command, there is a natural policer action, such
> that if there is
> > congestion, no more than the specified rate will
> be treated with
> > priority (ie jumped to the front of the queue) and
> any
=== message truncated ===
This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:44 GMT-3