This chapter describes how to optimize video across your network. Video is one of the fastest growing technologies in business today. Video supports an increasing number of applications, business processes, and training videos. Video on the WAN frequently consumes 30 to 60 percent of the bandwidth. Whether as video-heavy applications or streaming media, video can comprise more than half of traffic.

With RiOS 9.8 and later, SteelHead appliances support Dynamic Adaptive Streaming over HTTP (DASH), also known as MPEG-DASH.

This chapter includes the following sections:

You can use video to disseminate information either through live or recorded content. As of RiOS 9.1, these are the solutions for video optimization:

Distribution of video impacts not only the overall bandwidth use, but it also impacts other services running on the network. In the case of live broadcasting, you might need multiple simultaneous streams per broadcast to support multiple bit rates (for example, remote or wireless workers might watch video at a lower bit rate, while viewers in the office might watch video at a higher bit rate for a larger screen). As the number of streams increases, the likelihood increases that other services, such business applications, are affected.

Depending on the codec, resolution, and software in use, video distribution can use anywhere between 16 Kbps (for a low resolution, highly compressed video stream optimized for a small display) to 15 Mbps or more (for a high resolution HDTV stream) per stream. Typical enterprise video streams use between 350 and 500 Kbps to support a single user desktop application.

Connectivity can be overwhelmed quickly and does not scale well when you compare these speeds to typical branch office connectivity, in which you send a single stream for each user. For example, a typical T1circuit running at 1.544 Mbps (or an E1 running at 2.048 Mbps) might be able to serve users’ needs for many business applications, but it cannot support more than 4 or 5 concurrent video streams. When the entire company might be watching a video broadcast or video conference at the same time, the need for efficient delivery of video across the WAN becomes clear.

When you optimize video streams of either type, you reduce the overall impact of video traffic on the WAN, thereby ensuring service continuity and optimal user experience.

RiOS uses HTTP stream splitting to optimize the following different live video technologies:

You can optimize video technologies for on-demand video. For details, see Video on-demand with HTTP prepopulation.

An unoptimized live video stream can saturate a T1 link with as few as four viewers. Normally, each client that connects to view video draws its own stream, quickly exhausting the resources of smaller branch office links. With stream splitting, one stream per bit rate is sent from the data center to each branch office, and software at each of the branch offices splits or replicates the stream for each individual client connecting.

Use HTTP stream splitting to reduce the number of duplicate streams operating between the server-side video server and the branch office clients. When you enable stream splitting, the first request for a video stream at a certain bit rate is sent out over the WAN, and the requests made by additional clients at the same branch are sent from the SteelHead. These additional requests are serviced after the client-side SteelHead has cached the first chunk of the video (typically, a single video consists of multiple video chunks or segments). As a result, only one copy of the stream is sent across the WAN no matter how many viewers are tuned in for the live stream. In RiOS 9.2 and later, the SteelHead identifies these streams using the video manifest file or video header metadata.

By using new streaming technology, you can ensure viewers always get the quality of video best suited for their conditions. Viewers with more bandwidth and processing power receive a higher-quality video stream than viewers with less bandwidth and processing power. If another user requests the video at a different bit rate, another stream is created for that rate.

Figure: Server-client video streaming shows a streaming video session between a single streaming video source and multiple clients at two client sites. The client-side SteelHeads provide a video stream for each client site. One client at Client Site 1 requested the video at a different bit rate and another stream at that rate is provided for that client. Both a client-side and a server-side SteelHead is required for this deployment. Each client maintains an active TCP session with the video stream source; this session is generally used for licensing purposes.

RiOS 9.1 and later improve live video stream splitting with the following enhancements:

For more information about these enhancements, see the SteelHead User Guide.

For CLI commands associated with this feature, see the Riverbed Command-Line Interface Reference Manual.

The following resources provide more information:

Company updates and new internal training videos are examples of video content that can cause bursts of traffic when they are first made available. Video content is generally accessible only from web servers and can only be accessed using HTTP. Prewarming RiOS data store during off hours helps to reduce WAN bandwidth consumption during peak hours. While HTTP prepopulation enables you to prepopulate any information over HTTP, this feature is geared toward video optimization.

For more information about HTTP prepopulation, see HTTP prepopulation.

You enable the web proxy feature from the SCC, and you must have the SteelHead xx70 hardware platform running RiOS 9.1. You can configure rules to select traffic that is cached on the client-side SteelHead. You must mark the content you want to cache for web proxy so that the video files are stored as web objects on the disk.

Using the web proxy feature achieves the same benefits as HTTP prepopulation, but web proxy uses a different area of disk inside the SteelHead, enabling larger objects to be cached. Any subsequent requests for the same content that is in the web proxy cache are served, in their entirety, from the cache. Serving the video locally removes the overhead of transferring the redundant request over the network.

For more information about web proxy, see Overview of the web proxy feature of the SteelCentral Controller for SteelHead Deployment Guide, the SteelCentral Controller for SteelHead User’s Guide, and the SteelHead User Guide.