From: Ahmed Mamoor Amimi (mamoor@ieee.org)
Date: Wed Oct 09 2002 - 07:19:18 GMT-3
Oh ! that one .... i made this paper when i was very confused on FRTS. This
was my conclusion after reading from many books and CCO links. I guess this
helps as it helped me gaining understanding of FRTS.
-Mamoor
----- Original Message -----
From: Chris Hugo
To: Carlos G Mendioroz ; Ahmed Mamoor Amimi
Cc: Erling_Bjxntegerd_(Privat) ; Svuillaume8@aol.com ;
ccielab@groupstudy.com
Sent: Tuesday, October 08, 2002 9:56 PM
Subject: Re: FRTS
Very Good Mamoor.
Can you point us out where you saw this rule? I have never seen that rule
documented.
Thanks,
chris hugo
> 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).
Carlos G Mendioroz wrote:
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(b! ucket),
> 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% th! at 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 c! ustomers 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)
> To:
> Cc:
> 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 fo! rwarded. 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:
>>To:
>>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 LW7 EQI Argentina
-----------------------------------------------------------------------------
-
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos, & more
faith.yahoo.com
This archive was generated by hypermail 2.1.4 : Tue Dec 03 2002 - 07:23:09 GMT-3