How tiered Internet pricing could actually facilitate P2P

Time Warner Cable's planned experiment with tiered charging for Internet access has generated a flurry of coverage in the blogsphere, but no new insights (at least that I've seen).

The primary problem ISP's complain about is that 5% of their customers use 90% of the available bandwidth and when they examine this traffic, it's mostly peer-to-peer file sharing.  A reasonable question is how to allow as much of this traffic as possible without increasing an ISP's variable costs or slowing down their other users.

This may not be as difficult as it appears.   Indeed if Internet access was as competitive as mobile telephony, we might already have seen what I'm about to propose — a combination of bundled pricing equivalent to mobile's "free nights and weekends" and "free on-net calls" with a way to facilitate P2P traffic that leverages exactly these "free" periods.

An ISP's costs

ISPs have some costs which are relatively fixed and others that are tied to usage.  A network is a relatively fixed cost and when it's not full, the incremental cost of adding traffic is zero!  This is the reason mobile operators give away free nights and weekend.  They've built their mobile network for the peak daytime traffic, so it costs them nothing to run promotions that add incremental traffic at off hours.  Peak hours and off hours may be different for an ISP, but the concept is the same. When a data pipe is lightly loaded the ISP's cost of adding incremental traffic is zero.

On the other hand, some ISP costs are usage based, for example "IP Transit" or more properly, Internet Transit.  This is the ISP's upstream cost to send and receive traffic to/from the rest of the Internet.  However, even here, usage-based costs occur at heavy usage.  Light usage periods don't save money.  To understand what's happening, it's worth a digression on Internet Transit.

Internet Transit

Internet access is monopoly or duopoly or a heavily regulated industry.  The middle mile connections from the local network to the Internet backbone may or may not be competitive depending on where you are.  But the Internet backbone itself is extremely competitive.  If you can get to a major Internet Exchange Point in the US or Europe, there are many providers offering extremely competitive rates for Internet Transit.  Typically these services are priced on a megabit per second per month basis (Mbit/s/Month) with lower rates for higher volume commitments.  The other key idea is that charges are based on the 95th percentile of all the five minute data rate samples taken during the month.  So an ISP can have a few bursts above their typical rate, as long as they represent less than 5% of the sampled intervals.

But this also means there is no extra cost to run at or near the typical rate at all times.

Local traffic

Even more important, if file sharing is done with other computers on the same ISP's network, then there is no need to pay for Internet Transit at all.  The question is how to figure out which potential peers are "on-net" and which are "off-net."

Sending signals to P2P software

Most P2P file sharing software has relatively little knowledge of locality.  Some P2P software practices "prefix awareness," for example, Joost gives preference to peers in the same /24 IP address block when they are available.  But if a major operator provided an automatic way for P2P client software to determine whether a prospective peer's IP address was currently reachable "for free", it seems likely the file sharing community would leap on it, and if there's money to be saved, active file sharers would download the new clients immediately.

A standard way to present such information might be via an extension to the XML-based response codes in one of the whois information exchange proposals, e.g. from ICANN or from APNIC.  Also, while what I'm proposing might start as a pricing plan rather like a mobile operator's "free nights and weekends" and "free on-net calling," it's not hard to see extensions where an ISP could offer dynamic access to underused capacity to those programs that were prepared regularly interrogate an ISP's server and use just the advertised off-hours capacity.

In closing

People liked fixed price deals.  Unlimited is great, but there's plenty of experience with bundles of minutes and the idea of data bundles has already showed up in 3G mobile data plans.  The combination of several tiered data bundle prices with the availability of "free" connectivity for "on-net" peers and during off peak intervals is likely to appeal to file sharers and produce better results for both the sponsoring ISPs and file sharers alike.

Comments

[Russ McGuire]

Good thoughts Brough. One other complexity to this puzzle, which also points to a potential solution to these challenges...

Unlike traditional telephone traffic (fixed or mobile), IP traffic is very bursty, especially near the edges before aggregation can smooth it out. An IP application need (sending an e-mail, downloading a web page) can last a few seconds, unlike telephone calls which are rarely less than a minute and often much longer than that.

In the telephone network, the "busy hour" is very meaningful. In an IP network, there are busy hour patterns, but my perception of network quality may be based on the "busy minute" in an otherwise not very busy hour (my VoIP call keeps breaking up because someone's downloading a huge video file). This forces ISPs to build enough capacity for my experience to be acceptable even in the "busy minute." Of course, IP networks have mechanisms to differentiate between different traffic so that my VoIP call takes precedent and the video file download can wait a second for available capacity. Unfortunately, applications and networks have typically not taken advantage of these capabilities.

While you're reconfiguring networks and applications to be aware of localness, maybe you can also reconfigure them to take advantage of prioritization schemes to further ease the burden on IP network engineers and ISP's capital costs...

Here's a promotional paper I helped write several years ago (when I worked for a different company than I do today) to try to put some math to this opportunity/challenge: http://www.telechoice.com/whitepapers/TC_Perspective_Super-Broadband_Deployment.pdf (I'm sure the assumptions are all horribly out of date, but I still think the logic fits...)

(As always, these views do not necessarily reflect those of my employer, especially since my employer has many folks much smarter in IP network engineering than I...)

[Brough Turner]

Russ, thank you! That's a very interesting paper at TeleChoice. When was it written? The $1T investment sounds high today, but I remember it seemed plausible a few years ago.

You are correct that IP traffic is very bursty in the first mile and perhaps in the middle mile depending on how many different traffic flows are being multiplexed. The issue is how much statistical multiplexing is going on. In every backbone link for which I've seen data, traffic flows are not bursty and do show reasonably strong time-of-day variations. For a really multiplexed example see:
http://www.ams-ix.net/technical/stats/
I'd love to see a formula for estimating how many traffic flows (and of what characteristics) have to be combined to render IP burstiness small enough to ignore. It may not be that much. The majority of traffic on most links these days is P2P file sharing of one sort or another and these P2P flows use TCP. The TCP protocol does a good job of removing burstiness from a flow, instead causing it to look like a sawtooth wave with its peak set by traffic flows on the most congested link.

However, there is no doubt that the first mile is the congestion point for most people and solutions that make sense when you own your own network (like add capacity) don't work in the political and regulatory mire that is the first mile. Some years ago I was involved in trying to sell first mile priority solutions to operators so they could offer IP service guarantees to their business customers. What I learned there was, even for a sophisticated IT department, services have to be very simple. I doubt MPLS is the ticket or that there is anyway to justify more than two classes, i.e. gold bits and brown bits.

This is worth some further discussion... Are we likely to run into each other at some upcoming show? eComm 2008, Spring VON, F2C?

[Benoit FELTEN]

Hey Brough, you beat me to the punch!

After our dinner together on Thursday, I intended to write about this and then one thing let to another and I wrote about other things. Oh well, I'll try and take it from a different angle.

It was a very nice dinner though ;-)

Benoit

[Russ McGuire]

Brough,

The paper must've been written around 2001. If it's hard for enterprises to deal with the complexity of different classes of services, how will we ever implement solutions in the consumer space? I've always assumed that the tagging of different classes would have to be done by the apps themselves or possibly the CPE. That's one reason I was excited by your post which opened the door for fixing things in the applications themselves. I'm sure we're just dreaming, but...

I'm hoping to make an appearance at eComm, but we're pretty busy these days, so waiting to see if I can justify the time...