From: CCIEin2006 (ciscocciein2006@gmail.com)
Date: Tue Jan 03 2006 - 16:06:54 GMT-3
Thanks everyone,
That clears it up for me.
On 1/3/06, Brian McGahan <bmcgahan@internetworkexpert.com> wrote:
>
> > 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
> > >
> > >
> _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> _______________________________________________________________________
> > 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