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). 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=51118&t=51044 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
