In some ways similar to WebNOB (Web North of Boston) that I used to attend when I lived in NH.

I’ll be out of town but otherwise, it’s the sort of thing I’d be strongly inclined to check out. Perhaps you should.

The coverage is due to the what I mentioned last night: my colleague Martin A. Brown produced an excellent writeup, using Renesys routing data, showing widespread power outages in the Ohio River Valley due to damage from hurricane Ike. So that’s news.

But the meta story here is one of the enduring power of the AP. Renesys has had lots of press over the years. I’ve been quoted for articles in the New York Times, Business Week, the Economist, the Washington Post and a long list of others. But I can tell you with certainty that *nothing* distributes a news story like getting cited in the AP.

In this age of democratized news authorship and distribution (learn more about all of that at Podcamp Pittsburgh next month), we like to delude ourselves with our cute little blogs and our social news sites into believing that we are somehow replacing the established infrastructure. We are nowhere near that. I’ve had stories slashdotted, reddited, dugg and AP‘d. The AP is the clear winner in reach and influence. It’s not even close. It will be interesting to see how and whether that changes.

View Larger Map

The linked blog contains detailed analysis of outages in this whole region of the country, with Ohio and Pennsylvania both hit hard, much harder than one might expect from a hurricane. Notable region outages include Ansoft Corporation (192.149.1.0/24), Continental Broadband Pennsylvania, Inc. (209.114.166.0/24), LogicaCMG Inc. (128.129.0.0/16, since 9/13/2008), and two USWeb networks. OK, let me be honest here: I grew up in the Caribbean and I didn’t know that yinz could have hurricane effects at all this far inland. It’s either refreshing or a little bit scary. I’m still trying to figure out which.

Repairs continue, but as of last night 60,000 people in the local area still didn’t have power. If you’re reading this, I assume you’re not one of them. Good luck out there, people.

Some of those criticisms are baseless.  Technical reporters have a really hard job. They write about complicated subjects for a really broad audience, so they have to try to both get it right and make it interesting (or at least comprehensible).  The sad fact is that most tech journalists fail on both accounts. This happens in part because tech journalists just don’t have the serious technology background that they probably need to write accurately and coherently about the things they write about.  And it also happens because in an effort to be more comprensible and relevant, many journalists gloss over or flat out change details that matter.

A funny, and frustrating, example of this occurred recently when Jason Perlow tried to explain why Limelight Networks was better than Akamai at serving Olympics content for NBC. Perlow stacks generalization upon inaccuracy and ends up mistating the facts and miseducating readers.  All of this can be clearly, and simply detangled.

Perlow is trying to explain why NBC chose Limelight Networks (Autonomous System Number 22822) over Akamai Technologies (ASN 12222 and 20940 among others) to serve streaming content of the Olympics.  Perlow writes:

“Akamai uses a centralized data hosting infrastructure with big Internet pipes that mirrors content that is hosted on a customer’s own servers. Usually with the aid of a special caching appliance installed at the customer’s ISP or edge network, the request to download that content is re-directed to Akamai’s own servers and fat Internet pipes. When you download big ISO CD and DVD images from MSDN, its going right to Akamai’s data centers over the public Internet. As fat as Akamai’s pipes are, I’ve seen MSDN’s downloads slow to a crawl during peak download periods, such as the days following Windows XP SP3 and Windows Vista SP1’s release. So like my colleagues here at ZDNet, I was expecting the worst.”

So far, Perlow is not even wrong, a phrase coined by Wolfgang Pauli, but which I heard first from Thomas Pogge, a stellar and compelling philosopher who tried valiantly to teach me some Kant long, long ago. That is to say, Perlow isn’t making enough sense yet to be clearly refutable, since it’s unclear what he could possibly mean.  The gulf between the truth and what he writes is so large that the brain of any reasonbly technical person struggles to reinterpret everything he writes in some way that might be closer to reality.

Akamai most certainly does not have a “centralized data hosting infrastructure”.  In fact, Akamai has one of the mostly widely distributed hosting infrastructures (probably the most widely distributed hosting infrastructure) on the planet. Akamai grew up during the go-go days of the late 1990s when space and power were cheap and bandwidth was expensive.  Akamai pitched Internet Service Providers (IPSs) on a value proposition of allowing Akamai to put servers in your space and in exchange serving cached/distributed content to your customers (thereby saving bandwidth).

When I was Chief Technology Officer at Oso Grande Technologies, we ultimately cut a deal with Akamai to host servers with us because we thought it would save us bandwidth.  It did.  Hundreds of other ISPs made the same decision for the same reason. According to Akamai, “Akamai has the most pervasive platform for content delivery and application acceleration – 34000 servers in 70 countries within nearly 950 networks.”  That’s not centralized, hoss.

Limelight, on the other hand, tends to pay for colocation and put their servers in a relatively smaller number of locations (although still a massive number of servers).  This difference in architecture is probably for at least two reasons.  The first is due to when they scaled out.  While Akamai was building out a Content Distribution/Delivery Network (CDN) in the late 1990s and early 2000s, Limelight was still just a Phoenix-based ISP who mostly just resold Global Crossing bandwidth.  Limelight didn’t find their true identity as a CDN until much later.  So they were faced with a very different economic and industry landscape.  By the time Limelight was building out latency was lower overall, speeds were higher, bandwidth was cheaper and power more expensive.

The second reason is that Limelight specializes in streaming large files:  videos and downloads.  These files are much less sensitive to latency than the small picture and html files that Akamai was originally architected for and may also benefit from centralization of storage (to improve cache-locality). That last is a slightly subtle point and if it isn’t obvious to you, ignore it.  Doesn’t matter.  Anyway…

Perlow goes on to write:

Where Limelight differs from Akamai and why the Internet didn’t “melt” is quite simple — they are completely “off the cloud”.  In other words, unlike Akamai and similar content caching providers, their system isn’t deployed over the public Internet.

There are many differences between Limelight and Akamai. Some of those differences are even relevant to performance and scale.  Not only is that difference not related to performance or scale, it isn’t even completely true. Let’s review what he might be talking about.

CDNs replicate content “closer” to users and serve that content up quickly—more quickly than the originator could have served it to that user.  CDNs serve that content on the Internet, of course, so obviously any CDN (including Limelight) is “deployed over the public Internet”.  It would be idiocy to suggest otherwise.

What Perlow might mean is that Limelight replicates to each cluster over their backbone whereas Akamai replicates over the Internet.  That much is true.  He got something almost right!  Akamai does not have a backbone and rather they rely on their colocation and ISP partners (and transit-providers’) bandwidth to replicate content to their server clusters.  Who cares?  In order for that to matter you would have to believe in a world where the first copy of the source content to the server cluster was routinely failing.  That doesn’t make any sense.

The source content is copied out to many, many server cluster who then serve that content hundreds of thousands of times to customers.  Those server clusters are heavy on the outbound-bandwidth and very, very light on inbound bandwidth, since the bits going out go to customers and the bits coming in go to the servers.  Since data circuits on the Internet (except for at your house) are symmetrical, there is always a surfeit of inbound bandwidth available.  Whether you copy the data across a backbone or across the Internet, it’s going to get there.  This difference between the two companies has nothing to do with whether end-user performance is slow or fast.

In the end, we’re left to wonder:  does Perlow understand anything about Internet routing and CDNs at all, or did he just confuse users by glossing over details that he actually does understand?  At this point, we don’t know…

[Disclaimer:  I know and have long relationships with people from both Akamai and Limelight in my day job at Renesys.  They're both good companies doing interesting work.  I don't have a particular opinion over which CDN is better since I use neither.  But both deserve more accurate coverage than this.]

“Tell ya what they ought to do. Buy some old shellacs and an old record cutter and press up promo copies and mail that out to us. We music critics love everything on vinyl, so you’d be doing yourself a big favor. (Yeah, I know the last part is ridiculous and stupid. I just don’t feel like deleting it all now.)”

On the contrary, Mike, I don’t think it’s ridiculous at all.  Pressing records would not be very expensive.  Most serious reviewers would be able to listen to them.  And vinyl, by virtue of being completely analog, is a nice form of copy protection.  It’s mostly a hassle to get a really good digital copy from a record with a typical home set up. 

On the one hand, I seriously doubt whether any label will take up this idea, but I don’t have a clear sense why it won’t work.

Until now.  Comcast and Cisco recently announced a succesful trial of 100 Gigabit/s router interfaces.  Comcast has been working on the 100GE stuff for a while, but it was my understanding that they were previously using Nortel gear, which handles transmission but not routing.  With this new announcement, it sounds like Comcast will be able to carry 100 Gb/s over a wavelength on fiber that was previously only able to carry 10 Gb/s.  That’s a huge difference and should ease some of the networks’ growth pains.

At NANOG, the networking conference whose program committee i chair, we have seen a medium-sized handful of presentations about 100 Gigabit standardization over the past year, many of them given by Greg Hankins of Force10 Networks.  The take-away messages from all of those talks has been:  standardization sucks, the IEEE is very bureaucratic and 100GE was taking much longer than it should.  Greg took a lot of heat for presenting this stuff, but that was mostly a case of blaming the messenger.

It has been nice, over the past six months or so, to hear about larger networks rolling out pre-standards 100 GE interfaces and putting some pressure on the standards organizations to finally finish up their work.

My early impression of Pittsburgh is that there’s an awful lot of biotech and medical startup activity going on, but not as much web stuff.  That’s fine, of course, but a mix is nice, too.  In some ways, this crop of companies looks like a lot of “me, too” with some “social network”, “facebook” and “social media” buzz lathered thickly over the top.  But when someone wants to spend money making web comics easier to make (as Chogger apparently does), you have to smile.

I’ve started perusing the resources available at InnovationWorks and starting to get a handle on startup culture and environment in Pittsburgh.  I was previously involved in some startup and venture-related activities in Albuquerque and I’ve been through a couple of rounds of funding at Renesys, so I have some context.  Pittsburgh looks like it’s in decent shape.

In particular, Alphalab looks like a reasonable deal.  Six months of use of space, some mentoring and $25k for 3% of common stock.  That’s an $833k valuation on what, in most cases, is just an idea.  Moreover, it is probably just the kick in the pants that many of these entrepreneurs need to get started.  I look forward to watching these six companies over the course of the next year or so and learning more about the funding/support system for startups in Pittsburgh.

The new offering is likely to ruffle feathers on at least three fronts and will shake up the analytics industry over the next several months.  It should be interesting to see it play out.  In the process of trying to shore up a key part of their own business, Google is likely to make a few new enemies and may even endanger a current stream of data.

The offering is supposed to detail which populations of users are visiting what sites.  If it is integrated into the adwords system, then ad buyers would be able to see more about the audience of the sites in the content network in order to determine which of them are worth advertising on.

Adwords users already know that the content network is the weakest, most underdeveloped part of Google’s ad-selling empire.  What we’ve seen, in placing small ads for Babbledog over at Renesys, is that the click through rate (CTR) of the same ad on various parts of Google’s content network gets 1% or less the CTR of the exact same ad placed on search.  The low CTR on the content network is a known problem whose official answer is “those content pages are just so darned interesting that people don’t always see the ads!  honest!” The more likely explanation is that there is a behavioral difference involved.  People who are searching are in the act of reaching out and trying to answer a question or acquire information.  In that mindset they are much more receptive to well-targeted paid answers to their questions than they are when reading icanhascheezburger.com.

This is trouble for Google.  Search is already monetized and its growth will be relatively small.  On the other hand, the content network could, conceivably, be as large as the Internet as a whole.  That’s probably bigger.    But in order to make more money off of the Internet as a whole, Google has to do two things: 1) get more ads on all those pages; 2) get more viewers of those pages to click on those ads so that Google gets paid and advertisers are happier.  This new website analytics product is designed to do just that.

The WSJ says that advertisers might be worried about giving too much of their money to Google.  Since Google already has a dominant market share for online advertising, they might worry that they should not use Google for website metrics, too.  It’s a matter of trust.  Still, free is hard to argue with.  Comscore and Nielson Netratings should be worried.

There’s an interesting backstory here that is barely covered in the WSJ article.  Where is Google getting the data for this product?  ” Google’s new offering will be based mostly on data from Web servers, allowing for a deeper and broader view of Internet use.”  Hrm.  “Data from Web servers”.  What webservers?  Yours.

It’s obvious that Google is finally cashing in on their free Analytics product by aggregating all of your web hits and putting them to work for advertisers.  This should be of no surprise to anyone, since Google’s entire enterprise is about aggregating all of the data out there and putting them to work for advertisers.  However, the nakedness, the blatantness of this particular scheme may surprise some people and may make it more difficult to justify that “free” Google Analytics account.

All of this should have people thinking about the subject of website analytics and why this is big business in the first place.  Jay Adelson, of Digg and Revision3 fame, wrote an excellent piece about the sorry state of the web analytics industry last year.  He wondered why large sites couldn’t just publish audited web stats from their own logs rather than relying on silly panel-based metrics such as Comscore and Nielson offer or extrapolated data such as Google is likely to offer.

I have to say, he has a point.