From: Scott Vermillion (scott_ccie_list@it-ag.com)
Date: Mon Mar 03 2008 - 19:42:38 ARST
And just to be clear since I can see how some might be mislead by my below
ramblings, outbound policing, if configured, will be invoked regardless of
whether the TxRing is backing up into the SW queue, *so long as that policer
is not one invoked implicitly as a result of the 'priority' option in a
class map.*
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Scott Vermillion
Sent: Monday, March 03, 2008 2:35 PM
To: 'Sadiq Yakasai'; 'Spolidoro, Guilherme'
Cc: 'Biggs, Jeff (M/CIO/BIE)'; 'Gaurav Prakash'; 'groupstudy groupstudy'
Subject: RE: LLQ
Hi Sadiq,
OK moving from the physical interface back into the router...
You've got what's referred to as the TxRing or the hardware buffer. Now
that last moniker is a bit of a misnomer, IMHO, in that it seems to suggest
that some stand-alone physical chip is the "HW buffer." Not exactly true
according to my understanding of things, but let's avoid semantics in an
effort to keep the discussion clear.
So this TxRing is of some default depth, depending on the interface type.
When the very first ever (straight out of the box, LOL!) packet is switched
out this interface, it's headed straight into this queue, from which it will
be serialized onto the physical media.
Now let's assume for the sake of argument our TxRing is of a depth of 10
packets. Our first one has already been serialized. Now we get a burst of
9 packets. Everybody straight into the TxRing according to FIFO rules. Now
we get packet 10. Same same. Now we get a burst of five additional
packets. We're still serializing, say, Packet 3 at this point. So we've
got a problem (seven left awaiting serialization and now five new packets
arrive, our queue depth of ten has been exceeded by two). We can no longer
switch packets directly into this interface's TxRing, as there's no room
left to do so. Enter the "software queue." Enter the congestion phase. It
is at this point that we invoke our service-policy defined on the interface.
We do LLQ and policing and whatever else we have configured in the
policy-map. Once the SW queue drains out into the TxRing and the TxRing
falls below its depth (10 in our hypothetical case), we no longer are
experiencing congestion and, for example, there will no longer be any
policing of the priority class(es) of traffic (or any fancy queuing).
So to recap, the SW queue drains into the TxRing/HW queue, which
drains/serializes out onto the physical media. We bypass the SW queue
whenever possible. When the TxRing backs up into the SW queue we are in a
congested state and we apply our configured policy.
This is the reason to shorten the TxRing when a service-policy is applied.
Let's consider the case where we have a single B channel BRI. We're moving
bulk data (perhaps a database replication). Our TxRing is of a depth of 100
packets and that bad boy is full up. We are obviously serializing very
slowly. Now we kick off a voice call. Once stuff is in the TxRing, its
simply awaiting serialization and there is no reordering or any kind of
head-of-line privileges for priority classes. Chances are good we're going
to bust our one-way delay budget right here on this one single interface.
So when a service-policy is applied to this BRI, the TxRing is truncated to
just a few deep (I don't recall specific details, no doubt it varies by
interface type) so that serialization issues do not render our policy
ineffective. Now our priority class of traffic can head straight into the
LLQ (part of the SW queue structure), where it will be serviced up to the
configured bandwidth value. It will still have to get in line to await its
turn into and out of the TxRing, but that is much more shallow now and so
the delay experienced isn't unacceptably high.
Again, all of this according to my understanding of things, which is taken
largely from Doyle's QoS bible and also the Russ White (et al) IOS book I
earlier mentioned.
Cheers,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Sadiq Yakasai
Sent: Monday, March 03, 2008 2:06 PM
To: Spolidoro, Guilherme
Cc: Scott Vermillion; Biggs, Jeff (M/CIO/BIE); Gaurav Prakash; groupstudy
groupstudy
Subject: Re: LLQ
Scott,
Thanks for the defination there. So in essence, once a packet is ready
to be transmitted, it is placed in the SW output queue, from where it
is put onto the TXRing and then eventually on to the wire by the media
controller.
Now, my question again :). When is the interface congested here? Is it
when a packet is ready to be placed into the SW queue and it has to
wait for (at least) one other packet (that is in front of this packet
in question) to be placed in the SW queue? Or is it when the packet
awaits another packet to be placed from the TXRing to the media? Which
of these is this the absolute definition of interface congestion
again?
Because it is only when this happens that the LLQ process is invoked
in the router, right?
This archive was generated by hypermail 2.1.4 : Tue Apr 01 2008 - 07:53:52 ART