Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
H3/QUIC flow control/buffering problem and suggestion
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 6 Jan 2023 20:28:51 +0000
Hi All,
As H3 in libcurl is going steadily to the production feature, I would like to tell about one H3/QUIC issue, which was OK for the experimental stage, but probably needs to be addressed to make H3 a full production feature.
When I was comparing H3/QUIC with the H1/H2 TCP in my local network setup, I noticed that H3 download speed was unexpectedly much slower compared to H1/H2.
After looking into the issue, I figured out that UDP socket options setting socket receive buffer (1MB in my case) didn't affect QUIC performance for H3 as they did for TCP used by H1/H2 because QUIC protocol is implemented in user space (by ngtcp2 and other QUIC backends) vs TCP in kernel,
and its flow-control options are not affected by UDP socket receive buffer size.
On the other hand, for TCP, socket receive buffer size also specifies flow-control option, like max TCP window size (which allows to reach better download speeds for large downloads when it is increased).
So, QUIC as user-space transport layer, requires its own receive buffering and flow-control setup (similar to TCP receive buffer) in order to match TCP buffering/flow-control capabilities provided by socket options.
(I found an interesting discussion about this subject: https://github.com/ngtcp2/nghttp3/issues/20)
Because libcurl controls H3 QUIC flow-control options via CURLOPT_BUFFERSIZE option, I was able to reach for H3 the same speed as for H1/H2 with 1MB socket receive buffer size
by doing the following steps:
- Increased CURL_MAX_READ_SIZE to 1MB (required libcurl re-build)
- set CURLOPT_BUFFERSIZE option to 1MB for H3 transfers.
Obviously, such steps are not for production use, and "production ready" H3 feature should provide a better and easier way to optimize H3 buffer/flow control settings for client apps.
So, I suggest to provide a new "QUIC" option (similar to the "TCP" options that we already have):
CURLOPT_QUIC_BUFFERSIZE
which will do similar steps that I did but in just one option setting call and without the need to modify libcurl for each desired buffer size.
Thanks,
Dmitry Karpov
Date: Fri, 6 Jan 2023 20:28:51 +0000
Hi All,
As H3 in libcurl is going steadily to the production feature, I would like to tell about one H3/QUIC issue, which was OK for the experimental stage, but probably needs to be addressed to make H3 a full production feature.
When I was comparing H3/QUIC with the H1/H2 TCP in my local network setup, I noticed that H3 download speed was unexpectedly much slower compared to H1/H2.
After looking into the issue, I figured out that UDP socket options setting socket receive buffer (1MB in my case) didn't affect QUIC performance for H3 as they did for TCP used by H1/H2 because QUIC protocol is implemented in user space (by ngtcp2 and other QUIC backends) vs TCP in kernel,
and its flow-control options are not affected by UDP socket receive buffer size.
On the other hand, for TCP, socket receive buffer size also specifies flow-control option, like max TCP window size (which allows to reach better download speeds for large downloads when it is increased).
So, QUIC as user-space transport layer, requires its own receive buffering and flow-control setup (similar to TCP receive buffer) in order to match TCP buffering/flow-control capabilities provided by socket options.
(I found an interesting discussion about this subject: https://github.com/ngtcp2/nghttp3/issues/20)
Because libcurl controls H3 QUIC flow-control options via CURLOPT_BUFFERSIZE option, I was able to reach for H3 the same speed as for H1/H2 with 1MB socket receive buffer size
by doing the following steps:
- Increased CURL_MAX_READ_SIZE to 1MB (required libcurl re-build)
- set CURLOPT_BUFFERSIZE option to 1MB for H3 transfers.
Obviously, such steps are not for production use, and "production ready" H3 feature should provide a better and easier way to optimize H3 buffer/flow control settings for client apps.
So, I suggest to provide a new "QUIC" option (similar to the "TCP" options that we already have):
CURLOPT_QUIC_BUFFERSIZE
which will do similar steps that I did but in just one option setting call and without the need to modify libcurl for each desired buffer size.
Thanks,
Dmitry Karpov
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-01-06