The SRT (Secure Reliable Transport) Alliance is publicizing its new protocol as a good way to deliver video. I decided to take a hard look at it and see if the marketing is backed up by a solid technical design. I think it is.
SRT is intended to transport video over IP networks with many of the good features of adaptive bit rate (ABR) video but without some of ABR’s negative features. Here are some of the basic facts about ABR video:
- It’s based on the IP level four protocol TCP.
- While it can overcome lost packets, lost packets can significantly increase latency and slow throughput. Lower the throughput too much, and the video stalls (buffers). This is partly because a sender does not get an explicit NAK for a lost packet. In practice, over the internet, the sender can detect a lost packet only after dozens or several hundred additional packets have been transmitted.
- TCP uses a technique called slow-start (the transmission rate is gradually increased) to detect the maximum threshold a connection can support. Unfortunately, for bursty traffic such as ABR, it wastes bandwidth.
- Using TCP makes it sensitive to traffic levels in the opposite direction. Specifically, if you saturate the uplink, ABR performance on the down link will deteriorate significantly.
- ABR video nearly always uses HTTP. Consequently, it becomes sensitive to the efficiency of DNS.
- ABR does not natively support encryption. That needs to be added with SSL/TLS.
If you watch Netflix, Apple TV, or YouTube, you are probably satisfied with the ABR on which they are based. Note that Chrome users will not be using ABR; rather they use QUIC to view Netflix and YouTube. QUIC was developed by Google with some of the same design guidelines as SRT.
Here is what the SRT designers decided to implement in SRT:
- The layer four transport protocol is UDP (used in voice and videoconferencing). This automatically eliminates some of the negative features of TCP transport.
- Acks contain a receive rate and estimated link capacity. This increases the likelihood of even delivery.
- Packet delivery is time stamped.
- Error resilience is significantly enhanced by using FEC (forward error correction).
- Encryption is built in and based in AES-CRT, a widely accepted method.
- Slow start is not used.
There are some other non-technical reasons I like SRT. One is that they have committed to a draft RFC to appeal to the internet community. That’s imperative if you’re going to win the support of the IT community. Second, they have a powerful marketing message with their demonstration video, which is available on the home page of srtalliance.org. Some major players have already implemented SRT besides the originators Haivision and Wowza. Some of these include Matrox, Cogent, Marshall, and Teradek.
