It has been a while since we blogged about Uber Bandwidth and the improvements we’ve been making to our bandwidth product. Our goal has always been to deliver the best performance and superior routes to our customers, so… before we let a year slip by without a proper blog post, here is a year-end 2010 update with what we’ve been working on over the last 12 months.

The vast majority of the year was spent building a private network around the United States and to Europe. In early 2010, based on customer feedback, we quickly came to the conclusion, that even though we had direct connections to the best providers, almost all of them were less-than-perfect when it came to efficient packet delivery over long distances – even on their own networks! This was something we simply did not expect.

One of the founding principles at Uber Bandwidth is to connect to every provider possible, ensuring that traffic destined to a specific network, is placed onto that network as quickly as possible. This assumes, of course, that each provider will take the best care of traffic to and from end-users on their own network. We quickly learned that while the strategy of connecting to every network still remains essential to achieving our ultimate goal, it is necessary to take it one step further. Instead of placing traffic onto the destination network as close to the origin as possible, we need to keep it on our own network as long as possible in order to manage packet loss, latency and performance. Only once we have done the majority of the heavy lifting should we hand it off to the ultimate destination network.

So with this newly improved strategy in place, we began to rapidly build out our network by leasing capacity between key cities around the United States and the two most popular points in Europe… London and Amsterdam. Each location we have chosen is a major hub and boasts fantastic connectivity to an impressive provider list, plus hundreds of private peers. The map you see to the right (and on our website) demonstrates the aggressive roll-out we’ve been working on all year long.

Of course, a network like this doesn’t come cheap. But our goal has never been “cheap;” it will always be to create the best network product for a wholesale price. Not only do we lease network capacity between nodes, but we rent rack space, purchase and install routers and arrange for connectivity to all transit providers at all locations as well. All of this equates to a significantly improved bandwidth product, and when fully complete in late spring 2011, our customers will certainly notice.

So what does this mean for customers? Well, let’s give an example of how traffic may traverse from point A to point B in our original design vs. our new design. Let’s use the example of content originating in Atlanta, destined for a Level(3) customer in Seattle.

In our original design, this meant handing off the traffic to Level(3) right in Atlanta and letting Level(3) take it all the way to their customer in Seattle. It sounds like an excellent plan… give it to Level(3) quickly, and let them take it from there. After all, the ultimate recipient of the content is a Level(3) customer, so we would assume that Level(3) will do a good job of getting it to their own customer. And while Level(3) is one of the best networks in the US, this is sadly not always the case for them or any other network we’ve encountered. Packet loss and often-unnecessary latency across these networks has a very negative effect on performance. And when performance degrades, customers complain and ultimately point fingers at Uber Bandwidth.

In the new design, Uber Bandwidth retains vital control. In the same scenario, traffic leaving Atlanta for the Seattle Level(3) end-user traverses the Uber Bandwidth network all the way from Atlanta to Seattle. Only once the packets reach Seattle do we put it onto the Level(3) network for last-mile delivery to the end-user. In fact, if we could take it closer to the end-user, we would. The end result is highly superior. We retain control and can protect against network congestion, unnecessary latency and of course, packet loss. What we’ve implemented has virtually eliminated the already low number of tickets we receive regarding third-party network slowdowns. Once we’re done, the result will be even better.

There are a lot more exciting things planned for 2011, but we’re not quite ready to let the details out of the bag. Of course, we always want to hear from our customers and prospective customers. Tell us what you’d like to see, and we’ll definitely pool it with everyone else’s input for design consideration.

Happy New Year!

Jonathan Hoppe

{ Comments on this entry are closed }