Level3’s smoke and mirrors
Level3 didn't slash pricing for CDN service with their recent 'same price as transit' marketing ploy. If anyone slashed pricing, Amazon did with the introduction of their S3 storage. All Level3 did was imply their baseline CDN service is no better than their transit....heck, at least they admit it. A couple points to note. Baseline CDN service really is transit or no better than transit from Internap or some other route aggregator and Level3 may have lost allot of money over the years so it should come as no surprise that they are at it again. This time with some method to their madness, they baiting customers and will up sell them on value added services or give the baseline product away for free but demand a share of the customer's revenue generated as a result of distributing content. In essence subsidizing the delivery costs of that content.
Questions that come to mind about Level3's shuffling of the product pricing boxes: How much is their storage going to cost? What about those companies who need some DRM functionality for their downloads? How much with that cost? What about custom players or layered advertising? How much with they charge for that and what percentage of the advertising revenue will they require you give them for using their CDN?
I read their new delivery pricing works out to about $11 per Mbps equivalent. Not a bad rate, but certainly not as low as some of the pricing from other players in the space. And definitely not free, yet. It will be free sooner than later because it will be subsidized by advertising dollars.
First it may be helpful to explain the difference between transit of data and distribution of data. Everyone on the internet has transit. It is the ability to send packets from one place to another. Inherently there is some form of intelligence built into transit because it is built into the core backbone routers of the major carriers and isps.
Example: you're sitting at your computer on Sunday morning checking your fantasy football scoring on the Sportsline website. You live in CA and have Comcast as your ISP. Sportsline is hosted in FL at the Terramark datacenter(not sure if this is actually the case and am using as an example only) and connected to the Internet in Terramark via Sprint. When you type in the url and hit return a request gets sent from you computer out your cable modem and onto Comcast's network. Comcast's routers see the IP address of where that packet is supposed to go, looks up in it's routing table what would be the quickest way to get that data off of it's network and onto the Sprint network. Since quickest doesn't always translate into best and in this case only translates into Comcast not wanting to carry the cost of that packet on it's network your experience is subject to all sorts of hiccups along the way. That first packets eventually gets to FL and Sportsline and when it does, the same process, only in the inverse order, happens again. The updated score makes it's way back to you in CA and all is well. In this instance the experience wasn't all that bad but the information you requested was quite small in volume of data required to get you that score. Imagine if, instead of the updated score, you were requesting the infamous Paris Hilton and Rick Soloman video. The file size of that video is exponentially larger than that of the score of the fantasy game and the cost to Comcast and Sprint is also exponentially higher to deliver than the score. Fortunately for you, Rick Soloman was out to make some dough and wanted the user experience to be similar to his own experience so he hired a CDN to help ensure the quality of the experience remained tip top :) Important detail to note, CDN's all buy transit and most buy it from multiple upstream providers. In this made up example, Rick was uhttp://www2.blogger.com/img/gl.link.gifsing ACME CDN who was a new CDN. Unlike Akamai, ACME was built from the ground up to deliver large video files and wasn't too concerned with the last mile. As such, they had a smaller # of nodes placed in carrier neutral data centers on the two coasts and a couple in the South and Midwest. Since ACME isn't a web hosting company, Rick needed to contract with a second vendor to host the rest of his homepage. Rick is a sharp cat and a penny pincher so he used Amazon's S3 file storage service which would itself have been sufficient had the video been of Rick and anyone but Paris. He understood S3's limits and since he was out to make add to the stack of paper he was blowing on Paris, he only relied on Amazon for the non revenue generating files. When you click on the 'watch' button on his site the url where it sends you is not on Amazon's infrastructure but on that of ACME's. Similar to the fantasy scoring example, Comcast's routers determine that the destination address is part of address space supplied to ACME and easily accessible via SBC who happens to be one of Comcasts upstream providers. Comcast dumps this packet onto SBC. Unlike Akamai, ACME's technology doesn't rely upon multiple DNS queries to determine where the originating or destination IP address is physically located. ACME uses anycast protocol/technology which allows it to have the same ASN at all of it's nodes. Another difference with ACME is that they aren't using a cacheing setup but instead are acting as the origin for their customers files. This allows them to guarantee that 100% of their customers files to be distributed will always be on 100% of their nodes. When using a cache, this can't be the case as only the most requested files remain on the node for a matter of time and then they're purged. Its great if you're popular but not so great if you're not popular of are very private data but depend on high performance. When SBC gets that packet it see's the AS it's destined for and dumps it as soon as possible. In this case that hap pend to take place in the same building, Equinix in San Jose. Both ACME and SBC are colocated at Equinix so there was minimal cost to SBC to deliver that packet which makes them happy to deal with ACME. Can't say the same for their dealings with Akamai because Akamai's nodes are out at the edges of SBC's network, in the CO's which would mean SBC has to keep those packets on it's network far longer than their ideal. Amazon's S3 cloud is located in VA and had Rick not used ACME for the origin location of the video, a similar process for delivering the fantasy football score would have occurred with the deliver of the video. Fortunately for you, Rick's decision to use ACME results in your viewing the video almost instantly and not waiting around for the packets to go back and forth from the West coast to the East coast.
So what does this have to do with Level3 pricing or the pricing of the CDN market in general? It highlights how much of a difference adding an origin storage component to a CDN can make in terms of route miles. If Level3 can charge customers more money for using less route miles then all the better, it may even make sense to give transit away if they can make up that $11/Mbps by making customers believe they're being so cutting edge with pricing and product positioning when in reality they're stroking themselves by driving more efficiency on their network.
Ohhhhh, if that were only the case. I guess theory sounds good on paper but reality is what it is.
Labels: Akamai, anycast, CDN, comcast, data center, dns, equinix, isp, James Crowe, Level3, Limelight, origin, pricing, routemiles, Sandpiper, storage, transit, transport
5 Comments:
Ciao Tomo,
thanks for the nice explanation to a non tech guy like me.
The CDN space still remains too difficult to understand, for me, with all its implications (baseline CDN, video, HD video, etc. etc.) and different technologies involved (P2P, being at the last mile or at big neutral data centers, etc.) and I guess different pricing for each of these services.
At least with data centers it was "easy" to understand that the neutral model was the winner. This seems a much more complicated arena.
This is a quote from Level 3 c.c., yesterday:
>>We view our CDN not as a separate and distinct business.
our goals with CDN is to recognize that some files will require different technical parameters that are better served from the edge some files are better served more centrally located and distributed over a network. We want to make sure that we make a very simple economic and technical proposition to customers that are trying to way the best way to move their files or move their content.
Our goal is to bundle all of that together in a way that is economically compelling for our customers and makes their traffic management, their network management much simpler.
We believe that our cost position by owning our underlined transport network and our underlined IT network which is a very big component of cost in a CDN network makes us uniquely positioned to bundle those products in a way to make it easier for our customer.
Jim Crowe
Kevin is making an important point that's worth underlined. Over time we are of the view that the difference between what is now called CDN and what is now called high speed IP and at times optical transport is going to blur and perhaps disappear, that is a very key observation.<<
http://seekingalpha.com/article/51004-level-3-communications-q3-2007-earnings-call-transcript?source=yahoo
What do you think about this approach? I don't really think Level 3 will become a major player in the CDN market, but I wonder if their target to solve customers' network management is a market need, today, with some customers, and could become an interesting selling point - I'm also thinking about other Companies who offer a bundled offering (colo, CDN, managed services), say NAVI or INAP.
3:53 AM
Hi Paolo,
Thanks for the note. I imagine you're quite pleased if you're still long on EQIX :)
Actually Equinix is a good example to use to illustrate why it pays off long term to stay focused on what you do best. There were plenty of opportunities for Equinix to venture in services which are "up the stack" and "drive more value" but they didn't, they stayed focused on a single thing, physical data centers and interconnectivity. Data centers are their main product, as without them they wouldn't be in spot to get the interconnection revenue.
The question around L3 that I can't seem to figure out is how in the world are they going to be the best at everything they've dabbled in....CDN, transit, transport, datacenters/colo, selling fiber IRUs, selling hardware, etc?
I don't think they can. Clearly they're having issues and buying a company distracts the attention away from the the problem temporarily until there is another problem somewhere else in their organization and they do the same thing all over again.
One thing is pretty clear which is that by publicly stating they don't see much difference in CDN vs transit isn't going to have any negative impact on L3 but certainly has created situations where Akamai has had some explainin to do.
One more thing.... it's almost impossible for L3 or any other backbone provider to be offer content distribution services and perform well if they don't buy connectivity from their peers or in L3's case some of their customers too. Which flies in the face of their argument that they have anb already fixed cost associated with their network which is true. But it's only for their network, not for anyone elses which they rely upon and essentially get a free ride on through peering. Rest assured, when they start competing against one of their peers and undercut them on price, that argument doesn't hold water.
All said, L3, like Amazon had, is married to their fixed costs. With Amazon it happened to be datacenters and racks of computing infranstructure. With L3 it is network. As proven by Amazon, running that fixed cost at a higher efficiency drives costs per transaction down and as it scales it can become extremely profitable. L3 appears to be applying this strategy by lowering their pricing and cannibalizing their own products lines in the name of generating more traffic to bring higher utilization to their sunk cost. The problem with this is that Amazon was good at running the servers and opening them up to additional users wasn't that far fetched. For L3 it's far fetched to assume they can add all of these services and be good at providing them too.
I think INAP could be chasing the same tail and losing focus on what customers like them for....they're aggregation of routes via a single connection. In theory a customer wouldn't need a CDN if they were colo'd in a few markets and bought transit from INAP in each one yet INAP is getting the peanut butter syndrome as well....ie, they're spread awfully thin. Not sure about NAVI, haven't followed them much but what I do know is the hosting space is white hot.
7:20 PM
Thanks for your comments. I am staying away from L3 as an investor, but that's definitely a story I'm watching. I wouldn't be surprised to see some strategy change on the road (again), or them addressing their large debt problem sooner than later.
Still holding Equinix, still very pleased with it, still my favourite business plan in the sector, still my major holding.
I just wish I had all the original shares I bought a while ago - but I guess it's almost impossibile for a small investor to cope with such a great success, you just end up selling a bit because it's "becoming too much money in a single basket". The opposite of what you should be doing, which is adding MORE as the story develops nicely. So I've started my own 10b5-1 Trading Plan a few months ago, at least no filing is needed in my case... :-)
But I think I'll keep a significant position for the very long term.
As I've always said, it's mainly been the pleasure of watching a fantastic turn around story and a great group of people achieving what Jay had dreamed of since the beginning (and some early investors had embraced).
And it's just so difficult to find someting else as exciting... :-)
Sorry for the digression... Ciao, thanks again.
4:57 AM
Hi
Where do I get information on the size and market shares of various players in US, Canada and Lat Am data center markets???
2:49 AM
Awesome....
11:03 PM
Post a Comment
Subscribe to Post Comments [Atom]
<< Home