From: CCIEin2006 (ciscocciein2006@gmail.com)
Date: Tue Jan 03 2006 - 15:20:14 GMT-3
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
This archive was generated by hypermail 2.1.4 : Wed Feb 01 2006 - 07:45:47 GMT-3