[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Another Point Of View (Round 2)
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
-------------------------------------------------------------------------------