Level 3 Comments On The Future Of HTTP Based Streaming

Over on the StreamingMedia.com discussion lists, a big debate has been raging over whether or not HTTP based streaming and services like Smooth Streaming are cheaper for content delivery networks to deploy. Earlier in the week I wrote a post saying that today, it's not cheaper to deploy and for content owners, doesn't cost them any less than other forms of delivery. With both Microsoft and Apple making a strong push for HTTP based streaming and Adobe hinting since the beginning of the year that they will provide support for it before too long, there's no question that HTTP based streaming will play a big role in the future of video delivery.

While I spoke to a couple of CDNs about their HTTP deployments for both Apple and Microsoft's platforms, Level 3 was willing to give out some additional details for the blog and I did a quick Q&A with Mark Taylor, the Head of Media Product and Strategy at Level 3. Here are his thoughts on HTTP based streaming and some of the positive signs Level 3 is seeing with their deployments.

Question: Is HTTP based streaming cheaper for Level 3 to deploy and manage today when compared to FMS and WMS services?

Yes. There are three areas where it is more cost effective for a CDN.

Firstly, we have no software integration on any of our edge servers with the new HTTP streaming solutions. For significant new versions of proprietary streaming protocols, that do not use HTTP, this integration is a significant amount of work for our development teams. We effectively have to fold the new technology into our own ecosystem. There are a lot of things we have to build to turn the streaming vendor's code, a framework really, into a functional service. And even when we have the code built we have to go through rigorous regression testing before we can roll it out onto the thousands of servers throughout our network - we clearly have to be completely satisfied that no existing customers will be impacted negatively. Contrast that with the new HTTP-based streaming technologies where we need do almost nothing; maybe a few tweaks to our existing caching code in order to improve efficiency. And of course nearly every time there is a new feature or a code upgrade we need to go through the same cycle again.

Secondly, it is simpler and more efficient for our operational teams to manage. There is less complexity and we don't need to build any new management tools. Managing one technology is clearly easier than managing many technologies that all essentially do the same thing.

Thirdly, CDNs do not pay any traffic/bandwidth/volume related fees to the HTTP streaming software vendors.

Question: Do you envision being able to offer customers a lower price for HTTP based streaming services in the future?

As online video continues to grow towards TV sized audiences, we need to be in a position to provide an incredibly scalable and highly efficient infrastructure. For all the reasons mentioned above, we believe that HTTP delivery offers the best path for that. Being able to concentrate our own R&D efforts on continuing to reduce the cost of bit delivery, without being distracted by deployments of other code, is important. Being able to have the most effective and efficient operational team with extraordinarily deep technical expertise is also important. However, the whole industry has lived for many years with competing technologies. Right now we are not planning to differentiate our pricing. But we will lobby hard for the entire industry to embrace what we think is the best delivery technology for all of us. And at some point, it may become necessary, or someone may want to exploit the difference in cost as a differentiator, so it will be something that we continue to monitor closely.

Question: HTTP based streaming takes a lot of the guesswork out of a CDN trying to figure out what percentage of proprietary streaming servers to deploy on their network. What direct impact does that have on a CDN's cost?

It's all about efficiency. Having, say, 10,000 servers "worth" of capacity in a CDN network capable of delivering any bit for any customer is the most efficient approach to capacity management. In that environment you can develop tools that track usage growth across your network and augment appropriately when needed. It's a science we know well as a network operator - this sort of simplicity was part of the reason IP replaced many other networking technologies at the core of our network. Contrast that with having those same 10,000 servers worth of capacity sub-divided into six different delivery technologies. Firstly, the pool of capacity for each individual technology just got cut dramatically. But your capacity planning just got a whole lot harder. Now you also have to deal with the complexity of changes between technologies. This isn't simply a traffic management issue any more. It becomes a market adoption issue, a battle between competing technologies that we need to monitor and forecast. So, it is more expensive for us. But also traffic spikes or events are harder to deal with which leads to potential difficulties for our customers. If it was a trivial matter to re-purpose servers, from one delivery technology to another, then dealing with those spikes would be easier. But it isn't trivial.

Question: What demand are you seeing for HTTP based streaming services and how educated are content owners with the pros and cons of each?

We are seeing huge demand for adaptive bit rate technologies in general NOT just the HTTP based ones. Media companies are excited about the potential for improved quality and end user experience that adaptive bit rates offer. Their driver isn't necessarily related to the actual delivery technology in most cases. However, the biggest media companies do recognize all of the issues I mentioned above. Because, don't forget, they have to build it themselves as well. CDNs rarely deliver 100% of anybody's traffic. So while our customers may not experience the issues to the degree the very largest CDNs do, they are well aware of them.

Question: What's needed in the market for content owners to adopt HTTP streaming in greater numbers? Do they understand the total cost of ownership?

They need to experience that ease of set up and ongoing management for themselves. Our experience has been dramatic. We were up and running with the two newest HTTP streaming technologies in weeks. It takes months for a large CDN operator to set up an equivalent non-HTTP solution. But, I think this is well understood by all the software vendors in the industry. I believe it will evolve there anyway, within the next 12-24 months, without the content owners making any explicit technology choice.

Question: Delivering reporting based on HTTP streaming is much more difficult since the streams are based on chunked encoding. How will CDNs manage that change?

This is a very good question. And this explains why we just re-engineered our content analytics and reporting platform. We expected a massive increase in the volume of data that we would have to collect, collate and make available to our customers - so we built that on a completely new platform. What we are now doing is collaborating with our customers and the software vendors to figure out how best to make this data available to them - how best to present it and mine through it. We don't want to overwhelm our customers with that data. But we need to understand clearly what business decisions our customers are making with that data. This is so new that we are all still working that through. But it is an incredibly vital part of this change in our industry. We may have a more efficient technology for the CDNs. We may have a far better user experience for our customers end users. But we also need to ensure we can manage our network and that our customers can make appropriately informed business decisions that enable them to be as profitable as they can be. Reporting is central to that.

Question: MBR and HTTP based streaming is all suppose to be about delivering better video quality at a cheaper price. Will this enable content owners to truly make more money from their content over time?

It is certainly a part of enabling them to do so. And it is extremely important and probably long overdue. But at least as important, if not more so, are advertising technologies and advertising work flows. The potential exists for far higher quality advertising. Different forms of advertising. Better targeting of advertising. Better campaign management across online and other forms of advertising. All these things are aimed at increasing CPMs (or whatever form of measurement you want to use for ad dollars) for on line advertising. Advertising effectiveness needs to improve significantly before we reach the TV audience sizes online I mentioned at the start.

Comments

[Christopher Levy]

Dan, Great piece here. Thanks for continuing to delve into this subject with industry leaders to your readers' benefit.

[SomeGuy]

How come you never talk to Move Networks about this who have been doing HTTP streaming since `06? Are they even doing streaming anymore or did they change their entire strategy? Just curious.

[Dan Rayburn]

@ SomeGuy: I spoke to Move about this with their new CEO less than two months ago:
http://blog.streamingmedia.com/the_business_of_online_vi/2009/07/moves-new-ceo-to-focus-company-on-providing-solutions-for-full-linear.html

Also, I've also done a lot of posts about Move Networks over the years. Just do a search for Move Networks in my blog search bar.

[John]

Dan,

In your blog post from Monday, you said:

"Added: I forgot to mention that I spoke to both Level 3 and Limelight Networks who said that today, HTTP based streaming is not cheaper for them to deliver."

Why is Mark Taylor at Level 3 now contradicting what was said last Monday? Was the source you spoke to earlier at Level 3 incorrect?

[Dan Rayburn]

Hi John, Mark didn't say that it was cheaper "today" for Level 3, he says it will be, but it's not today, they are not charging less for it and are still working to deploy it on their network. So all the folks from Level 3 are on the same page, but Mark gave more details on the future impact it will have.

[Steve John]

Dan

As a company that has been delivering HTTP progressive video for almost 3 years, we have found little difference in CDN delivery costs. Where we have made a massive saving is in the reduction in volume of the data requiring delivery. It has proven to be more important to use an advanced video compression codec, than which form of streaming technologies used. I am sure that this will change over the next 12-18 months, however, in the meantime, we have reduced our delivery costs by almost 50% without picture quality loss, while also increasing user access even over low broadband connections, simply because of video compression, low delivery bit rates and good data flow handling. As always a great article, look forward to your next....

[Damien Wetzel]

Hello Dan, I believe if http adaptative streaming proves to be a reliable technology, it could be the end of the rtmp protocol (and latter of the flash player). From my experience On Demand Flash delivered via http works better than via rtmp (less sensitive to network congestions) and poses less issues (firewalls, scalability) for streaming within the enterprise LANs. When it will be possible to distribute Live Flash content via http servers then FMS will turn useless and a swiss army player like VLC could be a fatal weapon to the flash player in the long term.

[Steve John]

Hi Dan, I have to agree completely with Damian, we stopped using RTSP streaming in 2006, we abandoned RTMP 15 months ago, we have found that HTTP is the most stable method of multiple delivery of high quality video content. We divide all our videos into small data chunks, this has an added benefit of making the copying and theft of video content extremely difficult. We have found that this combination of small chunk and HTTP progressive download makes for a very stable delivery across a CDN. We have been doing a continuous live test broadcast 24/7/365 since 7th March 2008 between London and LA without a failure, so we are more than confident that we have made the correct choice of compression/delivery technology. I suspect that others in the same broadcast industry will follow on very quickly. The benefits of any cost savings detailed in this article, will only start to come into the equation once the majority of companies are using the HTTP technologies and there is little or no point supporting the other more demanding delivery technologies. I am sure Mark will be pleased to hear we are a Level 3 customer and very happy with their services.

[Damien Wetzel]

the only thing i wish is that the technology can at the end be implemented in any webservers (apache, nginx, etc..) and the client not only be silverlight ;)

[Steve John]

We are running from a Linux platform using apache and we don't use SilverLight or any media servers at all. We developed our own HTTP progressive download delivery system almost 3 years ago and designed it to run on any Web server or cluster of servers. Our system can control how Windows Media Player, QuickTime Player, Real Player, Flash Player and VLC all are opened, closed and what "play" functions are applied to each video download. We also have full server side reporting of each delivery showing a status report from every viewer. this ensures both a stable delivery and also means we know the play status on every viewer's machine. Packet loss is reduced to a minimum and playback is constant. Because of the much lower bit rates we employ, combined with the reporting, we also have not had a need to employ the more complex "adaptive" HTTP streaming systems, we have found it is not required. An average live broadcast displaying ¾ D1 video quality is usually sent at between 500 and 650Kbps (rate subject to picture content) with full stereo sound. Frankly our view is no one is going to expect a quality “live” video delivery to be available on less than a 1.5Mbps broadband connection. Our 24/7 test broadcasts connections are capped off at 1.2Mbps (upload and download connection speeds) and a single pass encode with a 4-6 second delay between camera and viewer produces an enjoyable delivery experience, so why make it more complex than it needs to be…... We expect this type of webserver delivery to become fairly standard over the next 2 years especially as Broadband speeds continue to increase and the need for "picture quality" is moved up the scale of important demands from online viewers.

[Miquel Urmeneta]

I agree with the comment by Damien. Although the fact is http Live Flash streaming is already possible. Flumotion is now providing this service via a native protocol as well as offering other multi-format solutions. The technology has been developed to embrace the best of both http and rtsp streaming protocols such as seeking functions, allowing the user to skip to any point during VOD files.

In regards to pricing, as the technology developed by Flumotion has always streamed via http protocol, we have been able to apply the economics of scale that Dan mentioned in a previous post. As a result, right now http delivery can be more cost effective than other solutions using different protocols.