« Google is playing to win in the 700 MHz auctions | Main | The end of Yahoo, and the end of Microsoft »

January 27, 2008


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:
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?


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 ;-)


Russ McGuire


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...

The comments to this entry are closed.

My Photo

Search this Blog

Subscribe by Email

March 2014

Sun Mon Tue Wed Thu Fri Sat
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          


Site Meter

Upcoming Travel & Conferences

Twitter Feed

Become a Fan