After years of languishing in the backwaters of cable industry tech discussions, a cable-optimized version of IP multicast has jumped to the front burner as an initiative at CableLabs and as a priority on the product development agendas of leading vendors.
In an update of R&D activity at the recent CableLabs winter conference in Atlanta, Matt Schmitt, director for DOCSIS, and Jesus Lopez, director of certifications, said multicast was among the initiatives related to development of an all-IP cloud-based approach to delivering pay TV service. Content ingest, encoding, packaging and ways to support alternate content and ad insertion are also part of the cloud initiative, they said.
People in the vendor community, on and off the record, confirm that cable multicast has reached the specifications development stage at CableLabs. “CableLabs is going to release a standard for multicast streaming of live content over ABR (adaptive bitrate),” says Thierry Fautier, vice president of solutions marketing at Harmonic.
The reason for this new urgency in multicast is obvious: with live IP streaming coming into play as part of cable’s TV Everywhere agenda, reliance on unicast streaming can’t last. While unicast is fine for streaming live content to connected devices in the home from a new generation of transcode-enabled media gateways, the need to make live channels available over the DOCSIS 3.0 network to wirelessly connected subscribers outside the home places a simulcast bandwidth burden on the network that can be greatly alleviated through shared subscriber access to multicast streams.
DOCSIS 3.0 specifications support the latest version of IGMP (Internet Group Management Protocol, v 3.0), but IGMP is not suited to the fast-channel changes and consistent quality performance required in the pay TV market, although DOCSIS 3.0 added some improvements by introducing QoS and security functions onto the multicast streams. Nonetheless, because IGMP is based on the “pull” model used with unicast streaming, the client requests for content that cause clients to be “joined” to a multicast stream are being made with no awareness or control over what’s going on in the network at large.
Now, much as was the case for telcos in their efforts to create a multicast solution for IPTV a decade ago, vendors are coming up with solutions which are feeding into CableLabs’ efforts to define the cable version. For example, Harmonic is formulating uses of multicast technology as part of its IPTV 2.0 agenda, with one component focused on the on-net segment of the cable network and another on the off-net segment.
“We’re doing load testing with operators to see how the technology works or doesn’t,” Fautier says. “We want to supply a tested, scalable multicast solution to the market.”
Fautier declines to say how closely Harmonic’s approach lines up to what’s emerging from CableLabs. But he acknowledges the company is paying close attention to what’s happening there.
RGB Networks, too, is working on solutions to the cable multicast challenge as part of its OpenStack-based cloud service platform. While declining to discuss details, Andy Salo, vice president of product line management at RGB, notes multicast is one of the tasks associated with delivering IP video that isn’t addressed by OpenStack, a pan-industry template for virtualizing multiple types of applications in the datacenter environment.
“Multicast is absolutely critical in the emerging cable video network, but it doesn’t work so well in OpenStack,” Salo says. “We’re doing things on the configuration and encoding side to get multicast to work with OpenStack.”
Two companies offering non-standardized versions of multicast that are getting a lot of attention in pay TV circles are Octoshape, which, as previously reported, has gained traction with various European distributors, and Broadpeak, which has developed a solution specifically designed for the cable market. Fautier says Harmonic’s solution is leveraging Octoshape technology for the off-net side of TV Everywhere, which is to say, for operators and programmers relying on OTT distribution to devices, while it is tapping Broadpeak for multicast over a cable-managed network such as will be used as the foundation for migrating pay TV to IP.
Octoshape’s proprietary approach to multicasting utilizes patented resilient coding schemes in conjunction with UDP (User Datagram Protocol) rather than TCP (Transmission Control Protocol), which is used with ABR streaming. The Octoshape-packaged multicast stream can be delivered to CDN edge points, where the Octoshape client translates the UDP single stream to TCP-based ABR streams formatted for unicast access by devices in whatever ABR mode is compatible with the end device. Or it can be sent deeper into the network to other unicast distribution points with excellent results as regards channel changing and QoS, judging from what’s been shown by Octoshape customers in trade show demonstrations.
Operating in a somewhat similar proprietary framework, Broadpeak’s nanoCDN technology is designed to convert ABR unicast streams from origin servers into single multicast streams for delivery to broadband gateways and IP-enabled set-tops, where the Broadpeak Agent converts content to unicast ABR streams in either the Apple HLS (HTTP Live Streaming) or Microsoft Smooth streaming modes without requiring the gateways to perform transcoding. This reduces bandwidth consumption over the broadband connections to the home gateways while minimizing the amount of processing performed by those devices.
Another cable multicast solution long under study is tied to use of the CableLabs PacketCable Multimedia (PCMM) protocol in conjunction with DOCSIS 3.0, although it’s unclear whether this idea still has the support it once did. PCMM is a server-based technology designed to orchestrate CMTS (cable modem termination system) functionalities for delivering a managed high-quality IP cable TV service, including coordination of sub-systems assigned to content acquisition, DRM, transcoding, media gateway, video server, subscriber management, billing, service assurance and, if implemented, multicasting. A PCMM-based server-side execution of multicasting would allow operators to maximize bandwidth efficiencies and to optimize QoS in the management of linear IP TV services across all devices.
Akamai is another vendor looking at solving the multicast issue, albeit on a broader scale that would apply to the needs of all providers of live streamed content. Moreover, says Kurt Michel, director of marketing for media products at Akamai, his company is addressing other challenges providers face as they search for ways to improve the quality of live and on-demand streams to levels expected of a TV-caliber experience. “The vision for us is how to deliver the highest quality of experience,” Michel says. “Multicast is just a part of the story.”
Where multicast is concerned, Akamai’s approach is meant to address the fact, as Michel puts it, that “no central body says all routers support multicast.” The question, therefore, is “how do you get to a place where everybody has got to play or you have to make up a protocol to get around the routers that don’t? There’s a lot of complexity involved.”
Given that Akamai has a pervasive global presence as a provider of CDN service, it could act as a “federation point” for receiving multicast streams and converting them to unicast. “Everyone doesn’t have to agree on a common language [at the router level], just the language we’re promoting,” Michel explains. “We’ll tell everyone this is a toolset we want you to use, and if you do, you will deliver a fantastic quality of experience.”
But that doesn’t exclude use of the cable multicast mode on the Akamai CDN, he adds. “There’s no reason not to build a gateway from one guy’s platform to another,” he says. “If we can deliver a multicast solution for the OTT market in general and use cable’s multicast as well, that’s great.”
The Akamai multicast solution isn’t a product yet. But it’s part of a mandate from Akamai CEO Tom Leighton ordering his teams to focus on what the needs of the Internet and especially the video component will be four or five years hence. “We are in deep innovation mode around what the next-generation network looks like,” Michel says. “We are thinking about client-side software that will deal with the limitations of today’s network, extending our technology deeply with client technology that works with our edge servers.”
A variety of techniques beyond multicast applying to all types of streams are under consideration to do things like accelerate delivery of long-tail content and make room for 4K through greater bandwidth efficiency. One key question is, “How do you deliver unicast streams with greater efficiency, utilizing the pipes to maximum capacity in a fair way that doesn’t destroy other traffic?”
Part of the solution, Michel says, is to be able to predict algorithmically what the user is going to do next so as to position content closer in advance. For example, if somebody is binge watching, it makes sense to put the next episodes out there at lower ebbs in bandwidth usage.
One big area of development has to do with compensating for the inadequacies of TCP, which, Michel notes, is an old transport technology based on protocols that are outmoded by today’s standards. He cites the much more efficient transport mode developed by Akamai partner Aspera, now a unit of IBM, as an example of what might be in the works.
“We partnered with Aspera to get big files loaded onto our platform,” Michel says. “Maybe we can extend what they do out into the network.”
As previously reported, Aspera’s fasp (Fast Adaptive Secure Protocol) technology uses UDP, replacing the overkill resend mechanisms used by TCP with proprietary methods that precisely identify and retransmit packets that have actually been lost while utilizing available bandwidth to the fullest extent possible based on the selection of optimal paths and various prioritization parameters. Moving such a “high-speed fast lane” into the network so that the efficiency achieved through fast mechanisms could more than compensate for bandwidth that would have been utilized by TCP to transport the same content might help resolve the video-driven bandwidth crunch that’s growing bigger by the day.