Did streaming go wrong?

That question is becoming almost as common as, “Where did the dotcoms go wrong?” The only thing preventing a backlash of criticism of streaming technology to go along with the spate of criticism of the dotcom economy is that fact that applications like eLearning, corporate communications and truly viable consumer-targeted commercial streaming services have renewed the buzz around streaming media.

MAIN ARTICLE Growing beyond a single CDN: Peering content networks

For many the question still remains: Where did streaming go wrong? The answer is that it didn’t go wrong; it just didn’t live up to all the hype. 

In fact, the renewed buzz around streaming has come about because the first wave of streaming proved the concept. Now it’s time to make the concept work. But what does this next wave of streaming deployment hold?

The first wave of streaming consisted primarily of testing the effectiveness of digital multimedia as a communications tool and streaming technology as a means of delivery. Did it work? Would users be interested in it?

The content that was being developed was content that businesses were willing to pay for users--primarily consumers--to see. Generally, this took the form of rich content that would attract more users to a website, keep users on eCommerce sites longer, or was more specialized content that businesses had a reason to distribute more widely.

Two great examples of early-phase streaming applications that are still popular today are corporate earnings calls and online seminars, or “webinars.” Streaming technology helps organizations increase the reach of this content--in the first case to meet SEC guidelines, in the second to expand the reach of marketing efforts.

And the answer to the question of whether users would be interested was a resounding yes. Streaming content became a staple on websites of all kinds. At the same time, Internet traffic and the Internet user population were experiencing explosive growth. Not only were web objects getting bigger, but more users were asking for more of them.

This explosion in Internet traffic tended to oversubscribe both service provider and private networks, which typically were not set up to handle the traffic loads generated million of users accessing multimedia objects substantially larger that typically static http objects.

But while these two infrastructures--“public” or service provider, and “private” or enterprise--were being stressed in similar ways, the reaction of administrators in these networks was very different. On the enterprise side, streaming media was seen as a consumer tool, not a business tool. As a result, many enterprises simply did not allow streaming media on the network, and instead focused on business applications and traditional, static web content that didn’t stress infrastructure resources the way that streaming did.

Service providers, on the other hand, didn’t have the option to simply disallow streaming media. These network designers had an immediate need to respond to the growing demand on their networks.

A common initial response was to meet demand via “brute force” techniques: more servers and bigger network links. However, most service providers found that keeping up with traffic growth was too expensive using these methods.

To solve this problem, service providers turned to first-generation content caching techniques for both traditional http objects and streaming content. These devices stored content closer to users or at bandwidth aggregation points in the backend network, allowing redundant user requests for the same content to be served without taxing back-end server and network resources. The result was that networks could handle more content for more users.

Caching techniques worked well both for static http objects and “on-demand” multimedia objects, which were downloaded prior to playback. But as more content was streamed live, service providers recognized a need to a solution to provide resource conservation for live content as well.

Two responses to this need were stream splitting and IP multicasting technologies, each of which allows networks to pull a single stream from an origin content server while serving multiple copies of that same stream to different end users.

With multicasting, origin servers send streams to a special IP address and users “subscribe” to the address to access the content being served. The underlying packet network must be “multicast-enabled” so that packets are duplicated to multiple router or switch ports where needed to reach subscribed users.

Similarly, stream splitting refers to using intermediary devices to retrieve a single stream from an originating server and duplicating the stream for delivery to requesting users, typically via traditional “unicast” transport.

For both techniques, the reduction of backend streams can save a significant amount of network and server resources and enables a larger audience to enjoy high-quality access to live content. Because stream splitting enables this function without requiring upgrades of the packet network, it is popular with enterprises that might not have enable multicast throughout the corporate network, as well as with content and service providers that deliver content to enterprise users.

Eventually, with the meltdown of dotcom companies, many saw this as a failure of streaming. Since much of the justification businesses to spend money for the content and the network infrastructure to support streaming came either from advertising revenues, the slump in these sectors looked like a failure of streaming.

However, both enterprises and service providers saw the success of streaming media as a communications tool even if some of the underlying business drivers had been soft. For enterprises, online seminars and up-to-date rich media information services laid the groundwork for today’s early-adopter streaming applications like eLearning and corporate broadcasting. For service providers, the infrastructure put in place to improve the performance of streaming content is a natural building block for commercially viable streaming services.

The common thread in these applications is that they deliver content that someone is willing to pay for. Often this content existed already in other forms, but is cheaper or more real-time, or more efficient. Service providers can offer a wider range of content in an on-demand application than can effectively be broadcast on a traditional television or radio channel. Enterprises can provide just-in-time training from a digital training library, as well as minimize the amount of travel needed for training programs.

These drivers have touched off a second wave of streaming. In turn, this new wave is driving new infrastructure requirements for delivering streaming content. Caching and splitting technology enable the existing infrastructure to provide the quality of experience necessary to make streaming multimedia applications useful. On top of this underlying infrastructure, a richer set of features to control and distribute content is needed to make these applications work.

The first key need is for a means of providing discretionary access to content as well as a way to track users access to content. Whether it’s an enterprise human resources department that needs to track the effectiveness of a training program, or a video-on-demand service that needs to capture billing and usage information, content owners need information and assurance capability around who’s accessing what content.

Many of these control functions are met with emerging Digital Rights Management (DRM) packages that protect the rights of copyright holders and prevent unauthorized copying of content. This DRM function must interoperate with the delivery infrastructure. Streaming content delivery devices must be able to understand and enforce the rules of the DRM system, so that content can continue to be served locally to users and QoE is preserved.

The second key set of requirements centers around flexibility and reach in distributing and delivering content. This means different things for enterprises and service providers. In the enterprise, network administrators typically know where the users are and have the access necessary to deploy infrastructure to these locations. The challenge for enterprises isn’t reaching the user, but being able to deploy something cost-effectively that can deliver content with high-quality performance.

Service providers face this same issue: deploying a delivery infrastructure that can effectively deliver content directly to users. However, in the case of a consumer-oriented service, virtually no service provider “owns” enough customers to provide a reach that will scale up past an initial piloting phase. Instead, service providers need a way to provide a reach into a broad base of customers, possibly worldwide.

Getting this reach requires cooperation between organizations that traditionally compete with one another, so service providers can’t expect this access to come for free. Instead, service providers will need to enter into content peering relationships that define how content is distributed to the edges of other networks and what rights regarding that content the parties involved have, and how payment and tracking information flows from provider to providers.

These peering relationships will encompass more than the simple exchange of bandwidth and/or storage space in strategically located points of presence. Currently, there are several efforts underway to define standards for content peering, both in industry-sponsored initiatives and working groups in the IETF standards body. These standards efforts will help to define viable operating and business models for commercial digital media services.

So, streaming has not “gone wrong.” The first stage of streaming proved the effectiveness of streaming technology as a communications, training and marketing tool. It also generated a lot of hype. The second stage of streaming is beginning. In it, enterprises and service providers are deploying new rich media applications based on associated business and operating models that justify their investment.
Mark Kraynak is Corporate Marketing Manager for CacheFlow Inc., Sunnyvale, Calif. He can be reached at mark.kraynak@cacheflow.com.

Visit CacheFlow online.