Plain Talk About Video Servers
By Steve Rose
Sunday, June 13, 2004
Plain Talk about Video on Demand Servers
Steve Rose, Interactive Content Engines
Interactive Content Engines LLC
(408) 876-4008
(808) 280-8080 (cell)
www.interactivecontentengines.com
(Rose has been involved with VOD and EOD since 1991, and video playback automation since 1973. His early work was cited as prior art in the lawsuit between Seachange and NCube. In the last few years he has worked with Pangrac and Associates, Andersen Consulting, Pathfire, Advent Networks, and Agile TV.)
Overview: This paper is intended to provide further background necessary to understand and evaluate VOD servers. It is meant to provide you with information helpful in making the best choice for your needs. Of course, we hope it will be our Interactive Content Engine. Even if not, the understanding should give you more tools to negotiate the best initial price and lowest lifetime cost for your needs. Indentation in this paper is intended to allow you to “drill down” in areas where you need a more thorough explanation, and skip what you already understand.
What is a VOD Server?
A VOD system moves content from storage to individual users. In general, it does not process the content – it is a playback mechanism that delivers content in an isochronous mode (one second of content is delivered during each second of real time).
The VOD server moves content from storage to a last mile delivery mechanism (typically QAM RF modulators or an IP network).
Important VOD Server attributes include reliability, scalability, initial cost per stream, and lifetime cost per stream.
Reliability: Reliability is generally achieved through the incorporation of redundant components for those components with higher failure rates , such as disk drives. At least equally important is the reliability of the software which operates the server. Frequently overlooked is the importance of simplicity of design. Sometimes adding hardware can reduce the reliability of a system. Reliability for a cable VOD server can best be measured in lost revenue due to service interruptions. Like golf, the lower the number, the better the player.
Scalability: We are in an era when more and more services are offered on demand, and the acceptance of on demand services is growing. TiVo™ has shown that a compelling answer is Everything on Demand. TiVo™ has also shown that cable operators lose control over commercial sponsorship when the consumer has independent control of presentation.
To be able to offer “Network Personal Video Recorder” (NPVR) services, an operator needs a server which is scalable to almost any number of streams. The limits of scalability of any server technology can be measured by how many users can be served by one copy of a content title. As soon as replication is required, the limits of scalability have been reached, and we have moved into the realm of redundancy.
Another scalability issue is “at what cost?”. Scalability means little if the additional cost per stream is greater than the new business case can support to remain profitable. To get to Everything on Demand, increasingly marginal services must be moved to an On Demand context. However, new business cases also arise when competition increases for existing services.
Initial cost per stream: To do a rational comparison between servers, you must be explicit in what is included in the cost per stream. Typically, the cost includes everything up to the modulator from a server manufacturer’s point of view, except headend shared resources such as standby power, and network and business management systems.. Sometimes the cost of the remainder of the system can be strongly affected by a choice associated with the server. For example, selecting DVB-ASI as the standard interface can be significantly more costly than using Gigabit Ethernet for the modulator interface.
Lifetime cost per stream: This is a more complex consideration. Is the technology selected near the end of its market life? What will the cost of replacement components be? Can the system be maintained by our own technicians? Will it remain interoperable with other equipment purchased at a later time?
Also in this category is “Future Scalability”: Can the system be expanded with then current technology, or must the upgrade be of the same vintage as the originally purchased equipment? If the system can be expanded with contemporary technology, does it take advantage of the new capabilities, or does it just emulate the original technology? And the worst case: If the system is to be expanded in a couple of years, will it require complete replacement via a “forklift upgrade”?
The Architecture of VOD Servers:
On The Back Side, There Is Storage
Storage mechanism: All contemporary servers store content on hard disks. Some can only offer to the user content which has previously been stored there, while others can offer content from the optical disk library or current, even live, events. The content is loaded to the hard disks from tape, optical disc, encoder, or data network source on a title-by-title basis. In some designs, popular content is then copied title-by-title into RAM to expand the bandwidth available for that title.
For some, content loading is a batch process – a title cannot be offered or viewed until it has been completely loaded. For others, such as the Interactive Content Engine ™, hard disk storage is considered to be a title-by-title cache, with the primary storage being the optical disc library. Any title in the optical disc library may be offered, as it may be viewed within moments of the beginning of the loading process.
Some servers move content on a title-by-title basis to RAM, or electronic memory, on the basis of popularity. The number of users that can be served from a title in RAM is ten to a hundred times greater than the number that can be served from a copy on hard disk. This approach may also reduce the physical size of the server (more streams per rack), in applications where high stream reuse is encountered. Because of the reuse, more output ports are associated with the RAM storage, so the “output port density” is higher. The drawback is the cost of RAM storage versus hard disk storage: RAM is about 100 times more expensive. The utility and value of saving content on a title-by-title basis in RAM depends on the architecture of the server, as explained below.
On The Front Side, There Is Deliver to End Users
Delivery mechanism: Contemporary servers use Gigabit Ethernet (GbE) for their outputs. This reduces cost and complexity, and can help simplify the server itself. It can also significantly reduce interconnection costs when copper GbE connections are used instead of fiber optic connections.
Legacy servers have generally used the DVB-ASI interface (Digital Video Broadcast Asynchronous Serial Interface), which is costly (e.g. $1200 for 213 megabits). Contemporary servers have moved toward Gigabit Ethernet, which is remarkably inexpensive ($100 for 1000 megabits or about 1/50 (!) the cost per stream of DVB-ASI), and less “fussy” about timing. Copper “Cat 5E” cables may be used instead of coax or fiber optics for modulator connections up to 100 meters away, further lowering costs..
This has been enabled by modulator manufacturers, who have been able to incorporate some of the functionality previously provided by the DVB-ASI standard into the modulators themselves. Multiple modulators (each delivering about 40 megabits per second) can be fed from a single gigabit input. VOD servers with Gigabit Ethernet outputs use Internet Protocol for transport, so they can connect equally well to digital networks.
What Is In The Middle Makes a Big Difference!
Internal Server Architecture: This is the key point of differentiation between different VOD servers. It determines scalability, reliability, initial cost, long term costs, system architecture (e.g. centralized versus distributed), and physical size. In essence, it determines the operator’s ability to respond to changing market conditions.
The architecture determines the number of simultaneous streams that may be delivered from a single copy of a content title: Answers here range from tens or hundreds of streams per copy to a number only limited by the capacity of the server. The best answer is unlimited, because this implies the smallest, least expensive machine, and no necessity to “micromanage” the server on a title-by-title basis.. Please note that this is not related to reliability. It is assumed that the underlying mechanism of storage of each copy incorporates adequate redundancy for reliability (typically about 20% extra storage capacity). As soon as content replication is required, significant additional management software is required for the server, as well as additional hardware.
The number of streams that can be generated from a single copy of a title depends on how the title is stored in the server. If it is stored as a single file, then the number of users that can be served before replication is required depends on the bandwidth of the storage medium. If the title is stored distributed moment-by-moment across all storage in the server, then the number of users that can be served from that title equals the total stream capacity of the server.
Moment-by-moment distributed storage of a title also has strong implications for storage costs. It no longer is necessary to store entire titles in RAM to get RAM speed and port density benefits, for example. If no one is watching a given moment of a title, there is no need to store it in RAM, since the bandwidth demand for that moment is zero! Titles may be automatically cached in RAM moment-by-moment, depending on the instantaneous demand for that moment. This allows far less RAM to have the same benefit as title-by-title RAM caching. And it works automatically for any title offered by the server. The bottom line for this approach is a significantly lower server cost per stream, without sacrificing port density or reliability.
RAM caching versus RAM storage: The Pig in the Snake Analogy
Titles (e.g. Movies) are not consumed in their entirety, they are consumed moment-by-moment. Demand for popular titles tends to be clustered in time by normal behavior patterns. When a snake swallows a pig, it only has to expand its body in the area occupied by the pig, which in time, moves through the snake.. In a VOD system, the greatest bandwidth only has to be provided for those moments in a given piece of content where there are actually people watching. Moment-by-moment RAM caching provides this extra bandwidth, without wasting RAM storage for moments in the content that no one is viewing at this instant. The RAM cache is reused based on what moments have not been viewed for the longest time, meaning it is always used in an optimal fashion automatically. No knowledge of the popularity of individual titles is required,.
The Pig in the Snake: Demand Clustering
The lump in the snake represents the allocation of RAM resources.. In the Interactive Content Engine, RAM is allocated automatically moment-by-moment.
The first person to reach a given point in time will incur the delay of reading the content from a disk drive (the delay is not significant and does not affect the viewer). Subsequent viewers reaching the same point receive their content from a RAM cache holding that moment. When the cluster passes, that RAM may be reused to store another moment of the same or a different title.
When a request is made for a moment of a title that is not already stored in RAM cache, the system determines which moment currently stored has not been used for the longest period. It reuses that RAM for the new request. This is referred to as the “Least Recently Used” or LRU strategy (algorithm). It guarantees the optimal use of memory at each moment, with no advanced knowledge of the popularity of a given title required. If a title is immensely popular, it may automatically be cached in its entirety, but only while the demand for all moments of the title keep it in cache.
This moment-by-moment caching strategy greatly reduces the amount of RAM required, by making the most effective use of what is available. It also allows a server to be tailored to the needs of the operator. In a case where each stream generated by a server is from a unique title, cacheing becomes irrelevant and the important parameter becomes disk storage bandwidth. With the appropriate architecture,it is easy to rebalance the ratio between RAM and disk storage in the field, as an operator’s conditions change.
Internal Server Bandwidth: A VOD server is a Bandwidth Machine. Assuming 50,000 subscribers, a 20% peak demand, and 4 megabits per second per stream, 10,000 streams are required or 40 gigabits of internal bandwidth for the server. There can be no bottlenecks in the architecture. In general, this means that a VOD server has to consist of many individual processors working together. The means by which they are linked is a primary element of the architecture, and determines cost and scalability. (Please see www.contentengines.com for a detailed explanation).
The same gigabit Ethernet switched protocol that has revolutionized the cost of the modulator interface has made remarkably low cost lossless interconnection possible within the server. In the Interactive Content Engine, this is enabled by our patent pending Synchronous Switch Manager™. Because of our technology, we can take advantage of interconnect prices which have become remarkably reasonable.
Distributed Versus Centralized Server Architecture: Some server architectures are only cost efficient when they are used in a distributed server deployment. Others are only cost effective in a consolidated, centralized server deployment. Experience has already shown that a system’s architecture may change after deployment. Having architectural flexibility is important to prevent future limitations. The best server is one which works effectively in either scenario (as does ours).
Interactive Content Engines rule of thumb for locating servers: The place where a server should be deployed is the point in the system where bandwidth goes from costing money if used, to wasting opportunity if not used. If multiple hubs are linked by leased fiber to a central headend, and by HFC from each hub to its subscribers, then the most economical place to put servers is in the hubs, with a central repository server in the headend.. The servers in the hubs act as caches.
With our distributed architecture, the whole assembly acts in the same manner and with similar efficiency as a large central server, but with greatly reduced bandwidth costs. It is not smart to send redundant copies of the same content, differing only in their point in time, over expensive leased bandwidth.
If the distribution bandwidth is owned or acquired, then consolidating everything in a centralized headend server can reduce maintenance and real estate costs. With our architecture, all that usually has to be done to convert a distributed server system to a centralized system is to reinstall the server hardware in the central location, and press a few buttons! The same equipment is used for our centralized architecture as our distributed architecture, and we can accommodate anything in between as well.
Interactive Content Engines LLC
(408) 876-4008
(808) 280-8080 (cell)
www.interactivecontentengines.com
Interactive Content Engines has harnessed low cost, high reliability components in an architecture which meets the needs of VOD / EOD providers at the lowest uncompromised cost per stream (we put the Comm in commodity).
We have used all of the most optimal techniques, industry standards, and architectural characteristics to reduce the cost of our Interactive Content Engines without compromising their reliability, scalability, or potential range of application.
Strong Points of Interactive Content Engines:
- Commodity, server quality components with exceptional internal bandwidth
- Highly reliable “hot swap” disk drives in an architecture that lets us use cooler and far less costly drives
- Gigabit Ethernet switch interconnects managed for optimum throughput by our patent pending management approach
- An architecture that lets us deliver any number of streams, up to the capacity of the server, from a single copy of a piece of content.
- Scalability from hundreds to hundreds of thousands of simultaneous, completely independent streams.
- The ability to upgrade deployed systems with new technology
- The ability to support any type of content, including MPEG-2, MPEG-4, and regular data
- Highly optimized moment-by-moment RAM caching giving us the speed and port density advantages of a RAM based server without the very high cost
- Gigabit Ethernet interconnects to last mile transport equipment (which we helped to pioneer)
New Business Opportunities
- The ability to record new content and make it available in moments.
- Real time content, including live events, with NPVR control.
- Centralized, private storage for video home and business security (bad guys will have to find another line of work when the probability of being caught and prosecuted gets close to 100%!)
- The ability to offer a library of thousands of titles, up to everything ever recorded
- Local library of unlimited size
- The cost of offering a piece of content is reduced to the negligible cost of storing an optical disc
- Links to other content libraries around the world
- The ability to offer specialized individual training and education
- The ability to offer local cultural information and resources
- The ability to individually target advertising
- The ability to charge for content provided without commercial interruption
From a business perspective, we also allow a cable operator to remain in control of the content revenue stream. TiVo ™ is under the control of the viewer, with no feedback to the cable operator as to who is bypassing commercials. With a centralized EOD server, the marketing department is back in control of how content may be offered. This applies to individually targeted, opt in marketing, which can be most effectively offered with our server capability.
Everything, Any Time: Interactive Content Engines
