From: Navin MS (navin_ms07@yahoo.com)
Date: Thu Jun 08 2006 - 14:31:26 ART
Hi Godswill,
Yes, when CIR is configured Bc also does get configured but this is what I think happens...
Assume you have a CIR of 128,000 bps and Tc = 125ms. This means Bc = 16000 bits (or 2000 bytes).
As we both agree, we cannot send more than 16000 bits per 125ms interval. Now we have two ways of
sending traffic in this interval. Either send a constant traffic throughout the 125ms interval
(ie., 16000/125 = 128 bits per msec) or send one burst of 16000 bits anytime during the interval.
When we do the latter, we have used the bursting capability which CONFORMS TO CIR. When it is
constant rate, we indeed conformed to CIR but WITHOUT BURSTING !! This is what I meant when I said
we are not using the bursting capability when constant rate traffic is sent. That is Bc will
indeed get configured for every CIR given, but one MAY NOT USE BURSTING CAPABILITY.
So, if one gets a 2000-byte packet after say, 15msec, the FRTS would use up all the Bursting
capability for that interval. For the rest of the (125-15)=110msec interval, one cannot send more
traffic into the network (without using excess burst capability). If I have to put a graph, the
bits sent would be along Y-axis and Time (in msec) will be on X-axis. And if we have to conform to
CIR, then the Product of bits and Time should not exceed configured CIR.
So IMO, the 2 options for FRTS router are.. either send constant traffic or burst out and shut up.
Though I personally believe that constant rate is possible only theoritically... real time traffic
is almost always bursty !!
Guess that makes it a little clear ?
Naveen.
--- Godswill Oletu <oletu@inbox.lv> wrote:
> Navin,
>
> Oops, I mistakenly was referring to a Tc of 10ms as the maximum recommeded; actually I meant to
> say it is the minimum recommended, and the example that I did, where the router replied with
> 'doesn't make sense' is an attempt to reduce my timing interval to the lowest possible and also
> reducing the amount of traffic sent per timing.
>
> To transmit at constant CIR and "not using Bc" as you indicated in your other post, will result
> into something like:
>
> !
> policy-map nnn
> class class-default
> shape average 128000 128000
> !
> !
> interface Serial0/1
> ip address 172.1.17.7 255.255.255.0
> encapsulation frame-relay
> frame-relay map ip 172.1.17.6 205 broadcast
> service-policy output nnn
> !
>
> R3725-R3#sh policy-map interface ser0/1
>
> Serial0/1
>
> Service-policy output: nnn
>
> Class-map: class-default (match-any)
> 63 packets, 2557 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: any
> Traffic Shaping
> Target/Average Byte Sustain Excess Interval Increment
> Rate Limit bits/int bits/int (ms) (bytes)
> 128000/128000 32000 128000 128000 1000 16000
>
> Adapt Queue Packets Bytes Packets Bytes Shaping
> Active Depth Delayed Delayed Active
> - 0 29 2115 0 0 no
>
> This is the only way I can think of right now, on how you can transmitt constantly at CIR and
> "not use Bc" But, the other question will be; Is this a good idea to make the Tc equal to 1sec?
> Because large chunk of traffics will tie down the link and smaller traffics, might be waiting
> endlessly in the queue to get their own shot at the transmit ring.
>
>
> Thanks.
> Godswill Oletu
> ----- Original Message -----
> From: Kayode Oladipo
> To: godswill.oletu@footstar.com ; oletu@inbox.lv
> Sent: Thursday, June 08, 2006 9:42 AM
> Subject: FW: Re: FRTS Lab 1 - 7.2 question.
>
>
>
>
>
>
>
> ----------------------------------------------------------------------------
>
> From: Godswill Oletu <oletu@inbox.lv>
> Reply-To: Godswill Oletu <oletu@inbox.lv>
> To: Navin MS <navin_ms07@yahoo.com>, Roberto Fernandez <rofernandez@us.telefonica.com>,
> Brian McGahan <bmcgahan@internetworkexpert.com>, Leigh Harrison <ccileigh@gmail.com>, Andi
> Bennett <bigandibennett@yahoo.com>
> CC: ccielab@groupstudy.com
> Subject: Re: FRTS Lab 1 - 7.2 question.
> Date: Thu, 08 Jun 2006 08:08:15 -0400
> >Navin,
> >
> >We might be saying the same but differently; the thing is I really do not
> >consider it a burst, if you allow me to burst upto Bc within each Tc but at
> >the end of the day, I cannot send more than my CIR. After all is said and
> >done, I am still limited to my CIR.
> >
> >And, I am kind of having a weird feeling that, if a question states that the
> >CIR is eg 128kbps and the question further states that allow for some burst
> >and one configure only CIR and Bc; he/she have not sufficiently fulfill the
> >tasks set forth in the question.
> >
> >Configuring CIR and Bc only fulfill the aspect of the task that is dealing
> >with CIR and by including a Bc; you are telling the router that, you want to
> >be in charge; you want to be the one who decides the rate at which you want
> >to send on each Tc timeslot and by that you are also dictating to the router
> >the value of the Tc to be used. And the router will only accept you Bc value
> >if it makes sense. If on the other hand, you did not configure Bc, the
> >router will configure one for you, but all these have not fulfill the aspect
> >of the task that states '....allow for some burst'.
> >
> >R3640-R1(config-pmap-c)#shape average 128000 ?
> > <256-154400000> bits per interval, sustained. Needs to be multiple of
> >128.
> > Recommend not to configure it, the algorithm will find
> >out
> > the best value
> > <cr>
> >
> >R3640-R1(config-pmap-c)#shape average 128000
> >
> >*note, what the router is saying about Bc'...recommended not to configure
> >it, the algorithm will find out the best value'
> >
> > >
> > > 1) Send traffic at a constant rate of CIR (in which case Bc of 4000 is
> >unused). Though you were
> > > allowed to burst, you didn't :)
> > >
> >
> >Can you explain this further? Is it possible not to use Bc? How can one send
> >at constant rate of CIR without using Bc? My experience had been, even if
> >you did not specify Bc, the router will calculate and impose one on you.
> >
> >The only theorical time, I think one can send at constant rate of CIR will
> >be when Tc= 1 sec, but the maximum recommended Tc is 10ms, so whether, we
> >like it or not, we will be forced to divide our CIR into junks of Bc and are
> >allowed to burst from 0 to that Bc value within each Tc.
> >
> >Look at my attempt at my failed attempt at forcing my router to accept a
> >very high Tc of 2ms; which is a long shot from the theoritical Tc vlaue of
> >1sec assumed above.
> >
> >R3640-R1(config-pmap-c)#shape average 128000 256
> >less than 1000 bits in an interval doesn't make sense
> >
> >R3640-R1(config-pmap-c)#
> >
> >The router took on some little attitude there, telling me that what I am
> >trying to accomplish 'doen't make sense'.
> >
> > >
> > > 3) Send a burst of (Bc + Be) bits per Time interval (if Be is configured,
> >in which case you are
> > > using Bc of 4000 and Be of 2000 say). When you do this, you are
> >effectively sending more than CIR.
> > > That is, your Tx rate = (Bc+Be)/Tc which is greater than (Bc/Tc).
> > >
> >
> >This not guarantee at all time, in essence your effective/constant Tx rate
> >will not be (Bc+Be)/Tc; In shaping with Bc and Be configured, you can only
> >send above Bc per timing interval when you have accumulated credit to do so
> >from the previous timing interval.
> >
> >Read the section 'Traffic Sahping and Rate of Transfer here:
>
>
>http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt4/qcfpolsh.htm
> >
> >In policing, configuring Bc & Be and the process of determining how the Be
> >get used, involve a complex set of algorithms, that will include borrowing
> >tokens, compounded debts, etc.
> >
> >Read the section 'Rate Limits' and other sections below it:
>
>
>http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt4/qcfpolsh.htm.
> >
> >Excuse, my rather lengthy email and also remember that, there are many QoS
> >gurus on this list and I am not one of them.
> >
> >HTH
> >Godswill Oletu
> >HTH
> >Godswill Oletu
> >
> >
> >----- Original Message -----
> >From: "Navin MS" <navin_ms07@yahoo.com>
> >To: "Godswill Oletu" <oletu@inbox.lv>; "Roberto Fernandez"
> ><rofernandez@us.telefonica.com>; "Brian McGahan"
> ><bmcgahan@internetworkexpert.com>; "Leigh Harrison" <ccileigh@gmail.com>;
> >"Andi Bennett" <bigandibennett@yahoo.com>
> >Cc: <ccielab@groupstudy.com>
> >Sent: Thursday, June 08, 2006 12:16 AM
> >Subject: Re: FRTS Lab 1 - 7.2 question.
> >
> >
> > > Yes, When it comes to plain English.. a burst is thought of something in
> >excess that a router is
> > > sending into the FR cloud. BUT from a frame-relay perspective, it simply
> >says how many bits in
> > > burst can be sent in one Time interval. Bc just gives us bursting
> >capability which is very much
> > > required given the sporadic nature of real-time traffic. I have an easy
> >alternate way of
> > > understanding this. One can look at it this way.
> > >
> > > For a customer there are 4 options...
> > >
> > > 1) Send traffic at a constant rate of CIR (in which case Bc of 4000 is
> >unused). Though you were
> > > allowed to burst, you didn't :)
> > >
> > > 2) Send a burst of Bc bits per Time interval (in which case you are using
> >Bc of 4000 bits). When
> > > you do this, you are effectively sending CIR bps (Bc/Tc) as agreed.
> > >
> > > 3) Send a burst of (Bc + Be) bits per Time interval (if Be is configured,
> >in which case you are
> > > using Bc of 4000 and Be of 2000 say). When you do this, you are
>
=== message truncated ===
This archive was generated by hypermail 2.1.4 : Sat Jul 01 2006 - 07:57:32 ART