From: Lee Carter (l2carter@yahoo.com)
Date: Sat Jun 25 2005 - 14:56:05 GMT-3
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