Stream Caching with TeraEDGE

New "content distribution server" tames the biggest bit-hog on the Internet, proxying, storing, and managing live media streams at the network edge. An initial deployment will broadcast summer Olympics.

by Lisa Phifer VP Core Competence, Inc. [September 11, 2000]

As proponents of web caching have long known, storing content at the network edge reduces backbone congestion and bandwidth use, while speeding content delivery to end users. Streaming media, arguably the biggest bit-hog on the Internet today, would seem a prime candidate for caching. Early cache extensions for real-time streaming protocols enabled stream splitting. Bandwidth was saved when more than one media player shared the same live broadcast, conveyed just once across the backbone between media server and cache. These caches proxied live streams, but they did not store them—until now.

Among the first
In August, Entera, Inc. announced general availability of TeraEDGE, a software cache that records HTTP/FTP web content and RTSP real-time streams. According to Entera VP of Marketing Richard DeSoto, TeraEDGE is more than just a cache. "We call it a content distribution server because it retrieves content on demand, routing requests to the nearest origin media server. Streams retrieved on first access can also be cached for later reuse," said DeSoto.

To do this, TeraEDGE employs two streaming proxies. A proprietary RTSP/RDT RealProxy engine, licensed from Real Networks, supports interaction with RealServer G2 and RealPlayers. A homegrown standard RTSP/RTP engine supports Entera's TeraCAST streaming server Apple's QuickTime, and Sun's Java media players. "We're being pragmatic by providing both standards-based and Real Networks proxies," said DeSoto. "TeraEDGE can communicate with any RTSP server. But we can do more with TeraCAST than we can with a Real G2 server."

Notably missing: Microsoft Windows Media Streaming (MMS). "On the client side, we have major customers asking for both MMS and Real.," said DeSoto Entera designed TeraEDGE for multiple streaming agents and will add an MMS engine in a future release. Until then, DeSoto believes RTSP will satisfy most of the market. "Measuring the MMS client market depends on who you ask. By some accounts, QuickTime has a larger installed base, and it gained ground faster than any other client last year."

Delivering streams over the Internet
Delivering quality multimedia over the Internet presents many challenges. Before streaming, audio and video clips had to be downloaded in their entirety before use. Streaming lets a media player start presenting content as it arrives, frame by frame. To speed delivery, media is commonly transported over UDP. But datagrams get lost and arrive out of order. Many players buffer frames to improve quality of the stream presented to the end user.

Streams are, by nature, bandwidth intensive. When many streams compete for resources over a highly variable and lossy medium like the Internet, client-side buffering is not enough. Delaying an occasional HTTP/TCP packet a few extra seconds degrades user experience. Delaying streamed packets, however, can render multimedia unplayable, and dropped UDP packets leave "holes" in the stream.

Furthermore, interaction between client and server is required for "rich" multimedia. End users want VCR-like controls that pause, rewind, forward, and index into streams. Content providers who own media servers want the ability to authenticate and charge users for delivered streams. The Real Time Streaming Protocol (RTSP) enables setup and control over streams delivered from media server to client. Defined by RFC 2326, RTSP acts as a "network remote control." Content itself is delivered using data protocols like RTP (RFC 1889) or Real's proprietary RDT. These real time transport protocols allow frames that arrive out of order to be reassembled with the intended timing and sequencing.

These protocols are, of course, used between origin server and media player client. But they can also be used by proxies to relay live broadcasts and on-demand content. During a live broadcast, an RTSP proxy uses one data session to receive the stream from a media server. It may split the stream to several clients, deliver the stream over IP multicast to many clients, or pass the stream through to a single client. In each case, the proxy accounts for use by establishing an RTSP control session per client. Only authorized clients can receive the stream, and statistics are returned to the media server for each client. Live stream delivery is analogous to pay-per-view TV— consumers join the regularly scheduled program and pay for what they watch.

Another delivery model resembles video-on-demand: Consumers request a movie whenever they want, and have discretionary control over playback (pause, rewind, etc.). On-demand stream delivery from origin server to media client can be impractical, costly, or completely impossible, depending upon network bandwidth, speed, and loss. Delivering on-demand streams across the backbone in volume would quickly gobble up capacity, even if quality of service could be adequately controlled. Often it cannot be. Clearly, the most economical approach for delivering high-quality on-demand streams is to cache them at the edge of the destination network—for example, at the broadband CLEC headend, backbone NAP, or ISP POP. Emerging products like TeraEDGE do just that.

page 2: Caching on-demand content