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.
Re: 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: Tue, 10 Jan 2023 21:42:13 +0000
> The write callback only delivers up to CURL_MAX_WRITE_SIZE bytes per invocation, and that means 16kB.
Yes, you are right! It can be less than CURL_MAX_WRITE_SIZE, but not more.
> Not really. It limits how much data libcurl can accumulate before it calls the application though. For multiplexing protocols it might be worth having them a little larger just because how libcurl might need to have to > "fill up" data for many concurrent transfers before the application gets a chance to "drain"
> each transfer's buffers.
I guess in the essence it means how much data libcurl tries to read from the underlying transport layer and store in the read buffer before it calls the application.
> Sure, but we need a lot more than just a proposed name to get such functionality in place. Perhaps even such a new buffering system could be done and used without even introducing a new option...
For H1/H2 over TCP such a buffering system already exists - TCP stack in kernel provides such buffering, which is controlled via recv buffer size socket option, and it is independent from the libcurl internal read buffering controlled by the CURLOPT_BUFFERSIZE.
And TCP buffering system works in background - it accumulates incoming data in its internal buffer regardless of whether the client reads it or not.
H3 currently doesn't provide such "background buffering" option and increasing CURLOPT_BUFFERSIZE to TCP receive buffer size currently is the only way to match H1/H2 performance, but only if libcurl H3 client reads data without delays.
Any delays caused by data processing causing pauses between "perform" calls (where libcurl tries to fill up its read buffer) will negatively affect H3 performance if used QUIC backend doesn't provide the "background buffering" option similar to TCP stack.
On the other hand, H1/H2 with big socket receive buffers are not affected by such delays.
It would be great if all QUIC backends implemented such functionality and provided API to tune it.
Otherwise, we would need to implement such "background buffering" in libcurl code wrapping that backend to match TCP "background" performance which H1/H2 have.
And yes, this "background buffering" system in libcurl for QUIC backends that don't have it will be something new, but I don't think that we can avoid a new option(or even options) here.
Like with TCP tuning and socket options, we would need to provide a set of options to tune up QUIC as a transport protocol.
I think that provision for "background buffering" in QUIC backends or libcurl is very important to make H3/QUIC truly competitive with H1/H2.
And as H3 in libcurl is moving toward production-ready state, it is something to think about.
Thanks,
Dmitry Karpov
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Tuesday, January 10, 2023 12:02 AM
To: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Cc: Dmitry Karpov <dkarpov_at_roku.com>
Subject: [EXTERNAL] Re: H3/QUIC flow control/buffering problem and suggestion
On Mon, 9 Jan 2023, Dmitry Karpov via curl-library wrote:
> Exactly! That's why I proposed to use a new "CURLOPT_QUIC_BUFFERSIZE"
> option for that purpose. This option would control QUIC buffering for
> different backends separating it from the CURLOPT_BUFFERSIZE option,
> which is currently used for limiting the max amount of data to be sent
> in the "write callbacks".
The write callback only delivers up to CURL_MAX_WRITE_SIZE bytes per invocation, and that means 16kB.
> That's right. But the CURLOPT_BUFFERSIZE currently just limits how
> much data Curl sends to the "write callbacks",
Not really. It limits how much data libcurl can accumulate before it calls the application though. For multiplexing protocols it might be worth having them a little larger just because how libcurl might need to have to "fill up" data for many concurrent transfers before the application gets a chance to "drain"
each transfer's buffers.
> Right, I am talking about two separate "buffering" systems - transport
> layer internal buffering (socket buffer etc.) and Curl's reading
> buffering. In the essence, Curl's reading buffering is an intermediate
> layer between transport layer and the end client.
Sure, but we need a lot more than just a proposed name to get such functionality in place. Perhaps even such a new buffering system could be done and used without even introducing a new option...
Date: Tue, 10 Jan 2023 21:42:13 +0000
> The write callback only delivers up to CURL_MAX_WRITE_SIZE bytes per invocation, and that means 16kB.
Yes, you are right! It can be less than CURL_MAX_WRITE_SIZE, but not more.
> Not really. It limits how much data libcurl can accumulate before it calls the application though. For multiplexing protocols it might be worth having them a little larger just because how libcurl might need to have to > "fill up" data for many concurrent transfers before the application gets a chance to "drain"
> each transfer's buffers.
I guess in the essence it means how much data libcurl tries to read from the underlying transport layer and store in the read buffer before it calls the application.
> Sure, but we need a lot more than just a proposed name to get such functionality in place. Perhaps even such a new buffering system could be done and used without even introducing a new option...
For H1/H2 over TCP such a buffering system already exists - TCP stack in kernel provides such buffering, which is controlled via recv buffer size socket option, and it is independent from the libcurl internal read buffering controlled by the CURLOPT_BUFFERSIZE.
And TCP buffering system works in background - it accumulates incoming data in its internal buffer regardless of whether the client reads it or not.
H3 currently doesn't provide such "background buffering" option and increasing CURLOPT_BUFFERSIZE to TCP receive buffer size currently is the only way to match H1/H2 performance, but only if libcurl H3 client reads data without delays.
Any delays caused by data processing causing pauses between "perform" calls (where libcurl tries to fill up its read buffer) will negatively affect H3 performance if used QUIC backend doesn't provide the "background buffering" option similar to TCP stack.
On the other hand, H1/H2 with big socket receive buffers are not affected by such delays.
It would be great if all QUIC backends implemented such functionality and provided API to tune it.
Otherwise, we would need to implement such "background buffering" in libcurl code wrapping that backend to match TCP "background" performance which H1/H2 have.
And yes, this "background buffering" system in libcurl for QUIC backends that don't have it will be something new, but I don't think that we can avoid a new option(or even options) here.
Like with TCP tuning and socket options, we would need to provide a set of options to tune up QUIC as a transport protocol.
I think that provision for "background buffering" in QUIC backends or libcurl is very important to make H3/QUIC truly competitive with H1/H2.
And as H3 in libcurl is moving toward production-ready state, it is something to think about.
Thanks,
Dmitry Karpov
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Tuesday, January 10, 2023 12:02 AM
To: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Cc: Dmitry Karpov <dkarpov_at_roku.com>
Subject: [EXTERNAL] Re: H3/QUIC flow control/buffering problem and suggestion
On Mon, 9 Jan 2023, Dmitry Karpov via curl-library wrote:
> Exactly! That's why I proposed to use a new "CURLOPT_QUIC_BUFFERSIZE"
> option for that purpose. This option would control QUIC buffering for
> different backends separating it from the CURLOPT_BUFFERSIZE option,
> which is currently used for limiting the max amount of data to be sent
> in the "write callbacks".
The write callback only delivers up to CURL_MAX_WRITE_SIZE bytes per invocation, and that means 16kB.
> That's right. But the CURLOPT_BUFFERSIZE currently just limits how
> much data Curl sends to the "write callbacks",
Not really. It limits how much data libcurl can accumulate before it calls the application though. For multiplexing protocols it might be worth having them a little larger just because how libcurl might need to have to "fill up" data for many concurrent transfers before the application gets a chance to "drain"
each transfer's buffers.
> Right, I am talking about two separate "buffering" systems - transport
> layer internal buffering (socket buffer etc.) and Curl's reading
> buffering. In the essence, Curl's reading buffering is an intermediate
> layer between transport layer and the end client.
Sure, but we need a lot more than just a proposed name to get such functionality in place. Perhaps even such a new buffering system could be done and used without even introducing a new option...
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-01-10