From: Colin Barber (Colin.Barber@xxxxxxxxxxxxxx)
Date: Wed Aug 28 2002 - 17:50:28 GMT-3
Hi Jim,
Port speed is based on one second as at it is quoted in bits per second.
However the speed is provided from a synchronised clock and therefore a
subset of a second has a defined number of bits it can send. Do you mean the
Tc from the Telco is based on 1 second?
I agree that Cisco's shaping values has nothing to do with the telcos and
yes, once data is passed out of the traffic shaping algorithm it is send
towards the interface. However that interface only has small hardware
buffers.
Normally on a serial interface you have the software queue (FIFO, WFQ) to
provide a buffer for data arriving from fast LAN interfaces. With FRTS the
software queue is before TS and therefore once you send data out of the
algorithm you need to get it onto the wire as soon as possible. If you a
sending data faster than the AR at that fraction of a second you will
overflow your buffers and start dropping packets, the very thing FRTS is
trying to avoid.
Colin
-----Original Message-----
From: Jim Brown [mailto:Jim.Brown@caselogic.com]
Sent: 28 August 2002 20:53
To: 'Colin Barber'; Bauer, Rick; ccielab@groupstudy.com
Subject: RE: I need FRTS help or review - TIME TO VOTE
I need to clarify something. I'm not saying you can burst above the AR. The
provider usually provides a port speed based on a single second, the number
of bits you can transmit in one second. You, in our discussions, are viewing
the AR based on subsets of that second.
Cisco's BC variable has nothing to do with a provider value. Cisco's BC
variable is merely an increment fabricated by the software used in the Token
Bucket Algorithm to help calculate how much data to send towards the
hardware/interface queue.
All of the Cisco shaping values (Be, Bc, Tc, CIR, and minCir) provide a
shaping mechanism for pushing data towards the hardware queue and eventually
onto the wire.
-----Original Message-----
From: Colin Barber [mailto:Colin.Barber@telewest.co.uk]
Sent: Wednesday, August 28, 2002 1:30 PM
To: Bauer, Rick; ccielab@groupstudy.com
Subject: RE: I need FRTS help or review - TIME TO VOTE
I think the confusion is:
can (BC+BE)/Tc be greater than AR as Jim is saying because the interface
will buffer the excess or
(BC+BE)/Tc <= AR because the burst has to be transmitted within one Tc
Your link states that the parameters control the rate of traffic onto the
interface but not onto the line so is the interface buffering any excess and
can you have a large excess?
To put it another way: if your CIR is less than the access speed of the
interface and you wish to burst to the full access speed, do you work out BE
so that the access rate is achieved only in the first Tc or the access rate
is achieved over a full second?
I think we need a vote on the two options - I'm for option 2
For example:
CIR = 64000
Access rate = 96000
Tc = 1/8th sec
BC=8000
To burst up to the AR what is the value of BE?
option 1 BC=32000 (8*BC)+BE = 96000
option 2 BC=4000 at one Tc BC+BE=12000*Tc = 96000
Colin
-----Original Message-----
From: Bauer, Rick [mailto:BAUERR@toysrus.com]
Sent: 28 August 2002 19:55
To: 'ccielab@groupstudy.com'
Subject: RE: I need FRTS help or review
This should help. The first couple of lines will answer your question in
regard to CIR, BE, BC.
http://www.cisco.com/warp/customer/125/21.shtml
Rick, #9482
-----Original Message-----
From: Volkov, Dmitry (Toronto - BCE) [mailto:dmitry_volkov@ca.ml.com]
Sent: Wednesday, August 28, 2002 2:07 PM
To: 'Jim Brown'; 'Colin Barber'; 'Omer Ansari'
Cc: 'ccielab@groupstudy.com'
Subject: RE: I need FRTS help or review
Jim,
You are right traffic will be delayed and sent within 9th Tc interval
(assuming Tc=1/8 sec).
But Be is still Be - it is number of bits, and Be+Bc =< Port Speed
(clocking) * Tc.
We have to put actual number in config.
40000 bits will not be transmitted during 1st Tc - only 12000 bits.
Other bits will be delayed until 9th Tc.
Be - number of bits will be transmitted within 1st Tc ==> be = 12000
-8000(Bc) = 4000 bits
and this number 4000 we have to put in config as Be. The other bits will be
delayed / dropped, whatever.
I'm not 100% sure about it, but I got this logic from CCO.
Colin right - the documentation on this subj is very unclear.
This subj is like religion for me - believe or not believe :)
Dmitry
> -----Original Message-----
> From: Jim Brown [mailto:Jim.Brown@caselogic.com]
> Sent: Wednesday, August 28, 2002 11:35 AM
> To: 'Colin Barber'; 'Omer Ansari'; 'ccielab@groupstudy.com'
> Subject: RE: I need FRTS help or review
>
>
> You do not necessarily need 320Kps available during the first
> interval. The
> packets are software queued before they are placed onto the
> TxRing. This is
> the whole idea behind shaping.
>
> They are not placed on the wire at exactly the same speed
> designated per TC
> interval.
>
> List, if I'm way off base please correct me and help me see the light.
>
> -----Original Message-----
> From: Colin Barber [mailto:Colin.Barber@telewest.co.uk]
> Sent: Wednesday, August 28, 2002 9:09 AM
> To: 'Omer Ansari'; 'ccielab@groupstudy.com'
> Subject: RE: I need FRTS help or review
>
>
> What's the access speed of the interface? If it's 96k then this is
> incorrect. In the first time slot BC+BE=40000. For that
> amount of data to be
> transferred in the first timeslot the access speed will need to be
> 40000*8=320kbps.
>
> Colin
----------------------------------------------------------------------------
-- Live Life in Broadband www.telewest.co.ukThe information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer.
============================================================================ ==
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:41 GMT-3