From: Carlos G Mendioroz (tron@huapi.ba.ar)
Date: Tue Oct 08 2002 - 07:44:12 GMT-3
Mamoor,
nice one!
Some comments inline:
Ahmed Mamoor Amimi wrote:
> Hello,
> Tokens are added to the Bucket in time Tc and those tokens are consumed
> with the data that wants to travel on the FR. This is just like a
> ZOO tickets. U cant enter the ZOO if u dont have ticket and we can also
> called this a "supply and demand" , so the # of tickets(token) should
> be the same as the customers(data) awaiting.
> It is possible that there would be more customers(data) and less
> tickets(tokens)
> or less customers and more tickets. Tickets are added for sell at a certian
> time that is Tc. If consider that tickets are added to the booth at 1sec per
> ticket to be sold and there is no customer to purchase it then tickets will
> be added to the booth till its limit and that is capacity of the
> booth(bucket),
> after that no tickets will be added to the box. now consider if the capacity
> is
> filled with 100 tickets at the booth and in 1sec 100customers arrivied then
> all
> the tickets will be sold and 0 tickets will be left in the both. The rate
> for
> tickets to be added to the booth will remain the same that is 1sec per
> ticket,
> now customer will wait till the booth fills to its capcity.
>
> Now at this time there will be 2 condition :
>
> 1- the tickets will be sold next time when the booth will be fill to its
> capacity
> that is 100 ticket (so customer have to wait)
The first customer will take the next ticket coming to the booth, so
there will be no "100 seconds" wait. You need not have the booth full
for it to sell tickets.
>
> 2- the ticket will be sold next time when booth will be fill to its capacity
> for
> atleast 25% that is atleast 25tickets in the booth. (customer will be
> entertain but
> gradually).
I don't understand this one.
>
>
> Now cut the ZOO topic and come to our Bucket,CIR, Be, Tc talks.
>
> Where Bucket was the Booth
> CIR was the Customer rate of coming
> Be was execess Customer that comes
> Tc was the time the tickets was added to the booth
>
>
> Bucket = CIR + EIR
>
>
> -Mamoor
There is a problem here. If you are at the zoo, you have no control
over the customer's rate. Customer come when they feel like it!!!
Your control is at the zoo entrance, and only there.
You have:
Tc: time interval at which tickets are added to booth
Bc: number of tickets added each Tc
CIR: relation between those two
Be: extra capacity of tickets at booth (can't hold more than Bc+Be)
You can also have:
Ar: speed of a transport belt that carries customers from booth
to Zoo, measured in customers per second.
Also, when management gets involved and implement a customer dynamic
shaping, you get
mincir: minimum rate of tickets that a booth can receive (multiply
by Tc to get how many tickets you get at a minimum when park is full
so you are getting BECNs :-)
>
>
>
> ----- Original Message -----
> From: Erling Bjxntegerd (Privat) <erli-b@online.no>
> To: <Svuillaume8@aol.com>
> Cc: <ccielab@groupstudy.com>
> Sent: Tuesday, October 08, 2002 12:56 AM
> Subject: Re: FRTS
>
>
>
>>Hi,
>>my opinion about Frame Relay Traffic Shaping is as follows:
>>
>>mincir = guaranteed BW provided by the provider ( per second )
>>cir = guaranteed average BW provided by the provider ( per second )
>>max rate / access rate ( per second )
>>Tc = period of time where Bc and Be are forwarded. Normally TC=125s => 8
>
> Tc periods
>
>>Bc=cir/(nbr. of Tc periods) ( per Tc period )
>>max rate / access rate = (Bc+Be)*8 => Be = (AR/8)-Bc ( per Tc period, in
>
> this case Tc = 125 ms )
>
>>Traffic over max rate cause provider to drop.
>>Traffic over cir make the DE-bit activated
>>By receiving BECN traffic are throttled to mincir
>>
>>A good link
>>http://www.cisco.com/warp/public/125/traffic_shaping_6151.html
>>
>>Example:
>>int s0
>> encapsulation fram-relay
>> no fair-queue
>> fram-relay traffic shaping
>> fram-relay class serial-out
>>
>>map-class fram-relay serial-out
>> fram-relay adaptiv-shaping becn
>> fram-relay cir <>
>> fram-relay mincir <>
>> frame-relay Bc <>
>> fram-relay Be <>
>>
>>Best Regards
>>Erling Bjontegard
>>
>>
>>
>>
>>----- Original Message -----
>>From: <Svuillaume8@aol.com>
>>To: <ccielab@groupstudy.com>
>>Sent: Monday, October 07, 2002 8:07 PM
>>Subject: FRTS
>>
>>
>>
>>>HI,
>>>
>>>Jeff doyle says:
>>>
>>>CIR = Port physical speed
>>>Mincir= CIR ( cir provides by carrier)
>>>Bc= remote speed circuit /8
>>>Be<= port speed of the remote router
>>>
>>>Is it correct to define a FRTS?
>>
>
-- Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
This archive was generated by hypermail 2.1.4 : Tue Nov 05 2002 - 08:35:42 GMT-3