Content Delivery Network Strategies, by Stef van der Ziel

HTTP streaming is seen as the holy grail. It is hot. But what are the benefits and downsides?

Let’s start with the technical differences of digital video delivery:

HTTP download

You place a media file on a regular web server. Using a client (browser or media player) you download the file. You have to wait for the file to be downloaded. There is no intelligence whatsoever on download speed or Quality of service. You can’t skip, fast forward or dynamically change the quality. Reporting is limited. A lot of traffic can be used, especially if the file is viewed partially. Cannot be used for live streaming. Works good with unreliable connections (3G).

HTTP progressive download

You place a media file on a regular web server. Using a client (browser or media player) you download the file. The player will try to show the video while downloading. There is no intelligence whatsoever on download speed or Quality of service. So the buffer could easily underrun causing stuttering and rebuffering. Or a lot of traffic is spilled if the file is fully downloaded but the user stops viewing before the end of the file. You can’t skip, fast forward or dynamically change the quality. Reporting is limited. A lot of traffic can be used, especially if the file is viewed partially. Cannot be used for live streaming. Not recommended for unreliable or heavily shared connections.

HTTP progressive download with skip

You place a media file on an intelligent web server like Lighttpd (YouTube) or IIS7. Our own solution is called StroboScope. Using a client (browser or media player) you download the file. The file may need to be injected with specific byte-range metadata. The player will try to show the video while downloading. There is no intelligence whatsoever on download speed or Quality of service. So the buffer could easily underrun causing stuttering and rebuffering. The server may be able to limit the download burst to limit traffic costs. You actually can skip and random access the files. Reporting is limited. A lot of traffic can be used, especially if the file is viewed partially. Cannot be used for live streaming. Stroboscope works with injected FLV files. Lighttpd works with MP4 and FLV files. IIS7 supports many file types and has the most advanced and dynamic bursting and burst tempering features.

True Streaming

You place a media file on a streaming server like Windows Media Server, Flash Media Server, QuickTime Streaming Server, Real Server or Wowza Media Server. Using a client (browser or media player) you request a stream. The file may need to be optimized for streaming. The file is not downloaded, the server and the client use specific protocols (RTMP, RTSP, MMS) to distribute audio and video data to the client via UDP. The client and server use intelligent protocols via TCP (RTCP for instance) to maximize the quality of service. Data is burst to the client for instant-play. Then the data burst is limited to keep a decent buffer at the client, to overcome dips in the network, but also to keep delivery costs down.

If needed, the client and server can decide to temper the burst, or to increase the burst, in order to maintain a fluent stream. Clients and servers can even decide to drop data (‘thin’) or not to retransmit data to make sure that more important data (like audio over video) will make it to the client in time. Some technologies (WMS, Real, some mobile servers) have advanced and dynamic multiple bit rate support. These files and streams need to be prepared.

You can skip and random access the files. Reporting is advanced. And live streaming is supported of course. The downside of RTMP, RTSP and MMS is that these protocols may be blocked by firewalls. Therefore, these protocols can be tunneled via HTTP. Most firewalls allow HTTP tunneled streams. The downside of HTTP tunneling is that traffic cannot be delivered via UDP but via TCP, adding roughly 10% overhead traffic.

HTTP Streaming

First of all, I don’t like the term. It is not streaming since all it does is transmit chunks of files via HTTP. True streaming dynamically transmits data via advanced streaming protocols. From a technical perspective it should be called HTTP progressive chunk download.

Second, it is not true that HTTP streaming is cheaper to operate than true streaming. For Smooth Streaming, a CDN needs to deploy II7. For the future rumoured Flash HTTP streaming, a CDN needs to deploy Flash Media Server (or maybe Wowza Media Server). Some proprietary HTTP streaming solutions (Move?, BitGravity?) may need specific additions or tuning to the used web servers. The only HTTP streaming solution that works with regular web servers is Apple’s solution. But that is a limited solution that doesn’t even work with Apple’s own QuickTime Broadcaster.

Actually, HTTP streaming with chunks also causes overhead traffic. Here’s why:

• An encoder chops an encoded stream into chunks of 10 seconds.
• The chunks are copied to the webserver.
• The chunk app publishes a playlist on the webserver.
• The client connects to the web server and downloads the playlist and the first three items for a 30 seconds buffer.
• Every 10 seconds (Microsoft does this every 2 seconds) the playlist is requested to see if there are new chunks available.

So every few seconds the client has to request a playlist. And has to request new chunks. This is overhead data. All this uses traffic. Web servers will have to cope with a huge increase in requests compared to streaming servers.

Actually, HTTP Streaming can increase costs for CDN’s even further:

Most CDN’s use caching techniques. They redirect users to the caches. The caches then pull the chunks and playlists from the origin server. Other CDN’s use intelligent asset replication services. Most CDN’s are optimized for large size files.

With HTTP Streaming, CDN’s have to deal with many small assets instead of less larger assets. Which means that CDN’s that have optimized for lager assets may encounter bottlenecks sooner or later. It is not said that all CDN’s can cope with realtime chunk distribution…

Chunks are not assets, but partial logical assets. Some CDN’s only distribute assets to edge servers when they become popular. They have to add intelligence to their asset replication engines to be sure that chunks are kept together and distributed as part of a logical asset. CDN’s have to make sure that hits on chunks are actually a hit on an logical asset. And CDN’s have to add intelligence to their analysis systems so hits on chunks are reported as hits on logical assets. Chunks view time and traffic has to be added to the logical asset report. There is no QoS reporting. Just chunk download log entries.

Although some CDN’s claim that they already support HTTP streaming, you should ask whether this is truly a fully supported solution or a first implementation.

HTTP streaming claims no issues with firewalls. My experience is that most firewalls already work with HTTP tunneled RTSP, RTMP and MMS streams. And note that any realtime video delivery method, whether it is progressive download, true streaming or HTTP streaming will be eaten up by poor administrated proxy servers. ISA is horror!