Close
Close

Published

RIST protocol gains ground but confuses market

Just as Secure Reliable Transport (SRT) seemed to be gaining critical momentum to become the leading protocol for low latency streaming, so another one comes along to sow back some doubt among providers of both live and on demand OTT services. The stated goal of the Video Services Forum promoting its alternative protocol called Reliable Internet Stream Transport (RIST) at first sight only adds to the confusion, being to produce a common low latency standard ensuring interoperability within the wider streaming ecosystem, irrespective of the vendors and technologies represented in the underlying infrastructure.

There was a gathering conviction SRT was designed to achieve that, being open source and governed by a fast-expanding alliance of currently around 200 industry members, including big hitters such as Microsoft, Harmonic, Synamedia and Comcast, as well as various streaming pioneers. It was founded by Wowza and Haivision as a successor to earlier protocols that failed to optimize live streaming performance at low latency across unpredictable networks, especially at large scale.

However, RIST is now gaining momentum at least as fast following formation of its RIST Forum in March 2019, with some of the same companies among its 21 founding members, such as Synamedia and French encoding vendor Ateme. More intriguingly, Haivision, the company most intimately associated with SRT as founding member and strong advocate, was also among these inaugural supporters of RIST, so we have to take it seriously and take a closer look. We come to an immediate contradiction in that RIST’s founders insisted that the initiative was about interoperability more than innovation, being to ensure that all low latency streaming technologies and products would as far as possible work together.

But now, as Wes Simpson, co-chair of the RIST Alliance and President of media training services firm Telecom Product Consulting, told us, there is a strong focus on innovation as well. This derives partly from one key difference between RIST and SRT, which is that while SRT is an open source protocol, RIST is an open specification pitched as a common denominator for interoperability.

As Simpson pointed out, the RIST model is similar to the approach that was taken by MPEG to H.264, which specified just the syntax of the compressed streams to ensure interoperability at the transport level, leaving both encoder and decoder developers free to innovate around that. Simpson contended this has enabled H.264 to evolve for longer and to a greater extent than would have been possible if the underlying code base had been frozen and that the same approach is already yielding benefits for RIST. He claimed RIST can handle higher rates of packet loss than RIST again of up to 50%, even if this is somewhat academic in most real environments delivering live streams.

He does though raise an interesting point because there has been growing debate over the merits of open source as a means of ensuring diversity of development where the whole is greater than the sum of its parts. The open source model has undoubtedly had some huge successes but also brings logistical and resource challenges for enterprises that adopt the resulting software, especially for critical applications. Open source is defined as the production of software by unincorporated communities around a given code base using selected permissive licenses to facilitate greater adoption and sharing. This does allow innovation around that code base but that also can act as a brake on development, with success depending on how clear the vision and governance of the project are. If it is well run, as the SRT Alliance would insist its project is, then it can result in a stable product that can still evolve and adapt quickly over time through extensions to that underlying code base by participants.

However, it was the adoption of the open source model that helped give rise to RIST out of concerns that SRT would not by itself address the interoperability problem. RIST’s founders admitted that there were already plenty of promising emerging low latency technologies or protocols, but the problem was these were either proprietary as in the case say of Zixi, or for SRT slightly constrained by the open source model. But since then RIST members have expanded their ambitions to encourage innovation.

Both RIST and SRT are founded on the connectionless UDP protocol of the IP stack, which unlike its sibling TCP does not itself support packet retransmission in the event of errors or drops. But unlike SRT, RIST uses the established Real Time Transport Protocol (RTP) for the media transport on top of UDP to address packet loss and provide the foundation for some of the interoperability, but perhaps at the cost perhaps of ultra-low latency. It uses sequence numbers enabling detection of packet loss by noting when there is one missing, along with timestamps to remove network jitter if required. This use of RTP ensures that RIST-compliant systems can interoperate with non-RIST systems at a base level in the absence of packet loss recovery. It also, incidentally, highlights that although RIST itself appears to be a new kid on the block, it is founded on older established ones with a few twists on top.

Then for retransmission requests, RIST uses the Real Time Transport Control Protocol (RTCP) associated with RTP. This allows ranges of packets to be transmitted in the event of losses being detected. A critical point here is that to keep the protocol stable, the receiver must be able to differentiate between original packets and retransmitted ones, to ensure that the flow is maintained. If for example a retransmitted packet arrives too late at the time packets ahead of it have already emptied from the receive buffer, it must be ignored. RIST uses the standard SSRC synchronization field in the RTP header to make this differentiation, as recommended by RFC 4588, but with the difference that the least significant bit of that field is set to 0 in original packets and 1 in retransmitted ones. This simple innovation allows the maximum compatibility with non-RIST receivers, with the ability to decide whether to ignore or take account of retransmitted packets after noting the value of that bit.

The other innovation worth mentioning is support for bonding in RIST, allowing a high-bandwidth stream to be sent over multiple low-bandwidth connections and reassembled at the destination. This has two benefits, firstly to increase flexibility and possibly reduce cost of transmission; and secondly for error free streaming over poor quality networks by sending duplicate streams over separate links. Both of these use cases can also reduce latency, by in the first instance avoiding the need to wait for a high bandwidth stream to become available, and in the second by reducing or avoiding the need for retransmissions since the redundancy is enabled by using duplicate paths.

However, SRT embodies more advanced mechanisms to strip latency, including dynamic retransmissions where packets are only resent if they would arrive within their latency budget, along with ability to reconstruct the order and timing of packets at the destination to minimize additional processing delay.

For an even-handed assessment of the two from the field, we can turn to Ulrik Rohne, VP Research & Development at Swedish media transport firm Net Insight, which joined both the SRT and RIST alliances at around the same time. “SRT is a bit more advanced when it comes to fundamentals such as firewall traversal from both sides and encryption while RIST has more path protection features such as link bonding and FEC,” said Rohne.

He also identified where, as they presently stand, each would be more appropriate. “RIST is more suited and designed for high-bandwidth applications and has a better fit for remote production since you can converge all traffic in the same protected tunnel, essentially minimizing operational complexity. However, we like SRT because it helps our customers move content freely to any and all vendors supporting SRT, including Microsoft Azure.”

What we anticipate, with increasing overlap between the respective alliances, is some convergence between the two protocols with the common feature, as we keep on saying, being innovation around the UDP framework. In the absence of convergence, service providers may end up having to support both, as Rohne suggested. “Given the momentum we see with both RIST and SRT, I believe we are bound to see massive ecosystems forming around the respective technologies, and therefore organizations may need to support both to maximize reach, and simplify exchange, of content.”

Close