Should we provide QUIC support when it is done?

[K9A2]

As the title.

[bmah888]

We did think about this at one point, several years ago. At the time there wasn't a QUIC implementation that could be easily integrated into iperf3. It's not clear if that situation has improved, although there certainly appear to be more implementations nowadays.

One of the difficulties is that by design, all of the QUIC implementations exist in userspace, and there doesn't seem to be a standardized API analogous to the BSD socket layer to control QUIC connections. So iperf3 would needed to be coded to the API of a specific QUIC library or libraries, and the results that it obtained would be specific to those implementations.

iperf3 also runs on a fairly large number of platforms, with a minimal number of dependencies. Adding QUIC support is likely to complicate portability efforts.

That said we're not opposed in principle to the idea of having QUIC support in iperf3. We're willing to work with anybody in the community who might want to try implementing this. If someone's interested, please drop me a note before doing any significant work...this is likely to be a large effort that could have some architectural impact on iperf3.

[K9A2]

Yep, I agree with you. When the QUIC spec is finalized, the may be opporunity to integrate it in iperf3. Wait and see.

[ericcurtin]

There's a fairly portable QUIC implementation now that the likes of curl uses https://github.com/ngtcp2/ngtcp2

[pkropachev]

Is there a chance to back to the idea of implementing the QUIC protocol in iperf3?

It looks like OpenSSL v3.5.0 offers APIs for integration with ngtcp2. See ngtcp2/ngtcp2#1582, so it can be built with official OpenSSL version.

[davidBar-On]

Is there a chance to back to the idea of implementing the QUIC protocol in iperf3?

To better understand this request (at least for my information, as I am not from the iperf3 maintenance team):

1. My understanding is that QUIC is a layer 4 protocol running over UDP. What is the added advantage of testing QUIC directly compared to testing UDP performance?
2. If iperf3 will support QUIC, what specific options should be added or how existing options should be used for QUICK? E.g. I assume that -P (number of parallel streams) may have special meaning, encryption related parameters should be added or handled specifically for QUIC, etc.

[pkropachev]

1. All key advantage of testing QUIC directly based on QUIC specifics:

• Stream multiplexing: QUIC can handle multiple independent streams of data within a single connection. A direct QUIC test can measure the efficiency of this multiplexing and impacting application-level throughput.
• Security: QUIC has built-in encryption (TLS 1.3). Simple UDP testing would not account for this.
• Congestion control: QUIC implements its own mechanisms to manage network congestion, similar to TCP. Testing QUIC allows for the analysis of the performance and behavior of these congestion control algorithms (under different network conditions).
• Reliable delivery: QUIC provides reliable data transfer with mechanisms for packet numbering and acknowledgments to ensure data arrives correctly. This is one of the fundamental differences from UDP.
• Connection: QUIC provides efficient connection establishment process, e.g. 0-RTT. Testing QUIC connection establishment can measure latency benfits of QUIC.

Another question is which QUIC implementation should be used in iperf3. Each implementation suggests its own CC implementations, API, supported TLS backend, etc.

2. This is discussable. I'm afraid proper support QUIC will require quite a lot of additional options: QUIC version, choose Congestion control algorithm (Cubic, BBR), enabling 0-RTT handshakes, some options to work with streams.

[davidBar-On]

@pkropachev thanks for the explanations.

I evaluated adding QUIC to iperf3, at least as a prototype, but it seems the main problems in @bmah888 mentioned in 2020 still exist. On the other hand, there was a progress, so it seems that one of the following two approaches may be taken:

1. As mentioned in Linux QUIC for the kernel, on July a Linux patch introduce QUIC infrastructure and core subcomponents was added. Therefore, it may be that QUIC support will be available in most Linux distributions quite soon (I have no idea what soon means here ...). It might be that the right approach is to wait until that will happen.
2. The other approach is to use one of the available QUICK libraries. It seems that msquic may be the right choice as it is available for all the main OSs and supports OpenSS. The main problem is that it seems that a pre-built library is not be available for many Linux and other OSs distributions (e.g. it is not available for my WSL Ubuntu), and I am not sure how practical it is to build a such library as part of building iperf3.

[pkropachev]

@davidBar-On, thanks for this investigation!

1. I'm afraid adding QUIC to the Linux kernel won't be fast. Perhaps make sense to consider using one of the libraries that implements QUIC protocol.
2. Currenrly curl project uses ngtcp2 (+nghttp3) as main library for QUIC (HTTP3), other libraries are supported in experimental mode. ngtcp2 supports a lot of SSL backends. I suppose it will be difficult to find QUIC projects that provide pre-built libraries for many OS distibutives. libcurl is built for many OS, so perhaps it can be solved.

@tatsuhiro-t, could you please share if there are some specifics of using ngtcp2 on different systems?

[tatsuhiro-t]

libngtcp2 itself does not depend on any third-party libraries. I think you can compile it on many systems just fine. It is also packaged in some distributions as well, although the version may be a bit skewed. libngtcp2_crypto helper library, which helps integrating ngtcp2 with the particular supported TLS stack, depends on TLS stack, but it is inevitable on its own nature, and you will find the supported TLS stack on most of the systems.

[davidBar-On]

@pkropachev I will try adding QUIC support to iperf3 using ngtcp2 library. My understanding is that the crypto library used by iperf3 and ngtcp2 are unrelated, so initially I will build ngtcp2 with BoringSSL. My current approach is:

1. Use QUIC without HTTP support, i.e. without using nghttp3 as curl does. I believe that for the network performance tests this is the right approach. (Note that the iperf3 udp/tcp tests are also not using encryption, but encryption is part of QUIC that cannot be removed.)
2. Use the iperf3 --parallel option to define number of connections, and not support multiple streams per connection. The reason is that this seems to suit better the current iperf3 design, especially because each connection can to be supported by a different thread. Multiple streams per connection may be added later.

Is that sound reasonable? (Note that I am not sure when I will have at least an initial version of the implementation - depends on my available time ...)

[bmah888]

While this sounds like interesting functionality to have (and I've thought so for years), I'm very concerned about the maintenance load involved in adopting a major new feature like this. (And I do consider adding a new protocol, whose implementation has a completely different API from any of the existing transport protocols supported by iperf3, to be a major feature.)

iperf3 already has way too many features and options, and figuring out the interactions between those and this QUIC implementation will be non-trivial. I'm reluctant to add a lot of new functionality to iperf3 at this point in its lifecycle...while the small iperf3 maintenance team is grateful for code contributions, we're the ones left supporting that new code and in the end adding new features actually makes our job harder.

I don't mean to discourage anyone from looking into this, but I do want to express that it's actually very hard to add new features to iperf3 at this point, and to set expectations accordingly. Thanks to all for your understanding...