Gaz wrote:
> 
> Bit embarrassed. You say you may have simplified it too much,
> but my brain
> is still buzzing!
> 
> How does the time interval T come in to it, and who decides the
> time
> interval. If you've got bursty traffic will a longer time
> interval let you
> get away with murder (on average).

Good questions. I don't think I described Bc correctly, so no wonder you're
confused! I can tell you what Darren Spohn says in his book, Data Network
Design. Then I'll tell you what Cisco says, and hopefully I won't leave the
situation even messier than it already is, and if I do, hopefully somebody
will clean it up. ;-) I'll insert my own pithy comments in parentheses. Here
goes:

Spohn:

"The CIR is computed as the number of bits in a committed Burst size, Bc,
that can arrive during an averaging interval T such that CIR = Bc/T.

If the number of bits that arrive during the interval T exceeds Bc, but is
less than an excess threshold, Bc + Be, then the subsequent frames are
marked as DE.

At present, there is no uniform method for setting the interval T. If T is
set too small, such that Bc is less than the length of a single frame, then
every frame will be marked DE. If T is set too large, the buffer capacity in
the FR access node may not be practical.... In public FR, it is the
responsibility of the provider to set the value of T, and the value of 1 is
often used to match the line measure of bps."

And here's what Cisco says:

"frame relay bc 

The amount of data to send per each Tc interval in bits. Ideally for data
PVCs Bc = CIR/8 so that Tc = 125msec. If we are doing voice on the PVC, then
Bc = CIR/100 is preferable, so that the interval Tc = 10msec... The value of
Bc by default is the CIR in bits. (which would match the Spohn statement, by
the way)
...

Non-Configurable Parameters 

interval (Tc) 

The time interval during which you send the Bc bits in order to maintain the
average rate of the CIR in seconds.

Tc = Bc/CIR in seconds. (algebraically the same as Spohn's equation, by the
way)

The range for Tc is between 10 ms and 125 ms. The router internally
calculates this value based on the CIR and Bc values in the map class. If
Bc/CIR is more than or equal to 125 msec, it uses the internal Tc value. If
Bc/CIR is less than 125 ms, it uses the Tc calculated from that equation."

(I hope I haven't just confused matters even more! ;-)

Priscilla


> But if the Burst rate is already Bits per second and then we
> add another
> time interval, doesn't that make it bits/s/s. Isn't that bit
> acceleration?
> :-]
> 
> My mind won't allow me to continue.
> 
> After reading a bit more since I wrote the garbage above, I
> think I confused
> myself by calling it Burst rate rather than Burst size. Burst
> size makes it
> more sense.
> So do different providers have different time intervals to
> calculate mean
> rate from Burst size or is there a recognised standard. I take
> it that the
> longer the Tc the better (for the customer)?
> 
> Help - Frame is my bogey subject
> 
> Gaz
> 
> 
> 
> 
> 
> 
> ""Priscilla Oppenheimer""  wrote in
> message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > Davis, Scott [ISE/RAC] wrote:
> > >
> > > I guess maybe I need to make sure I understand the whole
> theory
> > > here. My
> > > understanding is that by setting Bc in conjunction with CIR,
> > > you are
> > > defining the delay by defining the timing interval with a
> > > maximum burst size
> >
> > Maybe indirectly this could have an effect on delay, but
> that's not what
> > you're setting. Don't think "delay" just because you see
> "time." The time
> > interval is used simply because otherwise a burst has no
> definite meaning.
> > Sending at rate x for 10 minutes is a lot different from
> sending at rate x
> > for 10 seconds.
> >
> > A lot of the descriptions are incomprehensible and get into
> token buckets
> > and other obscure minutiae. :-) Here's how I understand it at
> a higher
> > level. Someone please correct me if I have oversimplified to
> the point of
> > being wrong.
> >
> > The CIR specifies that as long as the data input to the Frame
> Relay
> network
> > is below or equal to the CIR, then the network provider will
> continue to
> > forward data for that virtual circuit. If the data input rate
> exceeds the
> > CIR, there is no longer any "commitment." The provider might
> discard
> traffic
> > beyond the CIR limit, although if there is sufficient
> bandwidth, it might
> > continue to forward traffic. CIR is measured over a time
> interval. Let's
> say
> > that CIR is measured over a time interval T.
> >
> > The committed burst size (Bc) specifies a maximum amount of
> data that the
> > provider will transmit over the time interval T even after
> the CIR has
> been
> > exceeded. The provider's Frame Relay switch is allowed to set
> the DE bit
> for
> > frames at the Bc level.
> >
> > Beyond the Bc, the provider can also support an excess burst
> size (Be)
> that
> > specifies the maximum amount in excess of Bc that the network
> will attempt
> > to transfer under normal circumstances during the time
> interval T. The
> > ingress switch at the provider immediately sets the DE bit on
> these frames
> > and also has the right to immediately discard the frames if
> the switch or
> > network is congested.
> >
> > Priscilla
> >
> > > and that by defining Be to anything other than 0 you are
> > > allowing specific
> > > instances where a burst larger than Bc will be allowed but
> > > marked DE ... or
> > > something like that but less jumbled that makes sense. I
> > > understand the
> > > mechanics of the commands, I just want to make sure I
> > > understand the theory.
> > > Thanks for the link Mark ... the explanation in that
> document
> > > is a bit
> > > clearer than the one in the FRTS docs.
> > >
> > > Thanks again
> > > Scott
> > >
> > >
> > > -----Original Message-----
> > > From: Turpin, Mark [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, August 09, 2002 10:10 AM
> > > To: 'Davis, Scott [ISE/RAC]'; [EMAIL PROTECTED]
> > > Subject: RE: FR traffic shaping [7:51044]
> > >
> > >
> > >
> > > Scott,
> > >
> > > I'm sure you know how to configure it, so I'll leave
> > > configuration examples out.  To get a conceptual overview
> > > of how shaping and policing actually works, check out this
> > > link: (wrap)
> > >
> > >
> >
>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos
> > > _c/fqcprt4/qcfpolsh.htm
> > >  s_c/fqcprt4/qcfpolsh.htm>
> > > as well as picking up the book IP Quality of Service
> > > (its actually a good read!)  The most important
> > > section that explains traffic shaping on frame is the
> > > section "Traffic Shaping and Rate of Transfer".
> > > Look for that, it explains it very well!
> > >
> > > Short answer, you can define Be/Bc values,
> > > but you're really better off leaving it to IOS
> > > to figure out.
> > >
> > > hth,
> > >
> > > -Mark
> > >
> > > -----Original Message-----
> > > From: Davis, Scott [ISE/RAC] [
> > > mailto:[EMAIL PROTECTED]
> > >  ]
> > > Sent: Friday, August 09, 2002 9:18 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: FR traffic shaping [7:51044]
> > >
> > >
> > > I am not clear on two of the settings when configuring a
> > > map-class.
> > > Frame-relay bc and be
> > > Are these values supplied by the carrier or a value that you
> > > can calculate
> > > yourself based on other parameters?
> > >
> > > TIA
> > > Scott
> > > &i=51044&t=51044
> > > --------------------------------------------------
> > > FAQ, list archives, and subscription info:
> > > http://www.groupstudy.com/list/cisco.html
> > >
> > > Report misconduct and Nondisclosure violations to
> > > [EMAIL PROTECTED]
> > >
> > >
> > >  "The information transmitted is intended only for the
> person
> > > or entity to
> > > which it is addressed and may contain confidential and/or
> > > privileged
> > > material. 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 and delete the
> > > material from all
> > > computers."
> 
> 




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=51120&t=51044
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to