Earlier this year, a new proposal was submitted by Apple to the HLS specification which addressed CDN switching. The proposal, HLS Content Steering Proposal 1.1b1, was posted to the IETF hls-interest mailing list for comment, where it received considerable feedback regarding the proposal’s lack of compatibility with typical CDN tokenization schemes. An ad-hoc group from several CDNs (including a few SVA members) reviewed the proposal together and proposed a simplification which eliminated the token issues altogether and simplified the design. This subsequent Redundant Stream Steering Proposal (dubbed RSS) was also posted to the IETF hls-interest mailing list for comment.
As a bedrock of segmented streaming video, HLS is a critical component of many streaming workflows and platforms. The ability to steer requests from one CDN to another is a vital piece of operational functionality. But the content steering proposal put forth by Apple did not necessarily consider the many ways in which CDN switching can happen, nor the specific methods by which many commercial CDNs may support tokenization (which is critical to ensure the security of streams).
To ensure industry concerns were being heard, the Streaming Video Alliance recognized the need for a response from our membership, which reflects many of the world’s largest CDNs such as Fastly, Lumen, Limelight Networks, and Verizon as well as many large network operators such as Comcast, Telefonica, and Orange, who operate their own CDNs. But this proposed change to the HLS specification also impacts other elements of the streaming workflow as well such as security, advertising, and the player. As such, the Alliance response needed to include companies like THEO and Nice People at Work, Sky, and Commscope.
In just a week, the Alliance was able to coordinate a cross-functional committee (led by Glenn Goldstein of Lumen) to formulate a response to the 1.1b1 content steering proposal and the subsequent RSS proposal. Supported by Alliance staff, the group met twice to discuss a response, gathered comments in a Google doc, and then circulated to the wider Alliance members for general feedback. When finished, the document was formatted appropriately for the hls-interest IETF mailing list as well as publication on the Alliance website. In short, the following were the top-level concerns from the Alliance member companies:
- It is typical in multi-CDN deployments for different entities to provide distinct parts of the solution. Manifests may be generated and manipulated by multiple provider’s services, media segments may come from other provider’s service, and CDN recommendation intelligence may come from yet another service.
- The HLS Content Steering Proposal blurs the clean delineation of responsibilities across these services, putting responsibility on the Steering Service to generate CDN-specific path prefixes (and possibly tokens). A cleaner separation of concerns could be achieved by limiting the steering service’s scope of responsibility strictly to recommending pathways in a preferred order (as described in the Redundant Stream Steering Proposal).
CDN-Specific Tokens - Our most significant concern was initially about the inability to have CDN-specific suffixes on the steering templates, precluding the real-world situations where different tokenization schemes are used by different CDNs.
- While the addition of QUERY-PARAMS appears to address this problem when tokens are expressed as query parameters, it still requires that the steering server generates CDN tokens (see above: Separation of Concerns) and it doesn’t address tokens that may be inserted anywhere in the path as path parameters or segments.
The group fully-supported the RSS proposal:
- RSS embraces and extends redundant playlists (the existing HLS approach for supporting multiple CDNs) and is backward compatible with any player that supports redundant playlists.
- RSS provides a cleaner separation of concerns and simplifies the responsibilities of the Steering Service, as it no longer participates in generation of manifest URLs or tokens.
- RSS simplifies the HLS Stream Steering scheme by eliminating the steering templates, prefixes, query parameters, and any code complexity associated with supporting the template substitution.
- RSS avoids the token-generation challenges that have been identified, as token generation for media manifest URLs remains in the main manifest.
But identified a few concerns with RSS:
- Precludes the addition of pathways after the master manifest has been delivered (potential issue for very long streams).
- Can be challenging for static packaging workflows that do not perform dynamic manifest manipulation.
- As with the original HLS Content Steering Proposal, RSS doesn’t really solve the case for some SSAI and other manifest manipulation cases where all manifests (main and media) are served from a domain and service separate from the CDNs that only serve media.
Although not an Alliance-generated body of work, the HLS specification’s importance to the streaming workflow required that we respond as an organization. As an industry and community, the streaming ecosystem must come together to ensure foundational technologies, like HLS, are as interoperable as possible.
Jason is the Executive Director of the Streaming Video Technology Alliance, the international technical association for streaming video which brings companies from across the streaming ecosystem together to collaborate on technical solutions to delivering high-quality video at scale. In this role, he runs day-to-day operations, finances, member recruitment, strategy, and evangelizes the organization at events around the world. He is also the co-founder of a big data startup, datazoom.io. Jason is a contributing editor at Streaming Media Magazine and has written several books.