Your browser is out-of-date!

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


Phil Hippensteel on SRT Compared to QUIC

This will be our final newsletter to focus on Secure Reliable Protocol (SRT). We’ll investigate how it compares to QUIC (Quick UDP Internet Connections). You will recall that in our last two newsletters we learned that SRT is a protocol developed to deliver video over unreliable networks such as the Internet. It uses UDP, which is considered unreliable, as the transport protocol. However, it simulates TCP, which is a more reliable method of delivering video, by including several of TCP’s features. QUIC, a new protocol from Google, also uses UDP and likewise includes features which assure more reliable delivery. Google claims QUIC is more efficient than TCP in many aspects. They also make it the default method of downloading videos from YouTube, a Google owned service, when you are using Google’s Chrome browser. However, a quick test of accessing YouTube with Microsoft Edge reveals that standard HTTP/TCP is used. A recent study revealed that QUIC by now accounts for more than 5% of all Internet traffic.

The objectives of QUIC include:

  • security equivalent to TLS/SSL
  • reduced latency
  • bandwidth estimation
  • quick session establishment
  • quick security association development

These features are very similar to SRT. In the last newsletter, we observed that SRT detects the available bandwidth and uses the amount needed to deliver the video at the selected rate required to play out. For example, if the video is to play at 4 Mb/sec, SRT will deliver the video at approximately 5 Mb/sec, adding some overhead for packet headers and control traffic. The rate of the delivery to the network is relatively uniform, not bursty.

Now, let’s look closely at QUIC. The figure below is a graph of QUIC’s bandwidth utilization when a video is downloaded over a 20Mb/sec DSL connection.

As the figure clearly shows, QUIC is very bursty in nature. It sends bursts of packets spaced approximately 8 seconds apart for about one minute. Then, it sends similar bursts of packets at intervals of about 20 seconds. The first portion is likely intended to fill the player’s buffer. The second phase is probably at a level which will keep the buffer partly filled. Because the traffic is encrypted, it is impossible to determine the exact packet structure. However, it likely that mpeg transport is being used, since the packets are consistently 1392 bytes in length.

QUIC may be rather unfriendly when mixed with other traffic, especially if that traffic is TCP based. For example, if the path of the QUIC flow is shared with a standard FTP transfer, the QUIC bursts will make it difficult for the TCP algorithm, which is used by the file transfer, to adjust to the remaining available bandwidth. QUIC also is likely to cause the network buffers to overfill. This often leads to packets being dropped from TCP flows. As we’ve discussed in other newsletters, this is a cause of retransmitted packets.

QUIC may be an effective protocol for Google browser to retrieve videos from YouTube. Despite this, there remains a significant amount of research and testing to be finished before it can be endorsed as a widely used video transport method.

Featured Articles