From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Tue Jan 03 2006 - 15:54:53 GMT-3
> 1. The point of FRTS is so that we create this artificial congestion
so
> that
> we decide which packets are dropped rather than let the carrier
randomly
> drop packets?
The point of traffic shaping is to *not* drop packets. This is
accomplished by delaying packets in the shaping queue with the intent of
sending them at a later time.
> 2. Lets say our CIR allowed us to send 1 voice packet every 10 ms. If
we
> used a 10 ms interval we would send exactly 1 packet every 10 ms. But
if
> we
> used a 100ms interval, we can possible send all 10 packets in the
first 50
> ms, then wait 50ms before sending more packets?
Yes. Setting the Tc smaller gives you a more even distribution of
sending as opposed to periods of high sending followed by waiting.
> 3. Basically is this technique a way to create a fixed inter-packet
delay?
Yes. The Tc only matters if delay is an issue. Otherwise you can just
let the shaping algorithm choose the Tc for you.
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
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> CCIEin2006
> Sent: Tuesday, January 03, 2006 12:20 PM
> To: Bob Sinclair
> Cc: Leigh Harrison; Cisco certification
> Subject: Re: FRTS Time Interval
>
> I almost got it now, just need to clear some things up. Please
correct me
> if I'm wrong:
>
> 1. The point of FRTS is so that we create this artificial congestion
so
> that
> we decide which packets are dropped rather than let the carrier
randomly
> drop packets?
> 2. Lets say our CIR allowed us to send 1 voice packet every 10 ms. If
we
> used a 10 ms interval we would send exactly 1 packet every 10 ms. But
if
> we
> used a 100ms interval, we can possible send all 10 packets in the
first 50
> ms, then wait 50ms before sending more packets?
> 3. Basically is this technique a way to create a fixed inter-packet
delay?
>
>
> On 1/3/06, Bob Sinclair <bob@bobsinclair.net> wrote:
> >
> > CCIEin2006,
> >
> > I believe the assumption behind the scenario is that we need to do
FRTS
> to
> > avoid potential policing or egress blocking. In other words, we
cannot
> > utilize all the potential bandwidth on the physical interface, so we
use
> > FRTS
> > to create a kind of artificial congestion.
> >
> > It would be necessary in this scenario to create a priority queue
for
> the
> > voice traffic so that it does not experience queuing delay. But we
are
> > still
> > only sending bytes to the interface, by default, every 125 ms. The
> voice
> > packet may be "first in the boat", but still the boat is too
infrequent,
> > so we
> > still need to decrease the Tc to something that does not blow the
> > end-to-end
> > delay budget.
> >
> > But sure, for voice traffic you would like to avoid FRTS entirely if
you
> > can.
> >
> > HTH,
> >
> >
> > Bob Sinclair
> > CCIE #10427, CCSI 30427
> > www.netmasterclass.net
> >
> > ----- Original Message -----
> > From: CCIEin2006
> > To: Leigh Harrison
> > Cc: Cisco certification
> > Sent: Tuesday, January 03, 2006 12:02 PM
> > Subject: Re: FRTS Time Interval
> >
> >
> > Why does it have to wait a full 125ms for the boat? If there is
enough
> > bandwidth the packet should be sent immediatley, no? If there is
> > congestion
> > how is playing with time intervals going to give you extra
bandwidth?
> >
> > On 1/3/06, Leigh Harrison <ccileigh@gmail.com> wrote:
> > >
> > > Hey there,
> > >
> > > You have to think of it in terms of overall delay. Cisco
recommends
> > > between 150ms and 200ms for an end to end VoIP conversation to be
of
> > > good quality.
> > >
> > > If your Tc is set to 125ms and a voice packet misses the boat for
that
> > > time period, then he's got to wait 125ms before the next boat
arrives.
> > > This takes a big chunk out of your total budget of 150ms (for
> example),
> > > leaving you with only 25ms to play with.
> > >
> > > If your Tc is set to 10ms, then our brave stranded packet will
only
> have
> > > to wait for 10ms for the next boat to arrive, taking much less of
a
> bite
> > > out of our 150ms budget. Which is a good thing.
> > >
> > > LH
> > >
> > >
> > >
> > >
> > > CCIEin2006 wrote:
> > >
> > > >Can someone please explain how changing the default Tc from 125ms
to
> > 10ms
> > > >benefits you when running voice traffic over a frame relay link?
> > > >I understand that voice traffic is very intolerant of delay and
> jitter
> > > but
> > > >how does changing your time interval help in this situation? Do
the
> > > packets
> > > >get broken up as in frame relay fragmentation?
> > > >
> > > >Maybe someone can explain what role the time interval plays in
> traffic
> > > >shaping?
> > > >
> > >
>
>_______________________________________________________________________
> > > >Subscription information may be found at:
> > > >http://www.groupstudy.com/list/CCIELab.html
> >
> >
This archive was generated by hypermail 2.1.4 : Wed Feb 01 2006 - 07:45:47 GMT-3