Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now


Phil Hippenstteel on SRT

The next few newsletters will focus on the new transport protocol Secure, Reliable Transport (SRT). Introduced to the market by Wowza and Haivision, SRT has dozens of companies supporting it through their membership in the SRT Alliance. We’ll consider, at a fairly moderate technical level, how it works. Then we’ll compare it to other transport methods developed by the AV industry. Lastly, we’ll study how it compares to transport methods developed within the IT industry. Competition is increasing among all of these techniques due to the rapid growth of video on IP networks.

SRT is designed to deliver video over the enterprise or the Internet. In many respects, it emulates HTTP/TCP transport used by adaptive bit rate video (ABR). However, as we will see, it avoids many of the negative characteristics of ABR. SRT is a one-way media flow that uses a two-way control flow. Rather than TCP, it uses UDP as the layer four transport protocol. This single fact eliminates some of the problems that have developed recently with all TCP applications. (See my publications and other articles on the topic of bufferbloat.) When compared to TCP, UDP is very efficient. It has an 8 byte header whereas TCP has a 20 byte header.

To provide reliable delivery of video over the Internet, the following criteria are needed:

  • A negotiated set of transfer parameters understood by both the sender and the receiver.
  • Guaranteed delivery of the packets.
  • Flow control, to prevent overfilling network and receiver buffers.
  • Detection of network congestion and automatic adjustment of the sending rate to accommodate conditions of congestion.

TCP provides for all of these. That’s why ABR video is popular for services like Netflix and Hulu. However, having stated the positive attributes of TCP, recent research has revealed that it can be slow to adapt to congestion. Also, it can increase latency of the delivery by many times.

SRT emulates the best characteristics of TCP transport but uses UDP. So, let’s analyze its operation. First it uses a single UDP port. That makes it easy to observe and manage its flows with tools like Wireshark or other network management software. The IT department will appreciate this feature. It also makes firewall traversal rather simple. The two-way control packets report on network latency, loss and congestion conditions. This allows the source encoder to adjust the bandwidth or retransmit lost packets. Lost packets are kept to a minimum by using forward error correction (FEC). By default, TCP doesn’t include this capability. Consequently, it isn’t usually used in ABR video.

TCP detects lost data segments by using a sequence number that tracks the number of bytes sent and acknowledged. SRT uses a counter that rolls over every 256 segments, virtually assuring detection of lost segments. However, TCP’s retransmissions can be delayed. I’ve seen situations where the retransmitted segment was received after more than 400 requests for it were sent to the source. The problem is due to bufferbloat, as mentioned earlier.

There are some obvious advantages, when SRT is compared to IPTV. IPTV is very sensitive to lost packets. Even a loss rate of 0.25% can cause tiling on the viewer’s screen. So, IPTV is virtually out of the question for use over the Internet. Such streams must be converted to ABR or SRT for delivery. SRT can easily tolerate this loss rate or higher. Due to these advantages, SRT excels over RTSP/UDP, which is the most widely implemented configuration used by security cameras. RTSP/TCP is generally used for delivery to video storage. Finally, SRT is different than SDVoE and AVB video because both of those are designed only for LAN implementations. Neither is appropriate for delivery over the Internet.

In our next newsletter, we’ll discover how SRT compares to ABR video and other implementation from the IT community and study how it behaves on the network.

Featured Articles