The video type we examine in this newsletter is distinct from the others we have studied. Adaptive bit rate (ABR) video is usually transported using TCP as the transport protocol. As we will see, this makes it operate very differently on an IP network than video conferencing, IPTV or video surveillance traffic. The fact that it uses TCP is unusual. For decades, conventional wisdom held that real-time payloads such as voice and video couldn’t be effectively implemented using TCP. This was because the receiver was required to deal with the latency of retransmitted packets. Microsoft, Adobe and Apple dispelled that myth by introducing Smooth Streaming, HTTP Dynamic Streaming, and HTTP Live Streaming, respectively. However, the two developments that demonstrated TCP’s appropriateness to carry video were YouTube and Netflix.
Virtually all forms of ABR video operate in a similar manner. A client player contacts a server and requests a particular asset (movie). The server authenticates the client and transfers a manifest to the client. This XML file contains the various forms in which the asset is available. For example, it might be available in standard or high definition. It also gives the addresses at which these forms of the movie are available. Once the client indicates the form in which it would like to play the video, the server begins to transfer sequential pieces of the video. These pieces are often called chunks and are usually about 10 seconds of video. As the video plays, the client monitors the amount of video in the playout buffer. When it reaches a certain level it triggers a request for the next chunk of video. The process continues until the entire asset is played completely.
The control protocol in this process is HTTP (Hypertext Transfer Protocol). This is the protocol used to retrieve web pages and to obtain material using a browser. HTTP is a request-and-fulfill protocol and not a transfer protocol. So, in all cases, TCP is used to provide reliable transport. Since TCP is being used, the behavior of this video on the network is similar to a series of repeated file transfers, each lasting less than ten seconds. It differs from most browsing by using the same source and destination ports. That is, it’s completed in a single TCP session.
ABR video is sensitive to network loss and jitter but not nearly to the extent that IPTV or a video conference might be affected. Competing traffic and oversized network buffers can create problems for the delivery of ABR video. For example, if a large system backup begins to use the same path as the video, the amount of bandwidth available to the ABR video might be reduced. This could cause the next chunk to be requested at a lower resolution. If network buffers are too large and filled to near capacity, TCP acknowledgement packets can be delayed in these buffers and TCP will lower its transfer rate. Oversized buffers are the current subject of investigation and the problem is referred to as bufferbloat. This can possibly cause a pause in the playout of the video.
In an effort to standardize the Adobe, Microsoft and Apple approaches, a standard method has been described called the DASH (Dynamic Streaming over HTTP). It focuses on a common format for the manifest sent by the server to the client.
