by cgragtmans on December 10, 2010
Many of you are probably aware of the conflict between Level3 and Comcast over the past few days. The debate revolves around the extent to which Comcast can provide peering for the data that will now flow across both of their networks as a result of Level3’s Netflix business win. This dilemma points to the inherent problems in the operation of the Web today, and especially towards the shortcomings of backbone providers and their peering partners. We have in fact touched upon the basis of this dispute already in our previous Direct Peering blog post.
A good aggregation of information on this issue can be found in this Datacenter Knowledge article.
We won’t choose sides here, but a few things are certain…
1) The current system does not seem to be working. As Daniel Gooding, Managing Director of DH Capital and guest blogger at GigaOm says, “No one here did anything wrong; these disputes aren’t uncommon.” Clearly there must be a better way.
2) Netflix unfortunately hangs in the balance while Level3 and Comcast settle their squabble. Netflix and many other companies today hold efficient delivery of their services at the core of their business. If Level3 and Comcast sever ties and no longer share bandwidth, it is devastating for Netflix.
3) It is most critical for content providers to choose neutral parties for delivery of content. This is especially true for parties that are not also Tier-1 providers. These companies have much different business objectives than a CDN/Content Accelerator whose sole objective is efficient delivery of the content. Performance should always be the main objective, not saving money delivering content.
4) In this example with Level3, they are first and foremost a Tier-1 provider. They also happen to offer CDN services, but the fact that they are a Tier-1 affects their ability to deliver. Because of their Tier-1 status, they only have settlement-free peering relationships with other providers. They do not buy transit from anyone. In the case of Comcast, it’s not like they’re seeing any new traffic from Netflix, it’s just that the traffic is now coming from Level3 instead of other providers when it was previously with Akamai. So, Comcast is now being asked to spend money putting in a lot more connections to Level3. The bigger issue is probably that Comcast will now have many underutilized transit connections to other providers, which is costly, and there is no way for Level3 to send the Netflix CDN traffic to them any other way.
This crisis illustrates one of the problems that has been central in the creation of Cloud Acceleration. The fact is that these disputes do happen all the time, and they point to the importance of owning a private network with connections to every provider out there. If an Acceleration solution were in place for Netflix, any relationship severance between providers wouldn’t affect them whatsoever!
The outcome of this will be very interesting, and one must ask… is this conflict between Level3 and Comcast the beginning of a “water rights” type of dispute between Internet providers? Will we see more legal wranglings over who controls what portion of the Internet streams? How will this affect not only service providers, but end users as well?
In the words of Stacy Higgenbotham of GigaOm, “What began as a commercial dispute may end up fundamentally changing how the web works and who pays for it.”
Chris Gragtmans
by cgragtmans on December 9, 2010
DNS is the critical first link in a Website’s ability to load quickly for its users. CDN, Cloud Acceleration, and Dynamic Site Acceleration solutions don’t mean much if your DNS system isn’t giving you great performance and the level of granulized control you need. High performance and granular control have always been focal points for our business here, and the existing demand for such quality services points to the importance of utilizing a full-service cloud enabling vendor.
Amazon has recently announced the existence of the new Route 53 DNS service. As a developer at Cloud Leverage, I always look at the functionality of services such as these, and how they will generate value for you… the Web-enabled enterprises and SMBs of the world.
What you need to know about AWS’s Route 53…
The Amazon offering is interesting, and what it offers brings up some very important considerations about what Web-enabled businesses are trying to achieve with DNS solutions today.
The first of these considerations is the need for granular control and full management. The Amazon Route 53 solution is simply the bare-bones API, which is what we would expect from AWS, and there is no mention of a user interface included or available – so you, or your developers, need to be ready to roll your own DNS graphical user interface. In addition, integration with other Amazon cloud services is not native at the user-account level, so you will need to call any other Amazon Web Services you use and get your info there, then call Route 53 change requests to point records to say, your “bucket”. The list of supported records numbers 10…
A Format
AAAA Format
CNAME Format
MX Format
NS Format
PTR Format
SOA Format
SPF Format
SRV Format
TXT Format
Ten record types will cover the basics, but who wants to tout their DNS power as “um, we can cover the basics”? (I will take the opportunity to note here that our solution covers 26 DNS record types for total IPv4/IPv6 control.)
Another huge consideration is automatic zone file uploading and record creation. Amazon is saying that you need to get your zone files, and you are then responsible for converting them to the Amazon Route 53 xml data to send the request. Amazon does have a pearl script that you can download that you can use to convert the zone files to their xml. But don’t you want your DNS provider’s system to handle all that for you? Me too – that’s why our DNS system processes zone files automatically. Using Amazon’s DNS would become a bit of a pain if you had 2000 zones to migrate. You or your developer would have to parse each one to xml, then send a separate request, and then get a “pending” status and an API experience that amounts to a “here’s your change receipt, check back later if you don’t get an answer now”. Why would I do all of that when with our DNS I can zip thousands of zone files up and just upload the zip file and let the DNS system do the parsing? Also it will tell me what, if anything is wrong with the DNS records I upload – even remind me to change the authoritative name servers if I forget. So, suffice it to say the Amazon DNS offering is asking you to do the development yourself to get these things done.
It is a good thing that Amazon is jumping into the DNS space and lending credibility to the importance of the service. I mean we all know there are still plenty of folks out there that just aren’t aware of the power of the really good DNS solutions that are available now-days, so having Amazon step into the game will probably get some people who weren’t previously thinking about what they really need from DNS service to succeed going forward. The question for businesses must now become… go with a minimalist approach such as that offered by Route 53, or take advantage of a more complete and automated DNS API and UI with the features and functionality that enterprises today need.
To each their own, but we prefer to focus on delivering the latter.
Zach Farnham
