Without getting into a religious debate, I need some consensus for a problem that I am having regarding the definition of a burstable circuit.
In my view of the world, a burstable circuit is defined as one where the customer can send us as much data as they would like (for example, an entire DS3's worth on a consistent basis), and we would bill them for usage above the contracted amount via some method (we use 90th percentile reporting)
In someone else's view inside the company, the customer should be prohibited from sending above the contracted rate for any extended period of time by policing at the ATM layer. Both views are viable, but I believe (nearly religously) that the former view is correct.
Any input would be appreciated.
PS. These views are my own and do not represent those of the company, even though I'm sending from my work email 
To me, what you view as "burstable" means "metered".
IMHO, "burstable" means you are gauranteed X bandwidth, and you can burst
up to Y, but only if network conditions allow.
Andy
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Andy Dills 301-682-9972
Xecunet, LLC www.xecu.net
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dialup * Webhosting * E-Commerce * High-Speed Access
i think your definition is correct, ie customer can burst to some max.
billing based one some base, with free bursting, or billing for the 90th
percentile are common options.
i think what the other view is what i would call an "expandable" link,
in that the customer buys blocks of raw throughput, without any throttling
taking place (other than to limit them to their contracted amount.
this would be useful for a customer that doesn't want the excess billing
that a burstable connection could cause, or the potential of the bandwidth
not being there (if more than one customer shares the bursting bandwidth).
a customer could call up and say "hey, bump me up 5 megs" or "drop me down
5 megs" and the implementation could be done swiftly, as no physical changes
are required.
The holder of the latter view is confused. (does that count as religious?)
Seriously, what all the providers I have experience with have done is let
you burst to whatever the link capacity is and charge a premium on the
overage above the normal committed per Mb rate, or bump you to the next
committment level once you have sustained an overage for a period of time.
While it can make traffic engineering a little more difficult, both of these
represents a revenue opportunity.
If you take the first approach and charge a premium it has the advantage of
generally being self-corrective when you explain to the customer they are
paying more by not making a larger bandwidth committment. Taking the second
approach is easier for you, generates additional revenue, but could be more of
a billing/customer service hassle.
My view matches yours but certainly I know that this would
not be shared amoung my own work mates. Its the Telco World
Vs IP Junkies story all over again.
Maybe you should play with there heads and ask them how they
manage ABR ;-).
Regards,
Kevin
Without getting into a religious debate, I need some consensus for a
problem that I am having regarding the definition of a burstable circuit.
In my view of the world, a burstable circuit is defined as one where the
customer can send us as much data as they would like (for example, an
entire DS3's worth on a consistent basis), and we would bill them for
usage above the contracted amount via some method (we use 90th
percentile reporting)
In someone else's view inside the company, the customer should be
prohibited from sending above the contracted rate for any extended
period of time by policing at the ATM layer. Both views are viable, but
I believe (nearly religously) that the former view is correct.
The holder of the latter view has the benefit of history on
his side. Remember Frame Relay and terms like Bc (committed
burst)?
What you are talking about is a varient of volume based billing
or metered service. The fact that you can 'burst' (for up
to 5% of samples without being billed extra (actually
just 'use' as you could do it all in one lump in one
day of the month, which is hardly a burst), led some
marketroids to call this a bursting service a long while
ago, has (sadly) caught on, to the point where now there
are two definitions in equal use, and a lot of confusion.
The confusion is then added to by sales people who
just say 'yes' to the question 'does the bursting
work like [x]', for all values of x. Then the unhappy
customer is annoyed when they either receive a bill
for more than they expected, or find that after 3
seconds, their initially extremely zippy ftp session
slows down to their committed rate. Cue support call
from right. Exit sales person, pursued by a bear market.
I forgot one thing:
A small part of the reason why people invented 95th % billing etc
(which was quite difficult in the days when measuring things reliably
was hard), was that implementing proper bursting and shaping in
an IP compatible way was harder. It still is. Just look at the
brain damage the 'burst' facility that 'forward or drop' technologies
like Cisco's CEF/CAR do to a TCP/IP session, and you'll see why.
[shall we shape the traffic by queuing the packets we'd have
otherwise binned, and take them off the queue at a reasonable
rate? noo noo process switching noo bus bandwidth horrors etc.]