From: Joe Chang (changjoe@earthlink.net)
Date: Fri Jan 03 2003 - 11:32:54 GMT-3
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