From: Chris Lewis \(chrlewis\) (chrlewis@cisco.com)
Date: Sat Jun 25 2005 - 13:11:15 GMT-3
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 excess is
> dropped.
> 4) provide an average of X band out an interface = shape
> 5) only allow x amount of band = policing.....
> <ok, so really only #1 is an axiom>
>
> my question is about "shaping". i cant remember back to any labs i
> did as to how things were worded with regards to shaping. the only
> thing i can think of
> is "provide an average of x out an interface".
> can anyone think of
> any
> other catch phrases that might indicate the shaping is to be used?
>
> Wording can be tricky, but if they are looking for shaping, the could
> refer to things like delay, queue, store, anything like that.
>
> TIA
>
>
> Regards,
>
> John D. Matus
> MCSE, CCNP
> Office: 818-782-2061
> Cell: 818-430-8372
> jmatus@pacbell.net
>
>
This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:44 GMT-3