From: Joe Chang (changjoe@earthlink.net)
Date: Fri Jan 03 2003 - 13:21:58 GMT-3
Thanks for clearing this up for me Tony.
----- Original Message -----
From: "Tony Schaffran" <tschaffran@cconlinelabs.com>
To: "Joe Chang" <changjoe@earthlink.net>; <ccielab@groupstudy.com>
Sent: Friday, January 03, 2003 12:22 PM
Subject: Re: FRTS Question
> Actually, that is not quite correct. The CIR and MinCIR is the only
> parameter provided by the service provider. FRTS, as I understand it, is
a
> way to get more out of your service provider by bursting until congestion
is
> detected and lowering your risk for packet drop's. CIR, Bc, and Be are
used
> to calculate an expectable burst rate based on your router port speeds you
> have negotiated with your service provider. (ie. 384k CIR burst to 512k)
> 512k being your port speed.
>
> Let's keep it simple and say that is what you have negotiated with your
> provider on R1 and 768k burst to T1 at R2. For FRTS, these would be your
> settings:
>
> R1
> CIR=512000 (port speed of local)
> Be=1544000 (port speed of remote)
> Bc=193000 (1/8th port speed of remote)
> MinCIR=384000 (carrier enforced CIR)
>
> R2
> CIR=1544000 (port speed of local)
> Be=512000 (port speed of remote)
> Bc=64000 (1/8th port speed of remote)
> MinCIR=768000 (carrier enforced CIR)
>
>
>
>
> Tony Schaffran
> Network Analyst
> CCNP, CCNA, CCDA,
> NNCSS, NNCDS, CNE, MCSE
>
> www.cconlinelabs.com
> "Your #1 choice for Cisco rack rentals."
>
>
> ----- Original Message -----
> From: "Joe Chang" <changjoe@earthlink.net>
> To: <ccielab@groupstudy.com>
> Sent: Friday, January 03, 2003 6:32 AM
> Subject: Re: FRTS Question
>
>
> > I think the CIR , minCIR, Bc and Be values that are determined by the FR
> > service provider. The customer-end would have to follow these values
when
> > configuring FRTS. My reasoning is that the purpose of FRTS is to avoid
> frame
> > relay discards within the provider's network, and only the provider can
> tell
> > what FRTS parameters will avoid congestion.
> >
> > However I'm not dismissing your question; it is incredibly relevant in
the
> > real world. My personal experience with union-entrenched FR suppliers is
> > that you would be lucky to get them tell you what CIR has been
provisioned
> > for you.
> >
> > In your calculations remember that Bc = CIR* Tc. When you scale up the
> Bc,
> > the Tc will decrease, you will have to consider more slots in your
second
>
> > example.
> >
> > I have a question myself: is it possible to implement congestion
> management
> > as CBWFQ on the same interface where FRTS is configured? How about RSVP?
> >
> > ----- Original Message -----
> > From: "Joe" <groupstudy@comcast.net>
> > To: <ccielab@groupstudy.com>
> > Sent: Thursday, January 02, 2003 11:26 PM
> > Subject: FRTS Question
> >
> >
> > > This is a lengthy question, but I would really appreciate the time you
> > > might take to help me with this.
> > >
> > > When configuring FRTS, the value chosen for Bc is typically CIR/8,
> > > assuming that an interval Tc of 125 ms is acceptable. Assume I have
no
> > > real-time traffic such as voice or video.
> > >
> > > For the sake of example, suppose I have a circuit that is 4 timeslots,
> > > or 256000 bps and the carrier CIR is 192000 bps. At the other end of
> > > the link I have a T1 with a carrier CIR of 768000 bps and this end
also
> > > supports other PVCs. I am going to want to configure FRTS on the T1
> > > side of the link for two reasons: 1) so it can throttle down to the
> > > lower capacity link and 2) so I can reserve bandwidth for the other
PVCs
> > > that are being services.
> > >
> > > The first question is this: When deciding on Bc, is the value for CIR
> > > taken from the CIR you specify in the FRTS config or is it 1/8 the CIR
> > > from the carrier?
> > > The second question is this: What if any are the benefits of shaping
on
> > > the lower speed link as well? Would this use the same parameters for
> > > shaping?
> > >
> >
> ------------------------------------------------------------------------
> > > ----------------------------------------------
> > >
> > > This is what I believe to be true about FRTS as it applies to this
> > > example:
> > >
> > > First of all, I would configure CIR = 256000 and MINCIR = 192000.
> > > Anyone disagree with that?
> > >
> > > If I configure Bc to be 192000/8 or 24000, then I will be sending out
> > > 24000 bits every time interval. This allows me to specify a Be of
> > > 64000, which would then be transmitted during the first time interval
if
> > > no congestion is detected. The data transmitted is:
> > >
> > > Data transmitted = (Bc+Be) + Bc + Bc + Bc + Bc + Bc + Bc + Bc =
> > > (24000+64000) + 24000 + 24000 + 24000 + 24000 + 24000 + 24000 + 24000
=
> > > 256000
> > >
> > > As long as I don't experience congestion, this seems like a desirable
> > > flow of traffic, even though some traffic can be marked DE.
> > >
> > > On the other hand, if I configure Bc to be 256000/8 or 32000, then I
> > > will be sending out 32000 bits every time interval. If I configure a
Be
> > > of anything other than 0, I will attempt to transmit this during the
> > > first time interval. Suppose I set Be to 64000 again in this case.
The
> > > data transmitted is:
> > >
> > > Data transmitted = (Bc+Be) + Bc + Bc + Bc + Bc + Bc + Bc + Bc =
> > > (32000+64000) + 32000 + 32000 + 32000 + 32000 + 32000 + 32000 + 32000
=
> > > 320000
> > >
> > > In this case I am attempting to transmit beyond the physical capacity
of
> > > the 256000 bps link, so 64000 bits of traffic will be FIFO queued
> > > (unless I specify otherwise.) If I queue and carry over 64000 bits
into
> > > the next time interval then I can no longer burst, so I am down to a
> > > rate of 256000 bits again. But this is STILL over the carrier CIR, so
> > > this traffic is marked DE. This seems like it would create the
> > > potential for packet drop/loss.
> > >
> > > So which is the better configuration?
> > >
> > > Thanks!
> > >
> > > Joe
> > >
> > >
> > > As a follow on to this:
> > >
> > > Please take a look at the link below. I can't quite grasp why the
> > > author omits Be on the remote side but includes it on the hub side.
> > >
> > > I am also not in agreement with the math used to calculate the byte
> > > increment at the bottom of the link.
> > >
> > > Any comments would be appreciated.
> > >
> > > Joe
> > >
> > > <http://www.cisco.com/warp/public/125/traffic_shaping_6151.html>
> > > http://www.cisco.com/warp/public/125/traffic_shaping_6151.html
> > > .
> > .
> .
.
This archive was generated by hypermail 2.1.4 : Sat Feb 01 2003 - 07:33:40 GMT-3