Gaz wrote: > > I think I understand it better (that's usually the point where > someone pulls > the rug from under my feet :-)) > > The two seem to contradict each other though. One saying that > the Tc can be > set by the provider, and Cisco saying it's automatically > calculated.
Yes, Spohn does say that Tc is set by the provider, but perhpas that's because his book is somewhat old. Or perhaps what he meant to say was that Tc is derived becuase the provider and customer agree on a Bc value, which also changes Tc, as Tc= Bc/CIR. Sphon also says that the default value of Tc is 1, implying that Bc isn't set and is assumed to be the same as the bits value in the CIR bits/sec. Now Cisco says that the default value for Tc is 1 also, depending on which documents you read! ;-) But Cisco also lets you set the Bc which affects the Tc. You can do that when you configure traffic shaping. I don't think anyone actually explicitly sets the Tc these days. I think it's derived. Hey, but I'm way out on a limb here. Maybe someone else will join the discussion and reel me back in. ;-) Thanks. Priscilla > > They both seem to make sense. The Cisco way means that the > higher the value > of Bc compared to CIR, the greater flexibility you have, > because as well as > increasing the value of Bc, it increases the period over which > the average > is taken. > Spohn's method suggests that both variables are configurable > allowing > ultimate flexibility (to the provider). > > Or am I still messed up? :-) > > Gaz > > ""Priscilla Oppenheimer"" wrote in > message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > 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=51174&t=51044 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
