The Rockethouse

The case against net neutrality

I’m not sure net neutrality is a good thing. Here’s why:

1. Networks have to throttle traffic when there is congestion
2. If networks can’t selectively prioritize traffic during congestion, they must resort to random dropping of packets
   
3. Throttling randomly leads to unfair application quality of experience impacts
   
4. We want convergence of our phone, our mobile, our tv, our computer, etc… And carriers want to give it us (and they will give it to us).
   
5. If networks aren’t able to deliver these applications (tv, phone, mobile, etc…) with expected quality of experience on a shared IP network, they will deliver them on multiple, un-shared, networks. Re-birth of the walled garden. Content locked in protected, private networks and inaccessible except from certain devices.
6. If networks CAN selectively prioritize traffic during contestion, then converged applications CAN be delivered with high quality of experience, even during periods of conestion. Convergence will happen at the IP layer. Content and data is available to all applications and devices on any IP network.

I will expand on each of these points in subsequent posts, but that’s the gist of it.

The reason software is so bad is that it’s so easy to make

New Relic announced that it raised some money today. It looks like a pretty cool product. Assuming it works as advertised, you drop their plugin into your rails app, then visit their web app to browse and analyze its performance. 

Isn’t this a problem that every programmer in every language runs into? Tools like gprof and DTrace perform similar functions, but in a MUCH more general set of applications.

Despite not really being “new technology”, New Relic stands apart in that it seems to generate useful data without requiring the developer to really know what they should be looking for (e.g. you don’t have to tell it what you want monitored, it just figures that out for you). Makes you wonder whether you can ever expect an application to scale when it’s built by someone that doesn’t know how it will scale. 

A friend of mine always used to say “The reason software is so bad is that it’s so easy to make!” And over time it seems that software really does only get easier to make. But this doesn’t tell the whole picture. 

This whole “software gets easier to make” progression relies upon a small cadre of software engineers who actually make software easier to make. While you have the mass of programmers growing and applying decreasing levels of sophistication to their application authoring techniques (e.g. assembly language -> C -> J2EE -> Ruby on Rails), you have the small cadre of architects applying increasing levels of knowledge about what has worked at what hasn’t (e.g. procedures -> libraries -> classes -> patterns -> frameworks — or some such progression WLOG). 

So I can accept the “dumbing down” of software, because it is directly enabled by the “smartening up” of the underlying technologies on top of which most software is built.

That being said… Hey DTrace team. You can’t just be sitting on your haunches? Where’s your DTrace web service that let’s you “one-click” monitor any application?  

Fail! makes bid to acquire Fail!

Blockbuster made a bid to acquire Circuit City today. I can’t really imagine this being successful. Here’s my reasoning in sexy bullet list format: 

• Seems like old-school business model (brick and mortar movie rental) trying to bail itself out by combining with another old-school business (brick and mortar electronics).
• If blockbuster is really going to introduce a box in the home that streams movies right to your TV, they’re going to experience some channel conflict with their suppliers acquired through circuit city.
• One of Blockbuster’s biggest problems is that they have long leases on a ton of real estate which they can’t get out of. This is much of their $2B in debt. This deal will leave them with MORE real estate they can’t get out of. 
• Blockbuster has a market cap of $617M this morning (down 12% as I’m writing this) and yet they are offering up to $1.8B. This would be financed through issuance of additional stock. Now THERE’s some dilution.

My take: Blockbuster knows they can’t beat Netflix. Rather than try to compete, they are trying to hop into an adjacent market. BBI CEO Jim Keyes was formerly CEO of 7-11. Head down to your local 7-11 to preview BBI’s future.

The distributed computing myth

GigaOm posted this article about Google’s App Engine and I couldn’t help but comment. Much of what Mr. McConnell has to say is right on. Yes, we want utility like computing that can scale up and down as needed. Yes, we want to be able to use our development language or platform of choice. Yes we want it to be standards based.

But where I take issue is with the notion that cloud computing should look like a single linux CPU. Or that it should provide what looks like a single MySQL database.

This will not scale. If you want scalable computing architecture, you need to look beyond the CPU. If you build your application assuming that all CPU’s have access to a single global memory, you will build your software in a way that is inconsistent with running on a distributed system.

For example, don’t assume that every CPU has access to all session state. As you scale up to hundreds or thousands or millions of CPU’s, you’re going to spend all of your time making sure that your CPU’s have the same and consistent version of memory. Computation will grind to a halt as your virtual servers continuously update everybody else. You’re preserving an abstraction that does not efficiently scale with growth of infrastructure. 

Same goes for the database. If you assume that everything sits in a single database image, you enable and in fact encourage the programmer to make bad decisions.

The key to achieving scale is to set up your programmers with an environment in which they can’t make bad decisions (or rather, make it such that the easiest decision for them to make is inherently scalable).

BigTable is a perfect example. Google realized that it just isn’t feasible to build a single database cluster that contains the entire web. So they sacrificed some of the features of SQL that limit it to a single database instance in favor of a subset (GQL) that can be supported across a massively distributed set of servers. Engineers design their tables using BigTable and they query it using the tools Google has provided. As long as they do that, they can scale their database from kilobytes to petabytes without sacrificing performance.

Virtualization is not about “making the Internet look like a single linux CPU”. It’s about changing the programming environment in ways that prevent bad decisions and encourage good ones.

The classic problem with distributed systems has been trying to hide the fact that you’re running on a distributed system. It’s better to embrace this fact and build our tools in a way that supports the right abstraction.

I DO NOT want a single linux CPU or a single MySQL database. I want a set of API’s that ensures that whatever code I write will scale from one CPU to 1,000,000 CPU’s without modification. BigTable’s a giant leap in this direction. Distributed Hash Tables are another. We need more technologies like these to make this happen.

Is new media really going to be better than old media?

Lots of buzz about SellaBand raising $5M today. It’s a really interesting model. They have 18 groups that have been funded to the $50,000 level. That’s $900,000 raised $10 at a time from people over the web. Pretty impressive!

But have you read through the terms and conditions?

My favorite part:

“5.5 All rights in the titles on the CD, including intellectual and commercial property rights as well as master and copying rights and comparable rights are SellaBand’s rights exclusively.”

The band gets $50,000 to record an album (do they get what’s left over after recording expenses?) and gives away 5000 CD’s to do it. Then they get 60% of the net profit (after deducting expenses charged by sellaband) of sales after that.

Is this really that much better than the old media gig?

Peer to Peer Throttling Continues, But the Real Threat Lies Unmentioned

Bell Canada has been caught throttling peer-to-peer traffic. The reality is that this stuff has been deployed in most networks around the world in either test or production capacity. The debate is all about throttling which may miss the point. Throttling is a necessary component of a working network. Your PC throttles its bandwidth usage by virtue of using TCP. The routers and switches along the network, when they have more packets than they can process, drop packets all the time. It’s not physically possible to build a network that doesn’t throttle traffic in some way unless you can control all of the endpoints and control the rate at which they send data. Throttling is just a necessary and fundamental part of the network and it always has been.

What’s more scary is the inspection piece. What’s so scary about throttling peer-to-peer traffic is that the networks _know_ that it’s peer-to-peer traffic. Most p2p protocols masquerade as other protocols by using ports commonly used by other applications (HTTP or SMTP). In order to recognize p2p traffic, the network actually needs to look past the IP header into the body of the packet. This allows the network to distinguish between web browser traffic and p2p traffic, both using port 80.

Today they’re just using this inspection technology to determine which protocol you’re using. But it’s not a huge leap to extract specific and meaningful data out of those packets. Companies like adzilla and NebuAd are already using the same technology to deliver targeted advertising to users. It won’t be long before the ISP’s can remember all of the websites you visit, all of the posts to your blog, all of the songs you’ve downloaded. And what’s really scary is that there aren’t really many ways you can get around it.

ISP’s can learn this information merely because you connect to the inetnet through them. Encrypted traffic is obviously out of bounds, but today it is impracticle to encrypt every single packet from every single application you use. The opportunities for abuse are far spread…