From: Chris Lewis \(chrlewis\) (chrlewis@cisco.com)
Date: Sat Jun 25 2005 - 14:20:12 GMT-3
Hi Lee,
As far as I know, congestion only has one definition :)
In my view congestion is a binary operation, either the interface is
congested, meaning queues are building up, or it is not and all packets
are being sent straight out. Any definition of a percentage of
congestion does not make sense to me.
Regarding the following, which seems to be the center of our discussion.
"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."
In fact yes. If there is one packet in the software queue, it means that
it cannot be placed in the Tx-ring, meaning that in the example you
give, the Tx-ring size is one (which is not a good configuration for
optimal throughput), and a packet is in the Tx-ring because it cannot be
put on the wire, meaning the wire is fully utilized.
To say that priority is always in effect is incorrect, there is no other
interpretation that I understand. Priority and bandwidth only take
effect during congestion. Now in some cases I have worked on service
provider designs where they wanted priority traffic not to be able to
use more than its allotted amount even if there was no congestion. The
reason for this is that provisioning bandwidth for voice (what was in
the priority queue) is the most expensive bandwidth to provision as that
class would be over-provisioned by a factor of 2 or so to ensure best
service throughout the network. So the provider does not want the
customer to send more than the subscribed priority bandwidth for that
traffic. To get the router to behave that way, an additional police
statement is required. Without it the priority command only limits
traffic to the configured rate when there is congestion.
If the interface is 75% utilized, no queues build up and no bandwidth or
priority configurations take effect. The 75% figure only refers to the
amount of bandwdith you can allocate within queueing mechanisms by
default, not when those queuing mechanisms take effect based off
congestion.
Chris
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Lee Carter
Sent: Saturday, June 25, 2005 11:42 AM
To: Chris Lewis (chrlewis); John Matus; lab
Subject: RE: QOS question/clarification: bandwidth, priority, shape,
police
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_note09186a
0080103eae.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