Interesting People mailing list archives

a pricing model??


From: David Farber <dave () farber net>
Date: Sun, 15 Jun 2008 13:36:59 -0700


________________________________________
From: Gerry Faulhaber [gerry-faulhaber () mchsi com]
Sent: Sunday, June 15, 2008 4:03 PM
To: David Farber
Cc: brett () lariat net
Subject: Re: [IP] ALSO MUST READ  NYTimes.com: Charging by the Byte to Curb Internet Traffic "People seem to be missing 
the point."

[for IP, if you wish]

Whew!  Somebody finally got it right!  When all the costs are capacity costs
(as in the Internet), then the economically most efficient pricing (in
theory) is what Bohn calls "spot" pricing, or what economists call "Vickrey"
pricing (after Nobel laureate Willliam Vickrey, Columbia Univ.), sometimes
called "congestion" pricing (see Wikipedia): the price for use of a facility
is zero (assuming running costs are zero) if demand is less than capacity,
but increase during times of peak use when demand is great enough to use all
the capacity available.  All customers who use the facility during periods
of congestion pay this congestion price (BitTorrent users and people that
want to browse the Web alike), and zero otherwise.  The congestion price
should be sufficient to reduce demand so that demand just equals capacity
during this period, so that all customers willing to pay for the congestion
they cause are able to use the facility.  Customers not willing to pay can
postpone their use of the facility.  If congestion pricing leads to revenues
greater than the cost of capacity, then the owner of the facility has an
incentive to invest in more capacity, and will do so up to the point where
marginal revenues are just equal to the marginal cost of capacity.  In
theory, the congestion price is only imposed when capacity is congested.

While this is theoretically correct, it has proven to be difficult (if not
impossible) to implement in practice.  Since we are never sure exactly when
congestion will occur, there must be some way to inform customers what the
price is at this moment, and they must be able to respond to this
information in real time.  And what happens when someone opens a BitTorrent
download when demand is slack (zero price) but the price increases twenty
minutes into a two-hour download, maybe to $1/Mb?

Approximations have proven useful, such as peak load pricing.  In this
model, the owner sets prices by time of day, under the assumption that peak
demand always occurs at the same time (this concept goes back to Steiner in
the 1950s), which is likely false.  Further, in order for time of day
pricing to correctly ration customers' usage, they must all be aware of when
the prices change and by how much they change.  Price-elastic customers were
pretty good at this in the old telephone world (where time of day pricing
was standard), but not everyone.

Cell phone firms have opted for a "bucket of minutes" approach, which is a
form of usage-based pricing that customers seem to accept.  It only controls
peak demand if one makes the heroic assumption that across all customers,
total usage and peak usage are highly correlated.  Certainly not true in
general, but I suspect that as an approximation it's not too bad.  I also
suspect that this will be the direction that ISPs will take: do something
that customers have shown a willingness to accept (buckets of minutes), even
if it is only a fair approximation to the theoretically correct pricing.

If I were a broadband ISP (Brett Glass, you can chime in here), this is what
I would do.  I would transition by giving customers who use less than (say)
4 Gb a month a price reduction (for the lowest bucket), which could well
cover 80% of customers, and the rest would get a healthy price increase.
Theoretically perfect?  Far from it.  But a reasonable first move away from
the unsustainable All You Can Eat pricing we have now.

Prof. Gerald Faulhaber (Emeritus)
Wharton School and Law School
University of Pennsylvania

----- Original Message -----
From: "David Farber" <dave () farber net>
To: "ip" <ip () v2 listbox com>
Sent: Sunday, June 15, 2008 1:08 PM
Subject: [IP] ALSO MUST READ NYTimes.com: Charging by the Byte to Curb
Internet Traffic "People seem to be missing the point."



________________________________________
From: Roger Bohn [Rbohn () ucsd edu]
Sent: Sunday, June 15, 2008 11:13 AM
To: David Farber
Cc: Bob.Frankston () indigo pobox com;
"[bob37-2 () bobf frankston com]"@indigo.pobox.com;
Michael.O'Dell () indigo pobox com; "[mo () ccr org]"@indigo.pobox.com
Subject: Re: [IP] MUST READ  NYTimes.com: Charging by the Byte to Curb
Internet Traffic "People seem to be missing the point."

Regarding the reaction to the NY Times article and the whole subject of
charging by the byte, let me point out that the correct way to charge for
scarcity of bandwidth is ALSO something that many readers of this list will
distrust.

From: Michael O'Dell [mo () ccr org]

Since bit *rate*, not bit mass, is the instantaneously-exhaustable
resource in packet network, if they were actually worried about
network engineering, they'd be going to the burstable charging
model which is known to worth both technically and economically.
it relates the charges directly to the exhaustion of the
finite resource - bit *rate*, not bit mass.

Mr. O'Dell is correct about rate, but the scarce resource here is
_congestion_ flows, which are highly variable. The correct (economically,
and in my modestly informed opinion technically) way to charge for these is
with some form of spot pricing, i.e. prices that change in real time and
with location. When there's no congestion, no matter how much bandwidth
someone currently uses the charge should be zero. Conversely, when your
neighbors are running real-time movies via IP, both you and they should be
charged congestion fees for whatever each of you is  doing.  Even if you did
not "cause" the congestion, your usage is   exacerbating it for everyone.

The easiest analogy is to cellular phones, which have gone as far as a
two-level time-of-day price (free/ not free), but otherwise stayed away from
a "burstable charging model."  Electricity sellers are starting to play with
spot prices. But in general they are viewed as out of the question for
consumers because of the  uncertainty and variability they introduce. Your
monthly payment becomes even harder to predict than with a pure charge for
bytes.*

So like Network Neutrality, this is a case of "be careful what you ask
for...." How many of IP's readers would like to give some kind of real-time
pricing power to their ISP?  Imagine the problems of auditing your bill to
ensure that it was correct, for example. Solvable technically, but when
there is a rapacious quasi-monopolist writing the bills it would require a
lot of trust.

So a time-of-day based surcharge for bytes seems like a reasonable
compromise between tractability and theoretical optimality. This is not what
Comcast is proposing, though, which lends credence to the theories that they
have a very different agenda than what they claim.

Long-term solution: We need a third source of high-bandwidth to the home  -
probably nothing less will get the ISPs to behave. This would also, most
likely, solve the net neutrality problem without a lot of dangerous
micro-regulation of what behavior is acceptable.

Roger

*(Doing spot pricing  economically correctly for the Internet would be
harder than for cellular, because of  end-to-end issues, which can lead to a
lot of nonsense about capacity  reservations, "fair queuing," and the rest.
Hans-Werner Braun, KC Claffy, and I wrote a paper about end-to-end spot
pricing in the mid 90s. If they are only worried about local congestion,
though, as the Comcasts of the world imply in their PR, then backbone and
other-end congestion can be ignored.)




-------------------------------------------
Archives: http://www.listbox.com/member/archive/247/=now
RSS Feed: http://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com




-------------------------------------------
Archives: http://www.listbox.com/member/archive/247/=now
RSS Feed: http://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com


Current thread: