It has never been a trivial task to get video over IP networks. The need to move text data brought about IP networks. However, when voice was successfully and efficiently moved over these networks, engineers began to question whether video could also be transported on them. Video conferencing and IPTV were built on the concept that, if the network was not prone to loss, IP using UDP (User Datagram Protocol) could effectively deliver video. Vidyo demonstrated that the Internet could transport video conferencing if scalable video coding was used at the source. However, things really changed when Netflix began streaming video. They used HTTP/TCP, which is similar to nearly all other web applications. Broadcasters and streaming server manufacturers began to use the method, now called adaptive bit rate (ABR).
Despite this, TCP has not kept up with changes in network technology as well as we would expect. Around 2010, Jim Gettys, then at Bell Labs, discovered that TCP performance was suffering from its inability to deal with large buffers in the network. TCP detects congestion by observing lost packets. It modifies its sending rate by lowering the rate. However, these large buffers indicate that TCP is slow to adjust and can occasionally drop the sending rate too severely. So, is the answer not to use TCP? Not necessarily. Seeing that the only other choice is UDP which is very sensitive to loss, transport over the Internet continues to be a problem.
Two new approaches have been suggested to deal with this dilemma. One comes from the IT industry; the other is offered within the AV industry. The first comes from Google. Their TCP BBR (bandwidth bottleneck & RTT) uses the idea that congestion can be detected by continually estimating the delivery rate of the flow. Their experiments have shown that TCP BBR provides about the same throughput as traditional TCP but with much lower latency. It will be implemented at the streaming server and will require that the client be TCP BBR aware. If the client is not using the protocol, it will perform as a traditional client. That is, the benefits of TCP BBR will not be realized.
The second new direction has been proposed by Haivison and Wowza and is being promoted through the group they’ve orgqnized called the SRT Alliance. Several dozen manufacturers have joined the alliance and are committed to support SRT protocol. SRT (Secure Reliable Transport) is based on UDP. So, it avoids the issues that have developed with TCP. It also has lower overhead than TCP. Combining Fast File Transfer with UDP retransmissions and control messages means that it appear to be like TCP. That is, it is a reliable protocol, virtually assuring delivery of the video. It can also adapt to bandwidth fluctuations.
Both new approaches seem technically solid. However, both need more field testing in order to face the real problems of the Internet. For example, how will each share bandwidth with other traffic such as data oriented cloud file transfers, routine business traffic in VPN tunnels, and adaptive bit rate streams? While these things can be difficult to simulate in the lab, they are not impossible. I believe such testing should be conducted and the test results made available to users. In the near future the IT community may require this testing before adopting of these protocols.
