From: Fadiltakipte (fadiltakipte@hotmail.com)
Date: Sat Jan 04 2003 - 13:03:50 GMT-3
Tom,
Your calculation logic for Be seems wrong to me. Usually (Be+Bc) /Tc must be
the remote port speed.(This is not the main logic, there are some other
considerations calculating these values). If you say yours depending on a
logic please let me know.
Fadil
----- Original Message -----
From: "Tony Schaffran" <tschaffran@cconlinelabs.com>
To: "'stefan vogt'" <stefan-uwe_vogt@web.de>; <ccielab@groupstudy.com>
Sent: Saturday, January 04, 2003 6:46 AM
Subject: RE: FRTS Question
> I just used the numbers that were given for an example. I did not do any
> calculations.
>
> If you calculate Tc, then the actual Bc would be 64000
>
> Does that clear it up?
>
>
> Tony Schaffran
> Network Analyst
> CCNP, CCNA, CCDA,
> NNCDS, NNCSS, CNE, MCSE
>
> CCOnlineLabs.com
> http://www.cconlinelabs.com
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> stefan vogt
> Sent: Saturday, January 04, 2003 6:07 AM
> To: ccielab@groupstudy.com
> Subject: Re: FRTS Question
>
> Hello Tony,
>
> I have some problems to understand your example.
>
> I agree to
> R1
> CIR=512000 (port speed of local)
> MinCIR=384000 (carrier enforced CIR)
>
> But how do you derive
> Be=1544000 (port speed of remote)
> Bc=193000 (1/8th port speed of remote)?
>
> http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a
> 00800d6788.shtml
> states that
> 1. The Tc value is not directly configured on Cisco routers. It is
> calculated after the Bc and CIR values are configured
> 2. Tc cannot exceed 125 ms
>
> When using Tc = Bc / CIR with your values then
> Tc=193000[kbit]/384000[kbit/s]~0,5s... I think I have to use the carrier
> enforced Cir in this equation?
>
> Who can help me out of this?
>
> Thanks,
> Stefan
>
> > ----- 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
> > > > > .
> > > > .
> > > .
> > .
> ________________________________________________________________________
> ______
> Ent- oder weder? Nein! Wer den nicht kauft, der platzt vor Neid:
> M E D I O N - PC P4 2.4 kompl. nur 969,- http://www.mempag.de/xmas3.php
> .
> .
.
This archive was generated by hypermail 2.1.4 : Sat Feb 01 2003 - 07:33:41 GMT-3