From: Maurice Flint (mflint@xxxxxxxxxx)
Date: Sat Feb 16 2002 - 11:49:04 GMT-3
What seems to be confusing is the fact that some documentation reports that the
"Be" is only sent in the first Tc interval while other documentation reports th
at
the Be is sampled at the same Tc rate as the CIR and is sent evenly during each
period along with the data from the Bc calculation.
Peter Whittle wrote:
> Carolyn
>
> In Frame Relay
>
> CIR is the average rate that you can transmit at measured over a time
> period Tc without having the ingress port on the Frame network flag your
> frames as over contract by setting the DE bit.
>
> EIR is the rate that you can exceed CIR before the ingress port will
> discard your frames.
>
> Bc is the total number of bits that you can send in period Tc and not
> have the frames marked with DE.
>
> Be is the total number of bits in addition to Bc that you can send in
> period Tc that the switch will allow before discarding any excess
> traffic at the ingress port to the Frame network.
>
> These parameter are inter-related.
>
> CIR = Bc/Tc
>
> EIR = Be/Tc
>
> So you only need to specify 2 of the parameters. On a Carrier grade
> switch it is customary to specify CIR, Bc, and Be. Tc is normally fixed
> for the entire network. Incidentally over here in Europe Tc in use on
> most public networks is 1 Second.
>
> The shorter Tc the more responsive things are but you get less of a
> bandwidth free ride. If you are implementing FRTS, it is quite likely
> that you want to have the traffic shaper responsive so Tc as defined on
> the router may very well be << Tc set by the Telco on the Frame Network.
>
> So looking at the traffic from a Frame Relay Network perspective if you
> start CPE A end sending 0 traffic into the network and gradually
> increase the traffic that you attempt to send the following will happen:
>
> 1) traffic rate 0 up to CIR - Will be delivered to the B end.
>
> 2) traffic rate exceeds CIR but is less than CIR + EIR - frames will
> normally be delivered (depends how congested the network is, true in
> Europe) but frames where the total number of bits sent in period Tc
> exceed Bc will be marked with DE. Any DE marked frames may be discarded
> by any of the switching nodes in the Frame network if a node is
> congested.
>
> 3) An attempt is made for the traffic rate to exceed CIR + EIR - All
> frames will be discarded immediately at the port of ingress to the
> network until the rate drops down below CIR + EIR.
>
> ----
> At the B end you will see:
>
> 1) All frames delivered DE = 0 (or what ever was set by CPE at A)
>
> 2) The first frames up to a total Bc bits sent will be received with DE
> =0. The remaining frames up to an additional total of Be bits sent will
> be received with DE=1
>
> 3) The number of frames received will not increase. The total rate of
> arrival = CIR + EIR.
>
> ----
>
> In the real world (not as marketing tell it!)
>
> 1) as described above - most of the time (If not time to seek a new
> carrier)
>
> 2) First frames up to a total of Bc bits sent will be received with DE =
> 0. Some of the remaining frames will be received <= an additional total
> of Be bits sent will be received with DE = 1. The number less than
> those sent is a measure of how congested your carrier's network is on
> the path A to B.
>
> 3) Will rate limit somewhere between CIR and CIR + EIR.
>
> When one of the nodes is congested it will set FECN = 1 on frames
> forwarded towards the destination B. CPE B will then totally ignore the
> FECN as customers are want to do. Some traffic will be going back the
> other way. Ah ha! The congested node now has a frame returning to the
> sender A so it sets BECN = 1 and forwards it to A.
>
> In the normal way the customer still ignores any notification of
> Congestion and continues to send. The network becomes even more
> congested. Time for some serious action! The congested node is nolonger
> mildly congested (traffic exceeded a software configurable threshold
> either on an interface - ok, or on the whole switch - BAD news!
> Typically 50% of buffers in use / queues 50% full) but is seriously
> congested (again determined in software on the switch, perhaps 75% of
> buffers are in use / queues 75% full) so it starts to drop frames with
> DE=1 but forwards those with DE=0.
>
> Now users being users send even more traffic so now the poor old switch
> is in serious trouble! - "No room at the Inn!" There are ZERO free
> buffers! So no option just drop all frames coming in to the switch.
>
> RESULT no frames delivered!
>
> "The moral of the story is, behave!"
>
> -----
>
> The real world amended for FRTS.
>
> CPE A attempts to send an average amount of traffic defined by CIR as
> set on the router (This is probably higher than CIR defined by the Telco
> on the switch) and to control the bursts by queuing the traffic on
> egress from the router to delay some frames so as to reduce the average
> rate of transmission. Result a happy network with minimum frames lost,
> most of them arriving with DE = 0 and some of them arriving with DE = 1.
>
> If on some rare occasion the Telco network gets congested ('never
> happens, honestly'). Then when a frame is received at CPE A with BECN =
> 1 (or more typically > 50% of the frames received have BECN = 1), FRTS
> will slow down the average frame transmission rate to match the MINCIR
> setting on the router. (In this case MINCIR is normally set to or below
> the actual CIR on the Telco Switch.) So now as well behaved, good
> router citizens, our traffic now obeys the recommendations and reduces
> to comply with the Telcos CIR, all our frames get through and have DE =
> 0.
>
> When the congestion reduces and we receive less than 50% of our frames
> with BECN = 1 we can step up slowly back towards our peak rate.
>
> The reason that we want to behave well, besides being good router
> citizens, is that lost frames = lost TCP segments which causes TCP time-
> outs and then re-transmissions. (Remember the slow start algorithm,
> after every time-out we start with 1 segment wait for the successful
> acknowledgement then on to 2 segments, then 3 ... until we are using the
> full window size again or until another frame (segment) goes AWOL and
> our throughput collapses again!)
>
> =================
>
> So back to the problem.
>
> >> > - at 48Kbps, discard eligible
>
> Set CIR = 48000 bits/S
> =====
>
> >> > when receiving BECN, 16kbps should be guaranteed.
>
> Set MINCIR = 16000 bits/S
> =====
>
> >> > basic time interval 125ms
>
> Tc = 125 mS = 0.125 S
>
> => Bc = CIR x Tc = 48000 x 0.125 = 6000 bits
> ====
>
> >> > at 64kbps, frame discard
>
> Need EIR = 64000 - 48000 = 16000 bits/S
>
> but Tc = 0.125 S
>
> => Be = EIR x Tc = 16000 X 0.125 = 2000 bits
> ====
>
> Port speed is independent of the above.However, see design guidance 3
> below.
>
> So if CIR = 48 k, Tc = 0.125 S and Bc = 16000
> then port speed must exceed 48000 + 16000/0.125
> = 48000 + 128000
> = 176000. (see design guidance 3 below)
>
> However, good design from a Frame Relay network perspective with out
> oversubscription would lead to:
>
> 1) no individual CIR > 75 % port speed
>
> 2) sum of all CIRs on port < 75 % port speed
>
> 3) for each dlc in turn CIR + EIR < = port speed.
>
> If oversubsciption then (2) is amended to:
>
> 2') sum of all CIRs on port < 200 % port speed.
>
> Oversubscription is only available with the customers consent and CIR
> guarantees are nolonger valid. It would normally only be used when the
> customer knows that certain dlcs are not used simultaneously e.g some
> are only used for over night back, time of day variations, or some of
> the dlcs are only fro customer selected resilience to be used when the
> main dlci goes down.
>
>
> Remember all frames are transmitted bit synchronously onto the wire at
> port speed, say 128k. If the CIR = 48k then you can send continuously at
> 48 K and frames will be delivered, DE = 0. You may burst above the CIR
> up to CIR + EIR for a short period of time Tc and your frames will
> normally get through, though some will have DE = 1. Say EIR = 16k, then
> you can burst up to 64 k. You will never receive an average of more than
> 64 k no matter how much traffic you put into the network. If the network
> is congested then you will receive between 48 and 64 k of traffic.
>
> I hope that this helps.
>
> Peter
>
> In message <01b401c1b663$8934c900$0301010a@oemcomputer>, Carolyn
> Camarda <ccamarda@bellsouth.net> writes
> >How do you figure the BE value of 16k makes the line rate 176k? It would
> >seem that with 8 time intervals at 6k, that would be 48k and then 16k BE
> >which goes in the first time slot would
> >equal a total of 64k.
> >
> >
> >
> >----- Original Message -----
> >From: "Richard Wheat" <rwheat@ami.com.au>
> >To: "Kang BS" <avantus1@hotmail.com>
> >Cc: <ccielab@groupstudy.com>
> >Sent: Friday, February 15, 2002 9:21 x
> >Subject: Re: FRTS
> >
> >
> >> Good day,
> >>
> >> I think your BE should be 2000 not 16000. BC + BE = maximum line rate.
> >> Your BE value means the maximum line rate is 176kbps.
> >> Otherwise it looks ok.
> >>
> >> HTH,
> >> Richard.
> >>
> >> Kang BS wrote:
> >>
> >> > Hi,
> >> >
> >> > I have already read lot of stuff about FRTS including all of mail in the
> >> > archives
> >> > and cisco documents
> >> > (http://www.cisco.com/warp/public/125/21.shtml
> >> > http://www.cisco.com/warp/public/125/traffic_shaping_6151.html)
> >> >
> >> > But I am still confusing.
> >> >
> >> > On below question, Which is a correct configuration?
> >> >
> >> > - at 48Kbps, discard eligible
> >> > at 64kbps, frame discard
> >> > when recieving BECN, 16kbps should be guaranteed.
> >> > basic time interval 125ms
> >> >
> >> > - My solution is
> >> > frame-relay cir 48000
> >> > frame-relay bc 6000
> >> > frame-relay be 16000
> >> > frame-relay mincir 16000
> >> >
> >> > is mine right or else?
> >> >
> >> > please help me.
> >> >
> >> > thanks in advance.
> >> >
> >> > BS Kang.
> >> >
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 13:46:25 GMT-3