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: [EXTERNAL] 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: Wed, 11 Jan 2023 19:33:12 +0000
> But also, doing such "background buffering" is going to be difficult for QUIC backends unless they introduce threads for that purpose,
> and if they do they get new thread-related challenges instead.
I think they will have to use threads at the end and provide " background buffering" similar to what kernel does for TCP.
Otherwise, it will be difficult for H3/QUIC to match H1,H2/TCP performance for large downloads using these backends if there are some delays in incoming data processing
and client can't call "perform" frequently enough to avoid QUIC backends pausing their sending.
Threads have to be used for the "background buffering", it is just a question "where?".
For TCP, it is kernel, which makes client life much easier, for QUIC, it is still an open question.
It can be either in some QUIC library or in the end client using that library.
I think QUIC library is the right place where to put such functionality, but obviously it will increase library complexity and I understand why QUIC library creators currently don't want to deal with it.
And it is good, that msh3 provides the "background buffering" capabilities, so hopefully ngtcp and quiche will follow and provide it in the future.
Hopefully, as H3/QUIC progresses, each QUIC backend will provide "background buffering", with an option(s) to tune it, and it will be easy for libcurl to use it.
> Performance is not going to be a focus in the work of removing the experimental label,
> but we should of course always keep an eye on that and make sure that we keep polishing the internals to make curl transfer data as fast as we can.
Sure, understood. There are a lot of things to be done in H3 to make it work better, and the best possible performance is probably not on top on the list at this point.
But as people start using H3 more and more in production scenarios, the question of its performance will inevitably pop up.
Thanks,
Dmitry Karpov
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Tuesday, January 10, 2023 11:23 PM
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 Tue, 10 Jan 2023, Dmitry Karpov via curl-library wrote:
> 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.
I'm not convinced this design difference is going to be important in the end but I don't have any data or proof to back that up. But also, doing such "background buffering" is going to be difficult for QUIC backends unless they introduce threads for that purpose, and if they do they get new thread-related challenges instead. Which the best design is for performant h3 client-side transfers, I cannot tell.
As I don't plan on writing my own quic/h3 library we are left using the ones that exist, however their APIs work.
I believe msh3 works similar to the way you describe while quiche and ngcpt2 do not.
> And as H3 in libcurl is moving toward production-ready state, it is
> something to think about.
Performance is not going to be a focus in the work of removing the experimental label, but we should of course always keep an eye on that and make sure that we keep polishing the internals to make curl transfer data as fast as we can.
Date: Wed, 11 Jan 2023 19:33:12 +0000
> But also, doing such "background buffering" is going to be difficult for QUIC backends unless they introduce threads for that purpose,
> and if they do they get new thread-related challenges instead.
I think they will have to use threads at the end and provide " background buffering" similar to what kernel does for TCP.
Otherwise, it will be difficult for H3/QUIC to match H1,H2/TCP performance for large downloads using these backends if there are some delays in incoming data processing
and client can't call "perform" frequently enough to avoid QUIC backends pausing their sending.
Threads have to be used for the "background buffering", it is just a question "where?".
For TCP, it is kernel, which makes client life much easier, for QUIC, it is still an open question.
It can be either in some QUIC library or in the end client using that library.
I think QUIC library is the right place where to put such functionality, but obviously it will increase library complexity and I understand why QUIC library creators currently don't want to deal with it.
And it is good, that msh3 provides the "background buffering" capabilities, so hopefully ngtcp and quiche will follow and provide it in the future.
Hopefully, as H3/QUIC progresses, each QUIC backend will provide "background buffering", with an option(s) to tune it, and it will be easy for libcurl to use it.
> Performance is not going to be a focus in the work of removing the experimental label,
> but we should of course always keep an eye on that and make sure that we keep polishing the internals to make curl transfer data as fast as we can.
Sure, understood. There are a lot of things to be done in H3 to make it work better, and the best possible performance is probably not on top on the list at this point.
But as people start using H3 more and more in production scenarios, the question of its performance will inevitably pop up.
Thanks,
Dmitry Karpov
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Tuesday, January 10, 2023 11:23 PM
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 Tue, 10 Jan 2023, Dmitry Karpov via curl-library wrote:
> 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.
I'm not convinced this design difference is going to be important in the end but I don't have any data or proof to back that up. But also, doing such "background buffering" is going to be difficult for QUIC backends unless they introduce threads for that purpose, and if they do they get new thread-related challenges instead. Which the best design is for performant h3 client-side transfers, I cannot tell.
As I don't plan on writing my own quic/h3 library we are left using the ones that exist, however their APIs work.
I believe msh3 works similar to the way you describe while quiche and ngcpt2 do not.
> And as H3 in libcurl is moving toward production-ready state, it is
> something to think about.
Performance is not going to be a focus in the work of removing the experimental label, but we should of course always keep an eye on that and make sure that we keep polishing the internals to make curl transfer data as fast as we can.
-- / 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-11