From: Joe Chang (changjoe@earthlink.net)
Date: Sun May 23 2004 - 23:55:39 GMT-3
That helps a great deal, thank you Brian!
The architecture book is a real eye opener, I'm actually working through it
right now. Who woulda thunk that the IOS is non-preemptive?
----- Original Message -----
From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
To: "Joe Chang" <changjoe@earthlink.net>; "Brian McGahan"
<bmcgahan@internetworkexpert.com>; <ccielab@groupstudy.com>
Sent: Sunday, May 23, 2004 8:57 PM
Subject: RE: Traffic Shaping question
Hi Joe,
Traffic-shaping controls the rate at which packets are moved
from the shaping queue to the transmit ring. The rate at which they are
moved is Bc per Tc, or in the case where excess burst is allowed, up to
Bc + Be per Tc. In the case of legacy GTS or FRTS with a single VC this
concept is fairly straightforward since only a single shaping buffer is
contending for the transmit ring. When you implement traffic shaping
with per VC queueing or GTS/FRTS via the MQC the model gets more
complicated.
The output order from the shaping queue to the transmit ring can
be either FIFO, WFQ, WRED, be bound by a custom/priority queue-list in
legacy FRTS, or be bound by the bandwidth statement or the low latency
queue in the MQC. The shaping process dictates that Bc bits will moved
to the transmit ring per Tc, but it is a different matter entirely WHAT
traffic will be dequeued.
With per VC queueing the logic gets even worse. Although each
VC is using it's own shaping buffer and output queue, they must all
still contend for the same transmit ring of the interface. Assuming
that the aggregate rate of all Bc's per Tc (and different VCs can use
different Tc's) does not exceed the serialization of the interface per
second (the transmit ring's ability to dequeue the traffic based on the
interface clocking), theoretically you should be able to sustain the
rate of Bc per Tc on a per VC basis, however again the traffic shaping
process still does not dictate WHAT traffic will be dequeued :)
IMHO these type of issues are well beyond the scope of most
practical QoS implementation, because there is only so much you can do
on one interface. If contention between circuits becomes a practical
issue, the best solution is just to terminate the circuit on a separate
interface. If you do want to research these type of topics further I
would recommend the Cisco press book "Inside Cisco IOS Software
Architecture".
Does that help at all? :)
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Joe Chang
> Sent: Sunday, May 23, 2004 11:48 AM
> To: Brian McGahan; ccielab@groupstudy.com
> Subject: Re: Traffic Shaping question
>
> That's right. The buffer is a queue, the style of which can be
specified
> in
> the configuration. But at what point can this buffer be emptied onto
the
> I/O
> transmit ring of the interface? I guess there's a lot more to the
> algorithm
> than the texts are letting on.
>
>
> ----- Original Message -----
> From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> To: "Joe Chang" <changjoe@earthlink.net>; <ccielab@groupstudy.com>
> Sent: Sunday, May 23, 2004 10:33 AM
> Subject: RE: Traffic Shaping question
>
>
> Hi Joe,
>
> Traffic shaping uses a buffer to hold packets that cannot be
> transmitted due to lack of Bc or Be credit. This buffer is defined in
> legacy FRTS by the "frame-relay holdq" map-class subcommand, and the
> "queue-limit" policy-map/class-map subcommand for MQC FRTS.
>
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
>
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > Joe Chang
> > Sent: Saturday, May 22, 2004 6:35 PM
> > To: ccielab@groupstudy.com
> > Subject: Traffic Shaping question
> >
> > QoS is a real popular topic here!
> >
> > Does anyone know what happens to packets that are queued as a result
> of
> > being
> > rejected by the token bucket algorithm? At what point are these
> packets
> > forwarded onto the transmit ring? Two streams result from the token
> bucket
> > function - one that conforms and one that doesn't. How and when can
> the
> > unconforming stream be sent without defeating the objective of
traffic
> > shaping
> > - keeping the average rate under the CIR?
> >
> > TIA
> >
> >
>
This archive was generated by hypermail 2.1.4 : Wed Jun 02 2004 - 11:12:16 GMT-3