[2428] in Commercialization & Privatization of the Internet
Billing Systems
daemon@ATHENA.MIT.EDU (Jack Haverty)
Wed Feb 26 22:09:24 1992
Date: Wed, 26 Feb 92 19:02:37 PST
From: Jack Haverty <jhaverty@us.oracle.com>
To: craig@aland.bbn.com
Cc: jhaverty@us.oracle.com, drw@bourbaki.mit.edu, com-priv@psi.com
In-Reply-To: Craig Partridge's message of Wed, 26 Feb 92 18:33:25 -0800 <9202270233.AA13759@aland.bbn.com>
One other comment. I've gone over this with a lot of our own suppliers and it's
probably worth repeating here.
With small (e.g. sales/support offices) sites, and/or client/server
architectures, traffic patterns become *very* bursty - e.g., there may be a
baseline traffic flow in the 0-1 kbps range, but occasional demands for large
data transfer that could plausibly use a full T1 or more pipe for a few seconds
or minutes.
What we want to buy, and pay for accordingly, is a service which separates the
cost of the access circuit from the long-haul usage. The access circuit (maybe
a T1 for a few tens of miles) would be a fixed expense. The long-haul usage
would be based on the aggregate traffic flow over some longish time - e.g., a
work day, week, or month.
So, for example, I might have a small site with a T1 access, but which has real
traffic for only an hour a day. It might heavily use that T1 link for that
hour, but on average during the day/week/month send no more traffic than a
"constant" user does over a 56 kbps access link. I'm willing to pay for the
higher speed access circuit, but I want to pay only about the same for the
"backbone" as what the constant/56 user pays - I just use the bandwidth in short
bursts but over a work period I send about the same traffic.
Statistical multiplexing - the original reason why packet switching was useful!
Jack
