0

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

Codegirl
  • 1
  • so, i know that quic can open separate data streams, but i do not know how this works with iperf or if there are any options of iperf to control how many streams are used. basic fairness would be iperf over tcp vs iperf over quic. Although you need to check that congestion control algorithms are the same. If quic manages to get more streams it should take more bandwidth. But this should be negated by starting several tcp streams (iperf should have an option to do this). Although when you get matching number of streams, this should measure fairness of congestion control, not quic – Effie Dec 28 '21 at 10:06
  • the second thing you can try is flow completion time, which you could probably do by loading small things with curl. Quic is supposed to have faster connection setup, so it should be faster. – Effie Dec 28 '21 at 10:07
  • next fairness parameter can be how fast new flow reaches its fair share of bandwidth. Here you could probably do iperf vs curl, or just start second iperf flow after the first one, and see when it reaches full bandwidth – Effie Dec 28 '21 at 10:08
  • another thing that i don't know is if security is optional in Quic. If you run quic with security and tcp without tls that should result in something less fair than it actually is. curl should use https, but i don't know if you can enforce ipref with tls. – Effie Dec 28 '21 at 10:10
  • Yeah I don´t know if iperf is such a good option with curl. But I think curl is the best option if I want to download a bunch of files but I don´t know how I can measure if Quic is fair when TCP and Quic should download parallel of the same page @Effie – Codegirl Dec 29 '21 at 18:02
  • With iperf 2, use iperf -n and -P. Also, compile from source using ./configure --enable-fastsampling iperf -c 192.168.1.66 -n 1M -P 3 -e --reverse --trip-times – rjmcmahon Dec 31 '21 at 20:12

1 Answers1

3

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.

Barry Pollard
  • 40,655
  • 7
  • 76
  • 92