In this second newsletter about Secure Reliable Transport (SRT), we’ll examine its impact on an IP network. Then, we’ll compare that to the behavior to the activity of adaptive bit rate (ABR), another video transport.
First let’s recall the characteristics of SRT:
- negotiates a “session” in a manner similar to TCP.
- guarantees delivery of the packets.
- detects congestion in the network and adapts to it.
- provides flow control.
By analyzing an SRT packet flow with Wireshark, you can learn a great deal. If you build a graph of the total bandwidth used by the flow, the utilization is almost constant. Figure 1 shows the utilization is nearly constant at 5Mb/sec for a video that plays at 4 Mb/sec. On average the packets are sent at about one-half millisecond intervals. We found that 62% of the packets were 1374 bytes in length indicating that mpeg transport (MPTS) was being used. That is the format used in most other video transport methods. MPTS usually fills an IP packet with 1316 bytes of audio, video and metadata. Of that, 28 bytes are MPTS headers. By our calculation, on average about 20% of the transmitted bytes were Ethernet, IP, UDP, SRT headers and SRT control packets.
Now, let’s look at the behavior of ABR video on the network. ABR is the method used by Adobe HDS, Apple HLS, Microsoft Smooth Streaming, and DASH. Netflix uses ABR and Figure 2 shows a graph of the bandwidth used. Such ABR traffic uses TCP as the transport protocol. So, we expect to see different behavior than SRT, which uses UDP. And, indeed, we do see something quite different.
First, the flow shows the utilization during the authentication process as lasting for six seconds. Then, it takes about 12 seconds until the flow reaches the relatively constant level of about 20 Mb/sec. This is the full bandwidth of this DSL downstream connection. But, as soon as the receiver’s buffer is saturated, at about 28 seconds, the transmission becomes very bursty. Chunks of video are transported approximately every four seconds.
This difference in behavior may seem like a curiosity. However, it is more than that. The bursty nature of TCP applications has been the focus of a significant amount of recent research. The problem arises when other traffic is present on the same path, especially if it is a TCP flow in the opposite direction. The rate of TCP transmission is dependent on several factors, but the most significant of these is the rate at which the sender receives acknowledgement packets from the receiver. So, suppose the ABR traffic is going to a user who has available 20 Mb/sec downstream and 2 Mb/sec upstream, a common DSL configuration. He will be able to receive an ABR flow intended to play at 5Mb/sec. However, suppose the user, or someone else in the home, decides to upload a video to YouTube, saturating the upstream 2Mb/sec connection. This will delay the acknowledgements to the ABR flow and the video chunks being delivered every four seconds could take more than 4 seconds to deliver. This will result in a video pause. In some of my own experiments with this, I’ve seen such an upload make the downstream throughput drop by more than 50% and last as long as the upload is continued.
We don’t know if SRT will be subject to this effect or not. It uses a form of acknowledgement so it might be affected in this way. This phenomenon I’ve described is further aggravated by wireless connections which is due to the fact that they can delay the acknowledgements more than wired connections do. It is something the SRT Alliance should investigate and be prepared to explain and mitigate.