HTTP Streaming Is Not Cheaper To Deliver, Industry Setting Wrong Expectations

Over the past few months, there's been a lot of talk in the industry about HTTP based streaming and how new technologies like Microsoft's Smooth Streaming are going to change the future of video delivery. While most industry insiders want to talk about how technologies like Smooth Streaming enable content delivery networks to scale and delivery video cheaper than using proprietary streaming protocols and servers, to date, no CDN is charging any less for HTTP based streaming.

The big selling point I keep hearing industry people talk about is that since CDNs already have a big footprint of HTTP based servers, they can save money on not having to deploy and manage streaming specific services like FMS and WMS. While this makes sense on paper, the problem I see with the adoption of HTTP based streaming is that none of the CDNs who currently offer it charge any less for HTTP based streaming. While HTTP streaming might be cheaper for them to deploy over time than say RTMP based streaming, if they aren't passing that savings onto the customer, where's the incentive for the content owner to adopt it? Taking away the pricing argument, there are still some great reasons for a content owner to adopt HTTP based streaming, mainly having to do with higher quality, but it seems they don't know what those values are and no one seems to be talking about them.

The other problem with this topic is that industry people automatically assume HTTP streaming is cheaper for CDNs to deploy and manage, yet to date, we have no proof of that. In order to support technologies like Smooth Streaming, CDNs have had to upgrade their networks and get hands on with the technology. They have to deploy it on their network, change the way it ties into their reporting system, since this is now the delivery of chunked files, and become familiar with the service and be prepared to support it. All of that costs the CDNs time and money and until there is a big enough demand for HTTP based streaming, it's not cheaper for any CDN to deliver. Nothing is ever cheaper for a CDN unless it takes into account the economics of scale, something not currently taking place with HTTP based streaming.

Down the road, the opportunity exists for CDNs to better control their internal costs if they can use the same box to delivery any type of content, based on the standard HTTP protocol. But right now, that's not a reality. While we hear a lot of people talking about the incentive for CDNs to move to HTTP based streaming delivery, what's the incentive for the content owner? We see the value for the CDN and one of the corresponding values for the content owner could be that if it costs less for the CDN deliver, they may pass some of that savings onto the customer. But today, that's not happening. And with HTTP based streaming and multi-bitrate encoding, a content owners delivery and storage costs may actually go up, not down. Not to mention, what's the cost to a content owner who has to re-encode their content to support HTTP based streaming?

Since nearly all of the CDNs in the industry already charge one price no matter what format the media is in or what protocol is being used to deliver it, chances are, CDNs won't start discounting HTTP based streaming anytime soon. It's possible that a CDN may start offering HTTP based streaming at a lower cost to make a name for themselves or use it as a marketing pitch, but considering that all CDNs are still trying to become profitable, I don't see that being a tactic of their's anytime soon.

The value in HTTP based streaming and technologies like Smooth Streaming needs to be about something other than cost. I think the industry is setting some really poor expectations with content owners when they have heard that HTTP based streaming is much cheaper to deploy, but then don't get a cheaper price from their CDN when they ask for a quote. Customers I have spoken to are then really confused as to what the value is when it comes to HTTP based streaming services since to date, the industry has only been harping on the lower price argument.

Lower cost is not what the industry should be selling right now, since that's not taking place in the market. Yes, there is an opportunity for content owners to potentially get a lower price in the future if HTTP based streaming takes off and CDNs find a way to pass that savings onto the customer. But until that happens, if it happens, the industry and vendors need to focus on educating content owners on what the value of HTTP based streaming services are today. Not something that may or may not happen down the road.

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.

Comments

[HmmConvenient]

HTTP is a dumb protocol, in theory easier to manage than a dedicated streaming server. If anything there is a huge window of opportunity for Cisco CDS and other caching vendors as they can deploy caches within corporate networks to optimize & control video delivery.

The implications for TV Everywhere are also significant, with HTTP practically any MSO could deploy their own "video" network without requiring the scientists that make FMS/ WMS/ * perform at the likes of Akamai.

[Ray Hood]

Dan -

I think the "cheaper" theory is based on the idea of simplifying the CDN's overall infrastructure from supporting a variety of streaming and content delivery technologies (Flash, WM, HTTP) to supporting fewer or even one (HTTP).

Of course the CDNs will try to avoid passing through the cost savings preferring to keep the new margin, but eventually one of the players breaks down and then they all will.

[Shawn Przybilla]

I would argue that HTTP delivery allows the content owner to talk CDN prices down. If you are constantly at 90% cache efficiency, I am sure the CDNs will take notice when you try to re-negotiate pricing.

[Prashanth]

HTTP also allows greater reach and penetration. It is easy to block RTMP (and often it is) from corporate networks etc. So, HTTP, again a claim that needs to be quantified, allows content owners to reach more viewers especially, day-time corporate users.

[Prashanth]

Also, there is a big difference between how CDNs architecturally support live and VoD traffic. VoD traffic, whether supported via RTMP or HTTP, is supported by an architecture similar traditional HTTP (this is based on copying content and caching it at many locations). The above is not true for Live video.

For Live video, with RTMP, the servers need to be arranged in an overlay multicast. Reflectors are setup to receive and forward content to other FMS servers. With HTTP, this architecture is again similar to traditional caching architecture. So, though HTTP live has greater latency, architecturally it is easier to build and manage if you already have an HTTP caching architecture.

These factors will hopefully permit more players to deploy HTTP live streaming services (including corporations looking to bring in their own data-centers) and competitively bring down the prices.

[Seth]

*If* HTTP streaming is coupled with adaptive bit-rate, then theoretically it might be cheaper than other existing solutions (lower bit-rate = less to deliver, though obviously, if the user has high-speed connection they could be watching a higher bit-rate file = more expensive).

IMHO: HTTP streaming is part of a paradigm shift- where yesterday you couldn't get the functionality of "Streaming" outside of special protocols, today/tomorrow you will.
Furthermore, I think we may see Private Delivery Networks start to take off - so this notion that it is all about what CDNs charge is/will be obsolete.

[Scott Safe]

Smooth Streaming has added storage costs for a CDN deployment - streams encoded at various bit rates require storage. CDN vendors don't have to lower their costs, they have a built-in pricing model that takes advantage of the increase in storage requirements. while not the major factor, in an on-demand environment these 'monthly fixed costs' will add-up. Reporting on the actual streams utilized will help content owners determine which bit rates really need to be supplied to meet actual user experience.

[Stef]

Dan, I totally agree. There are some hidden costs for CDN's to implement HTTP streaming. I just finished an article on my blog to explain this: http://www.jet-stream.nl/blog

[grinsandfun]

Well - at least they are not charging a premium... such as you mentioned back on Oct 3, 2008 (I.E. Akamai article on streaming vs. http).

Question I keep having - if all of the CDN's keep driving costs of their services to zero - how does everyone expect to have a long term ability to make any revenue here (or even ROI the investment)? Everyone keeps pushing back on price, where is the focus on quality and other pieces to the equation (ease of use, quality, etc). How do we get the "advocates" in the industry that are getting paid to speak on this stuff to focus on the value add's vs. the costs of the delivery mechanisms?

If I could sell something for free and get paid on it (and the customer paid nothing either) - where is the money coming from? This market is quickly commoditizing itself and diminishing it's value of the investors...

[Steve Lerner]

Which falls faster- a box filled with 100 pounds of bricks or a box filled with 100 pounds of feathers?

I can't believe that there is any debate about the cost to deliver video over HTTP vs a stream (for on demand video). The cost of equipment and licenses amortizes to nearly nothing when spread across all the bits delivered.

The only cost left is bandwidth- and the cost to deliver 1GB of video over HTTP is the same as 1GB of video via a stream.

They both use the same amount of bandwidth- so no reason to debate this any further.

A much better question is: can a server deliver the same quality of viewing experience using a lower bitrate method over a higher bitrate method that has the same technical acceptance by the same viewing base? If the answer is "yes" then the lower bitrate method can reduce costs.

Of course this is all only valid for on-demand... live is a whole different issue (and one that people are wise to avoid)

[Stef]

@grinsandfun and @Steve Lerner: Interesting two remarks.

Grinsandfun is spot-on right to say that CDNs (should) add value over regular traffic delivery. QoS guarantees, performance guarantees, customer service, reporting and management. So why should a CDN be as cheap as regular bandwidth? If a CDN offers a premium service, it should come with a premium price.

@Steve Lerner, I agree that software costs are very small piece of the operational costs of a CDN. HTTP or streaming delivery does not make a difference in operational costs. If one pays more for streaming, he should look for another CDN. The real costs are in infrastructure and organization. The challenge for CDN's is to be as efficient as possible while offering a wide choice of formats and protocols. So their price can be nearly as low as the carrier price for traffic. But IMHO a CDN should offer a better service than a regular carrier can do and can therefore charge a little more as well.

[Kevin]

"can't believe that there is any debate about the cost to deliver video over HTTP vs a stream (for on demand video). The cost of equipment and licenses amortizes to nearly nothing when spread across all the bits delivered."

Equipment is depreciated not amortized.

"They both use the same amount of bandwidth- so no reason to debate this any further."

HTTP uses MORE bandwidth due to overhead.

"The only cost left is bandwidth- and the cost to deliver 1GB of video over HTTP is the same as 1GB of video via a stream."

I don't care for this statement either. In the real world of networking the number of GB delivered is irrelevant. Customers might be billed that way but the CDN's along with other bandwidth providers and ISP's etc, GB delivered is completely irrelevant. HTTP is much more effecient from a network standpoint. Even though http will consume more badwidth to deliver the same amount of bits to the customer it is still more efficient and on a large network suchat Akamai or Limelight would in theory be cheaper to deliver. Streaming is one of the most ineffecient uses of bandwidth I can think of.

The goal of the network operator should be to deliver the bits as fast as possible and then to get them off of the network. a slow steady connection is a bad use of resources vs a fast burtsy connection.

It's similar to a highway. outside of the safety issues in this example the most efficient use of the highway is for every car to get on and go as fast as possible and get off. If everyone got on the highway and went 10 miles per hour (such as with streaming) and spent 6 times longer on the highway traffic would build up and cause traffic jams slowing the traffic down even more. If there is open space on the highway (bandwidth) the goal should be to get on and off as fast as possible making the space available for the next car (or download).

With a well designed CDN this can mean the difference of only needing 2TBS egress capacity instead of 2.5TBS of capacity. It would be highly variable but could result in modest cost savings. Notice I said modest savings, this is by no means a huge cost savings.

[Steve Lerner]

Kevin,

I'm not sure about where your information sources regarding CDNs originate, but you may want to double check them.

"Equipment is depreciated not amortized."

Depreciation is for financial accounting- not for operational costing. Amortization is used for operational costing. You amortize the cost of a device by its output units to get a cost per unit.

"HTTP uses MORE bandwidth due to overhead."

The amount of overhead is insubstantial when it comes to bandwidth costing, therefore irrelevant.

"In the real world of networking the number of GB delivered is irrelevant."

In the real world of networking, GB is the only relevant number. Its a proxy for Mbps (if you know the magic formula for conversion) and has become the de facto billing unit for CDN. Mbps for telco, GB for CDN- and this article is about CDN, not telco.

"The goal of the network operator should be to deliver the bits as fast as possible and then to get them off of the network. a slow steady connection is a bad use of resources vs a fast burtsy connection."

That is not necessarily the goal of a CDN. The goal is quality of service and performance, not necessarily speed.

"It's similar to a highway."

A CDN is not a highway- a CDN is more like planning a shopping mall or supermarket- getting buyers to the right place at the best speed to maximize monetization. A telco is like a highway. CDNs are not telcos.

CDNs are a totally different business than telcos in terms of operations (although frighteningly similar in terms of economics)...

Feel free to email me to find out more about how they operate if you are interested and google me to see where my info comes from.

[Thierry]

Dan, I would say that smooth HTTP Streaming is cheaper if user leaves the webpage, because you send video by chunks with smooth HTTP Streaming.

There are plenty of UGC websites who stream all the video, let´s say IE 2 minutes video, and user will only watch 10 seconds!

[John C]

Here's why HTTP streaming isn't cheaper for CDNs.

Small files which fall out of cache quickly. Especially live streaming like Apple or Smooth Stream. Now you have little files which are only valid for 10 seconds until the next segment is created.

Now the cache is filled and dumped every 10 seconds. This isn't a good model for a CDN. They rely on the cache to fill with larger files and stay fresh for hours/days, etc.

The constant little files being purged all day long will reap havoc on the hard drives. At least the segments will probably be around 1MB so it's not as bad as 10KB files, but still not too good.

Have fun!