Ustream’s Software-Defined CDN Could Become A Bandwidth Exchange For Live Broadcasters

Ustream has developed a reputation for its ability to host some of the world’s largest streaming events via their HD broadcast video platform. The company hosted more than 1 million concurrent viewers and 8 million total viewers during the launch of Sony’s Playstation 4 and regularly hosts 70 million viewers per month. And, while it is enough of a challenge to scale to accommodate a large audience when the size is predictable, it is even more difficult to scale fast when the audience size is unpredictable.

As a result of these problems, Ustream decided to create a unique solution that is the result of seven years of development – a technology Ustream calls Software Defined CDN or SD-CDN. If Ustream takes what they have built and offers it to anyone, as a stand-alone service, customers would then be able to buy live delivery services from what is essentially a bandwidth exchange. This would be a very interesting model because to date, there is no easy way for large content owners to buy from multiple CDNs, without going and doing a contract with each CDN individually.

One proven aspect of Ustream’s platform is that it can scale for audiences that start quickly, accelerate quickly and then leave once the live event is over. Large audiences like these bring several challenges:

• The sheer amount of bandwidth needed often requires using more than one CDN provider to cover all viewers in all parts of the globe
• It’s important to ensuring a high-quality stream with as little buffering as possible and HD quality playback for each viewer no matter what device they are on or where they are globally
• Handle the bandwidth and quality needs in the most cost-efficient way possible. While it is always possible to add additional servers or CDN capacity to accommodate the peak usage pattern, this often means during times of lower usage that extra capacity is wasted.

Ustream’s SD-CDN includes the following properties:

• Ability to scale automatically without manual provisioning of resources, dynamically adding and removing edges and providers on the fly as needed.
• Ability to leverage a combination of edge resources, which include: CDN providers, transit lines, peering and ad-hoc edges, including those located inside an ISP’s network on inside a private network (for example an enterprise network). A new edge resource can be registered and serving traffic in less than a minute.
• Ability to flexibility and instantly route traffic amongst any of the above listed sources based on a combination of rules to maximize resiliency, quality and cost.
• Built-in monitoring to evaluate the performance of and efficacy of the competing sources on a global scale or down to the individual viewer.
• Ability to tweak business logic in real time if scale, quality or cost are jeopardized by changing conditions.

Ustream’s SD-CDN works by deploying a software layer that transmits, receives and processes metadata between the sources of video content (streaming servers, CDN edges, transit lines, ad-hoc edges) and the destination of the video content – end user viewing devices. Each Ustream player that is deployed has a connection called the Ustream Media Server connection (UMS) which sends back real-time data each second. This creates an enormous amount of data, as each connected player (even if they are not yet playing or have already stopped playing video content) is sending back real-time data about the status of that client. This connection is a two-way connection, so it is used to deliver messages in both directions. For example, the player reports back to the SD-CDN its IP address and logic can be triggered based on that, such as whether a viewer is in a restricted country or not.

This same connection can be used to carry data about whether or not that player is buffering. This data is all processed at a few geographically distributed locations to ensure redundancy and analyzed in real-time using proprietary algorithms so that it can be interpreted. The algorithms contained in the SD-CDN central servers look at things like if a player is buffering, is it just a single viewing client, or is there a pattern of buffering in a specific region? Since switching between sources can occur on the level of a single client, then an isolated issue can be addressed in a client side switch, thanks to the SD-CDN. But if a large number of client-side switches are being reported back to the SD-CDN, then the SD-CDN can make a large-scale switch to completely disable a certain CDN provider or an ad-hoc edge if necessary.

Since the SD-CDN includes monitoring capabilities, the automatic logic can always be overridden or augmented by real-time monitoring at Ustream’s NOC. A network operations expert can spot a pattern not picked up automatically by the algorithms and use the interface of the SD-CDN to have instant control of the entire system. Over time, as new patterns emerge, they are added to automatic recognition algorithms of the SD-CDN.

The SD-CDN is particularly interesting and useful when looked at in concert with Ustream’s other streaming technologies. Ustream offers a cloud transcoding service so you can send a single high-bitrate HD stream and Ustream generates the lower bitrate and resolution versions of the stream from the original stream. When these versions are created, there are time synchronization markers added as metadata in the stream. This is important for switching between bitrates on a single player from a single source to ensure the stream content does not jump or skip back in time, but these markers also become relevant so that via the SD-CDN, the Ustream player can actually perform a seamless switch between streams coming from two completely different sources.

Ustream’s delivery platform can adapt to provide the best possible quality for each viewer or to make changes on a larger scale to pre-empt an issue before the viewing client reports it. In addition, a major function of the SD-CDN is the ability to manage traffic across a network of CDN providers, transit lines, peering and ad-hoc edges based on the cost considerations of carrying traffic of a given volume at any given time.

For those familiar with CDN pricing and contracts (www.cdnpricing.com) a typical situation is that a content provider is expected to predict in advance the amount of usage they will have on a monthly basis and to sign a long-term contract based on that. It is typically a use it or lose it proposition, whereby overestimating usage will result in sunk cost with no ROI, and underestimating usage can lead to steep overage fees. In addition, the provider is incentivized by way of scaled discounts to commit to a larger package because the unit economics become more appealing by buying in bulk.

The rules of this game make it a tricky proposition for any content provider wanting to maximize the value of their investment in a third-party CDN service. This is one of the key advantages that Ustream’s SD-CDN can provide. For several months, Ustream has been able to utilize third-party CDN services at a flat 95/5 usage pattern. This results in an optimal ROI in the contracts Ustream has with third-party CDN and transit providers. This cost savings can then be passed on to viewers, which is one of the reasons Ustream can offer the same scale and quality of delivery as many leading CDNs, even at lower costs.

While Ustream has used this solution extensively for delivery of video content, the company says what they have built is content-type agnostic and can be put to work for any kind of HTTP traffic, such as gaming or any Web-based application acceleration. Ustream is currently using their Software-Defined CDN to control all of its video content and is considering offering the solution as a stand-alone service for others with similar needs. If Ustream starts selling their platform as a stand-alone delivery service, it would be an interesting disruption in the market.

Most third-party CDNs aren’t experts when it comes to the entire ecosystem of live events. They can handle the delivery, but a lot more goes into a live event than just delivering the bits. This is why companies like Ustream, Livestream, Twitch and others who specialize in live broadcasting have all built their own live broadcast platforms. If Ustream can take what they have built and offer it to anyone, customers would then be able to buy live delivery services from what is essentially a brokerage exchange. This would be a new way of buying live delivery services, from multiple CDNs, all based on a specific quality of delivery tied to the time of day. The company hasn’t officially said they will offer it as a product yet, but did tell me they are looking into it. If they launch it as a stand-alone service in the market, it’s a very unique proposition and one I think they could have success at.