Re: a question on what I buy when I get a broadband connection.

[David Farber <dave () farber net>]

Begin forwarded message:

From: Brett Glass <brett () lariat net>
Date: March 6, 2007 9:58:14 PM EST
To: dave () farber net, ip () v2 listbox com
Cc: mo () ccr org
Subject: Re: [IP] Re: a question on what I buy when I get a broadband  
connection.

At 12:26 AM 3/1/2007, Mike O'Dell wrote:

> for most purposes, i'd much rather have a 100 megabit bearer that
> requires me to be less than 6 megabits averaged over 5 minutes 95% of
> the time than a 6 megabit bearer that guarantees me 6 megabits all the
> time.  the former is likely much cheaper as well.

We are an ISP that currently specializes in "guaranteed" bandwidth.  
We like doing this because customers can verify that they are getting  
what they pay for (speed tests are meaningful) and we can do adequate  
planning.

We do offer links which can burst faster, but the trouble is that  
customers are never quite satisfied with EVER being throttled back or  
not giving them the absolute maximum speed we claim. (Whenever a  
provider claims a burst speed, some customers expect to be able to  
get it always and indefinitely.)

The bandwidth hogs want -- or hope -- to be subsidized by the  
subscribers who use relatively little bandwidth rather than paying  
more for their excessive usage. Some providers (e.g. our local cable  
company) actually allow this, but can't indefinitely or their  
bandwidth will be consumed by such things as BitTorrent and GNUtella.

We also find that in some situations a company wants consistent  
bandwidth, but its employees want to do things which require  
burstable bandwidth and/or hog the company's share of our bandwidth.  
(This is a delicate political issue that can easily get you fired as  
a provider, because many of the activities which hog the bandwidth  
are recreational and shouldn't be done at work.)

When a user hogs the bandwidth we provide to a business, that  
business often complains that things are slow. But when we  
demonstrate that we're giving it what we promised and internal users  
are hogging it, they aren't satisfied by this explanation --  
especially if the person hogging the bandwidth happens to be a  
manager or the IT person himself! Instead, they often go shopping for  
another provider, hoping that the other provider will give them more  
than they pay for.

Our inclination (which may be misguided) is that what you get should  
reflect what you pay, and that rather than allowing cross- 
subsidization we should instead cut prices for the light users.

In any event, I am trying to figure out how best to structure our  
services so that the largest possible percentage of our customers are  
satisfied, none feel shortchanged, and we are able to make a fair  
profit on the commodity (bandwidth) that we resell. To what extent  
should we trade "burstability" for consistency? How much  
inconsistency are users willing to accept? And what should we do  
about the true bandwidth hogs, which are all too common in a college  
town such as ours (though there are businesses whose employees do it  
too)?

There seem to be several common policy approaches when a user hogs  
bandwidth:

* Slap his hand  -- e.g. with an extra charge;

* Cut his bandwidth back after a certain amount of time (at which  
point you immediately get a call claiming that something must be  
wrong because their trading of pirated movies is slow);

* Throttle only the bandwidth hogs, intentionally causing them to  
switch to your competitors so that they overburden the competitors'  
networks; or

* Do nothing, claim that the bandwidth you get is the peak bandwidth  
of your equipment, let the pipes fill up, and hope that not too many  
users complain. (This is what the cable companies seem to be doing.)

I'd be interested in hearing from the members of the IP community as  
to what approach they would recommend -- both from their own selfish  
perspectives (if they imagine themselves to be my customers) and from  
our perspective as a provider. So far, we've gone for the dedicated  
bandwidth approach because we have a fixed performance benchmark to  
meet instead of a nebulous demand for "fast enough." Should we stick  
to our guns? Comments welcome.

--Brett Glass



-------------------------------------------
Archives: http://v2.listbox.com/member/archive/247/@now
Powered by Listbox: http://www.listbox.com