Video: Tweaking Error Correction Protocol Performance: A libRIST Deep Dive

There’s a false assumption that if you send video with these new error-correcting protocols like RIST or SRT that you just need to send the stream, it’ll get healed and everything will be good. But often people don’t consider what actually happens when things go wrong. To heal the stream, more data needs to be sent. Do you have enough headroom to cope with these resends? And what happens if part of your circuit becomes temporarily saturated, how will the feed cope? The reality is that it could kill it permanently due to re-request storms.

In this video from VidTrans21, Sergio Ammirata from SipRadius talks about how the error correcting protocol within RIST works and how it’s been improved to cope even better in a crisis. Joined by Adi Rozenberg they remind us of the key points of RIST and the libRIST. As a reminder, RIST is one of many protocols which allows the receiver to let the sender know which packets its missed and for them to be resent. For a proper overview of RIST and SRT, have a look at this talk explaining RIST and SRT or the multitude of talks here on The Broadcast Knowledge on RIST or SRT. Today’s video is not so much about why people use RIST, but how to make it performant with difficult circuits.

libRIST is an open-source, free, library which implements the RIST specification. The aim of libRIST is to allow companies to easily implement RIST within their own commercial and free programmes. Sergio points out that it’s an active project with over 675 commits in the last year bringing RIST to many platforms including ARM, AWS, Darwin, iOS, windows etc. and is now on version 0.2.0, plus is soon to be in VLC 4.0 and FFmpeg 4.3.

To understand why getting error correction is important, we can look at the effects of a simplistic implementation of the negative acknowledgement error recovery method. When the receiver doesn’t receive a packet it sends back a request for a resend of that packet. The sender will send that and, hopefully, it will be received. Let’s imagine, though, that you’re in a data centre sending to someone on a 100Mbps leased line. If the incoming bitrate of your receiver’s internet connection started getting close to 100Mbps due to the aggregate traffic coming into the site, the receiver may start missing out on occasional packets leading it to ask for more packets from the sender. The sender’s bitrate then increases which reduces the margin available in the incoming circuit resulting in more lost packets. This cycle continues until the line is saturated. It’s important to remember that saturating an incoming link doesn’t mean traffic can’t get out. It’s quite possible there are hundreds of megabits available outgoing so there’s plenty of bandwidth to shout for more and more re-requests. The sender is quite happy to send these re-requests as it’s on a 10Gbe link and has plenty of headroom left. Only by stopping the receiver would you be able to break this positive-feedback loop.

Now, all protocols deliver some form of control over what’s re-requested to try to manage difficult situations. Sergio agrees that other implementations of RIST work well in normal situations with less than 10% packet loss, for example. But where bursts of packet loss exceed 20% or the circuit headroom dips below 20%, Sergio says implementations tend to struggle.

As a lead-up up to the recent improvements made in congestion management, Sergio outlines how libRIST uses internal QOS to maintain a bandwidth cap. It will also monitor the RTT every tenth of a second to help spread retries over time. By checking how the RTT is changing in these extreme conditions, libRIST is able to throw away redundant re-requests leaving more bandwidth for useful requests. The fact that the sender is doing this work means that even if the receiver is on an older version of libRIST or on another implementation, the link can still benefit from the checking the libRIST 0.2.0 is doing. The upshot of all this work is that no longer can libRIST deal with 50% packet loss, it can now deliver an unblemished stream up to just shy of 70% packet loss.

Watch now!
Speaker