[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: isdn@essential.org*Subject*: Another Point Of View (Round 2)*From*: mikebw@bilow.bilow.uu.ids.net (Mike Bilow)*Date*: Fri, 29 Nov 96 22:33:00 -0000*Reply-To*: mikebw@bilow.bilow.uu.ids.net

Bill Frezza wrote in a message to Mike Bilow: > I have considerably more mathematical education than "an > elementary course," and I have no idea what you are talking > about. What you seem to be describing here is the behavior of > the classic Poisson distribution, which is (as far as I know) > the accepted mathematical model for this sort of traffic > analysis. BF> Voice traffic follows a classic exponential, or Poission, BF> distribution. It is the basis for the Erlang tables used by BF> phone companies to provision trunk groups. Data calls *Do BF> Not* follow a Poisson distribution. See "Impacts of Internet BF> Traffic on LEC Networks and Switching Sysetms", Amir Atai BF> and James Gordon. (Note that nomenclature for Probability BF> Density Functions is not uniform. Perhaps you learned about BF> Power Law PDFs under a different name. Or maybe you were BF> absent that day :) Again, I really don't understand what you are talking about here. The discrete Poisson function is pretty straightforward, and it looks like this (using C programming notation): P(d,x) = pow(d,x) * exp(-d) / fact(x) where: pow(d,x) is d raised to the x power, exp(-d) is the base of the natural logarithm rasied to the -d power, fact(x) is x! = (x) * (x-1) * ... * 2 * 1 Now, x is an integer and represents the number of circuit slots in use, while d is some measure which we take to represent call density. For a given density d, P(d,x) represents the time probability that x circuit slots will be required. By solving for P(d,x) with x=1,2,3,... we can construct a picture of what sort of demand will be placed upon our communications system, based upon a particular assumption about the value of d. I have not read or even heard of the Atai and Gordon book, but this stuff just is not rocket science. The Poisson function is neither an "exponential" nor a "power" distribution, although it does involve both exponents and powers. As I think should be obvious to anyone who made it past high school math, the only real issue is whether the value of d is different for voice calls and data calls. It is by no means clear what the answer is to this question, and the only way to find out is to go and measure it. Even if the average data call lasts ten times longer than the average voice call, d would be the same for both if ten times as many voice calls were made as data calls. Properly, d should be correlated with the probability that any particular line is tied up with a call at any particular time. The purpose of the Poisson distribution is to account for the fact that calls are made at random times by independent actors, and the Poisson distribution will tell us how often we can expect peak demand to fill up x lines. Throwing around terms like "exponential distribution" and "power distribution" is not illuminating, at least not to me. What we really need to know is d. For example, let's say I have 100 bins and I throw 1000 balls into these bins at random, and I need to know how big to build my bins. The Poisson distribution tells me how probable it is that any particular bin will have a particular number of balls: 3 keys: 1 ( 0.23%) 4 keys: 2 ( 0.76%) 5 keys: 4 ( 1.89%) 6 keys: 6 ( 3.78%) 7 keys: 9 ( 6.31%) 8 keys: 11 ( 9.01%) 9 keys: 13 (11.26%) 10 keys: 13 (12.51%) 11 keys: 11 (12.51%) 12 keys: 9 (11.37%) 13 keys: 7 ( 9.48%) 14 keys: 5 ( 7.29%) 15 keys: 3 ( 5.21%) 16 keys: 2 ( 3.47%) 17 keys: 1 ( 2.17%) 18 keys: 1 ( 1.28%) In other words, it is expected that there will be 11 bins holding 8 balls, accounting for 9.01% of the balls. What is important from the standpoint of traffic analysis is that the probability becomes insignificant that any particular bin will end up holding more than 18 balls. If I chose to make my bins hold a maximum of 15 balls, then only (16-15)*2 + (17-15)*1 + (18-15)*1 = 2+2+3 = 7 balls would overflow onto the floor, out of 1000. What would happen if I threw my 1000 balls into half as many (50) bins? Then I would have to build the bins half again bigger, able to hold 29 balls: 11 keys: 1 ( 0.58%) 12 keys: 1 ( 1.06%) 13 keys: 1 ( 1.76%) 14 keys: 2 ( 2.71%) 15 keys: 3 ( 3.87%) 16 keys: 3 ( 5.16%) 17 keys: 4 ( 6.46%) 18 keys: 4 ( 7.60%) 19 keys: 4 ( 8.44%) 20 keys: 4 ( 8.88%) 21 keys: 4 ( 8.88%) 22 keys: 4 ( 8.46%) 23 keys: 3 ( 7.69%) 24 keys: 3 ( 6.69%) 25 keys: 2 ( 5.57%) 26 keys: 2 ( 4.46%) 27 keys: 1 ( 3.43%) 28 keys: 1 ( 2.54%) 29 keys: 1 ( 1.81%) What is counter-intuitive about the Poisson distribution is that you don't get very much gain from adding lots and lots of bins. What would happen if I threw my 1000 balls into 1000 bins? I would still need bins to hold 6 balls: 0 keys: 368 ( 0.00%) 1 keys: 368 (36.79%) 2 keys: 184 (36.79%) 3 keys: 61 (18.39%) 4 keys: 15 ( 6.13%) 5 keys: 3 ( 1.53%) 6 keys: 1 ( 0.31%) Even at 10000 bins, my bins would have to hold 3 balls to prevent any of the 1000 balls from overflowing onto the floor, but over 9000 bins would be empty: 0 keys: 9048 ( 0.00%) 1 keys: 905 (90.48%) 2 keys: 45 ( 9.05%) 3 keys: 2 ( 0.45%) If I built 999000 bins, I would still need bins to hold 2 balls: 0 keys: 998000 ( 0.00%) 1 keys: 999 (99.90%) 2 keys: 1 ( 0.10%) > BF> Ignoring the fundamentals of traffic engineering, CPT argues > BF> that a 20-minute local data call costs the phone company the > BF> same as a 20-minute teenage yak-fest, > >This isn't true? BF> Of course a 20-minute call is a 20-minute call regardless of BF> whether it's voice or data. But that's not the point. The BF> phone network is not engineered to handle 20-minute average BF> holding time calls. In addition, it's not the *average* call BF> that matters, it's the total call-minute load presented by BF> the entire distribution function. The phone network doesn't care about the hold time of calls, period. It cares about the probability that a line will be in use at a particular time. I do not understand why someone logging into the Internet for 20 minutes a day should bring the phone system to its knees when the average line is probably in use for 20 minutes a day with voice calls in any case. The call receivers present no substantially different patterns, either. Have you ever tried calling a technical support line for computer software? These things are often filled to capacity, with many people trying over and over again to get through. In your reasoning, it would be justified to charge companies who offer technical support lines a premium because their lines are always busy. Nevertheless, everyone understands the difference between technical support lines and an IEXC, so no one has proposed charging IEXC fees for companies who operate technical support lines. > BF> I tried explaining this to the dunderhead social engineers > BF> that populate CPT's ISDN mailing list some months ago, > >I object to that "social" allegation. BF> OK. Next time I'll call you anti-social :) Us geeks are easily offended. -- Mike ------------------------------------------------------------------------------- Bilow Computer Science | +1 401 944 3937 (voice) | Michael S. Bilow Forty Plantations | +1 401 944 7966 (fax) | President Cranston, RI 02920-5554 | +1 401 944 8498 (BBS) | mikebw@ids.net (Internet) PGP Public Key fingerprint = 4B 06 23 FB 3E 24 A5 24 14 B5 A2 14 96 73 B4 B2 -------------------------------------------------------------------------------

**Follow-Ups**:**Re: Another Point Of View (Round 2)***From:*Bill Frezza <frezza@interramp.com>

- Prev by Date:
**Re: Another Point Of View (Round 2)** - Next by Date:
**Re: Another point of view** - Prev by thread:
**Re: Another Point Of View (Round 2)** - Next by thread:
**Re: Another Point Of View (Round 2)** - Index(es):