From: Chris Lewis \(chrlewis\) (chrlewis@cisco.com)
Date: Sat Jun 25 2005 - 15:15:46 GMT-3
I'm familiar with the side effects of late night studying too :)
In the example I gave, the configuration does indeed add a police
statement in combination with the priority command to achieve the
desired effect of limiting the user to the pre-defined priority rate
even if there is no congestion. Police is chosen in preference to shape
in that case as the traffic is voice traffic and the aditional delay a
shape command would introduce for queued traffic is undesireable.
Cheers
Chris
-----Original Message-----
From: Lee Carter [mailto:l2carter@yahoo.com]
Sent: Saturday, June 25, 2005 12:56 PM
To: Chris Lewis (chrlewis); John Matus; lab
Subject: RE: QOS question/clarification: bandwidth, priority, shape,
police
Chris,
My bad. I am using congestion and utalizatoin as one term. (One of the
side affects of staying up till 2AM studying I guess :)
That aside,
In your exampl below were you want a priority queue for particualr
traffic but you also want to cap them at a pre-defined rate would you
use priority xxx then also add shape or police in combination?
Thanks,
Lee
--- "Chris Lewis (chrlewis)" <chrlewis@cisco.com>
wrote:
> 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
> -
=== message truncated ===
This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:44 GMT-3