From: Narvaez, Pablo (Pablo.Narvaez@xxxxxxxxxxxxx)
Date: Mon Mar 04 2002 - 22:09:43 GMT-3
Thanks a lot Bob!! that's exactly what I was looking for :-) ..
Cheers,
-Pablito, hockito, yansito
-----Original Message-----
From: Bob Sinclair [mailto:bsin@erols.com]
Sent: Lunes, 04 de Marzo de 2002 07:00 p.m.
To: Narvaez, Pablo
Cc: ccielab@groupstudy.com
Subject: Re: FRTS
Pablo,
Check out this link:
http://www.cisco.com/warp/public/125/traffic_shaping_6151.html
It is one of the best for FRTS. I think you will see that the Be = 2000. Ac
cess-rate = (Bc + Be)/Tc Here Tc is .125 seconds. Tc = Bc/CIR Here, 60
00/48000
-Bob
----- Original Message -----
From: "Narvaez, Pablo" <Pablo.Narvaez@getronics.com>
To: "Williams, Glenn" <WILLIAMSG@PANASONIC.COM>; "Peter Whittle" <peter@whittle
-systems.demon.co.uk>; "kym blair" <kymblair@hotmail.com>
Cc: <ccamarda@bellsouth.net>; <rwheat@ami.com.au>; <avantus1@hotmail.com>; <cci
elab@groupstudy.com>
Sent: Monday, March 04, 2002 7:30 PM
Subject: RE: FRTS
> I was double checking the explanation that Peter gave below... I wonder how h
e came to "be" value? ..... is there a formula I can use to calculate the "be"?
From my understanding, if I'm given these values:
>
> >>> > - at 48Kbps, discard eligible
> >>> > at 64kbps, frame discard
>
> then I would assume that the access-rate is 64k since I can't transmit anythi
ng above that value and the packets will be dropped.... so, cir=48k and be=16k
(be= access_rate - cir) ..... Is that ok? ...
>
> Thanks!!
>
> -hockito-
>
>
>
> -----Original Message-----
> From: Williams, Glenn [mailto:WILLIAMSG@PANASONIC.COM]
> Sent: Martes, 19 de Febrero de 2002 08:46 a.m.
> To: 'Peter Whittle'; kym blair
> Cc: ccamarda@bellsouth.net; rwheat@ami.com.au; avantus1@hotmail.com; ccielab@
groupstudy.com
> Subject: RE: FRTS
>
>
> Peter,
>
> Excellent explanation, and very timely for myself. Thanks for sharing this.
> Have one question. Never heard of the Maximum Line Rate. So I understand
> its calculation is = CIR + mincir/TC correct?
>
> Is this a rough guideline on what the port speed ought to be?
>
> TIA
> GW
>
> -----Original Message-----
> From: Peter Whittle [mailto:peter@whittle-systems.demon.co.uk]
> Sent: Friday, February 15, 2002 6:26 PM
> To: kym blair
> Cc: ccamarda@bellsouth.net; rwheat@ami.com.au; avantus1@hotmail.com;
> ccielab@groupstudy.com
> Subject: Re: FRTS
>
>
> as a config then:
>
> frame-relay cir 48000
> frame-relay bc 6000
> frame-relay be 2000
> frame-relay mincir 16000
>
> Peter
>
> In message <F42fJ8VrRQvXlaoY99E00026258@hotmail.com>, kym blair
> <kymblair@hotmail.com> writes
> >So what was the answer? Here are BS's original parameters and solution.
> >Please frame your corrected solution is a config like his (rather than
> >text):
> >
> >> >> Kang BS wrote:
> >>> > 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
> >>> >
> >
> >Thanks. Kym
> >
> >----------------------------------------------------------------------
> >
> >>From: Peter Whittle <peter@whittle-systems.demon.co.uk>
> >>Reply-To: Peter Whittle <peter@whittle-systems.demon.co.uk>
> >>To: Carolyn Camarda <ccamarda@bellsouth.net>
> >>CC: Richard Wheat <rwheat@ami.com.au>, Kang BS <avantus1@hotmail.com>,
>
> >> ccielab@groupstudy.com
> >>Subject: Re: FRTS
> >>Date: Fri, 15 Feb 2002 22:53:01 +0000
> >>
> >>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 13 2002 - 10:56:52 GMT-3