is QUIC fair to TCP

Question

I have a question regarding TCP and QUIC. For a project I have to test how TCP fair is QUIC. My Setup are two Virtual Machines one with nginx Quic implementation and one where I use nginx TCP. I have to generate random Files and download them with TCP and QUIC running. For the File download it is said I can use curl which is no problem but to measure the fairness I thought about Iperf to get the throughput and bandwith and calculate with the Jains fairness Index the result. I don´t know if this is the best solution but I can´t really find something else and know I am wondering if I can measure with Iperf while downloading with curl or isn´t it making sense?

Sorry I am really new to this forum and to TCP and QUIC.

Thank you in advance

Answer 1

Whether QUIC is fair to TCP or not isn’t the real question. Both will be as fair as the congestion control algorithm controlling the throughput rather than anything inherent to either protocol.

TCP has traditionally used quite conservative congestion control algorithms that back off considerably at the slightest hint of packet loss under the (often incorrect) assumption that the packet loss is a result of reaching network capacity.

BBR was a new congestion control algorithm that treats models the network differently and so is not as reliant on packet loss as a congestion control signal. As a result it has received criticism of being “unfair”:

BBR version 1 (BBRv1) is efficient and fast, but its fairness to non-BBR streams is disputed. When implemented at YouTube, BBRv1 yielded an average of 4% higher network throughput and up to 14% in some countries. While Google's presentation shows BBRv1 co-existing well with CUBIC, researchers like Geoff Huston and Hock, Bless and Zitterbart finds it unfair to other streams and not scalable. Hock et al also found "some severe inherent issues such as increased queuing delays, unfairness, and massive packet loss" in the BBR implementation of Linux 4.9.

At present QUIC implementations have basically reimplemented TCP Congestion Control algorithms (including BBR) so any measure of fairness is simply a measure of those. Now QUIC does allow faster iteration of changes so could become more “unfair” by allowing easier deployment of another, more unfair, congestion control algorithm if/when that comes along but for now they are very similar to TCP. Additionally wouldn’t depend on any single implementation being representative of all of QUIC, not being finished and unlikely to change - all implementations are young and changing considerably as learning from QUIC are discovered and improved upon. A number of studies have been completed as to whether QUIC is faster and most have concluded that it varies by implementation more so than most other factors at the moment.