Re: a HTTP/2 window sizing dilemma!
On Fri, 21 Feb 2020, Daniel Jeliński via curl-library wrote: Well then, I'd vote in favor of not allowing pause when CURLMOPT_PIPELINING is set to anything other than CURLPIPE_NOTHING. I'm not a fan of changes that may negatively impact performance, as you may guess. And I never used pause anyway. I think that would be a weird limitation and besides, I'm doing this work right now exactly because I have an user with an application that does this and needs to pause... -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/--- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: a HTTP/2 window sizing dilemma!
Well then, I'd vote in favor of not allowing pause when CURLMOPT_PIPELINING is set to anything other than CURLPIPE_NOTHING. I'm not a fan of changes that may negatively impact performance, as you may guess. And I never used pause anyway. Regards, Daniel --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: a HTTP/2 window sizing dilemma!
On Fri, 21 Feb 2020, Daniel Jeliński via curl-library wrote: Sounds like the problem HPN-SSH tried to solve: https://www.psc.edu/index.php/hpn-ssh/638 I like their approach, but I'm not sure how they got hold of the current TCP receive window size; the only value I could find was receive buffer size, which is not necessarily relevant here. Also, it's not necessarily so that a user wants to buffer as much as the TCP window can get increased to anyway, depending on their situation - imagine for example a program running in a small device that transfers a lot of streams that can be paused. And then of course HTTP/2 is multiplexed so there could be a separate high speed stream flying by when one stream is paused, and then the TCP window needs to be really big for the fast stream... If you decide to go with a static value, the default max TCP window size on most machines is 32MB or less, and it is enough to saturate 1GBit link on the longest wired network (300 ms RTT, according to https://wondernetwork.com/pings). That's indeed a sensible argument. Which then also implies that every stream that gets paused might end up with up to 32MB of buffered data in memory... Other than that, I'd love to know who is using curlopt_pause and how; as far as I can tell, handling pause is only a problem on multiplexed connections where we can't let the data rest in system buffers. Correct? Correct! -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/--- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: a HTTP/2 window sizing dilemma!
Sounds like the problem HPN-SSH tried to solve: https://www.psc.edu/index.php/hpn-ssh/638 I like their approach, but I'm not sure how they got hold of the current TCP receive window size; the only value I could find was receive buffer size, which is not necessarily relevant here. If you decide to go with a static value, the default max TCP window size on most machines is 32MB or less, and it is enough to saturate 1GBit link on the longest wired network (300 ms RTT, according to https://wondernetwork.com/pings). Other than that, I'd love to know who is using curlopt_pause and how; as far as I can tell, handling pause is only a problem on multiplexed connections where we can't let the data rest in system buffers. Correct? Regards, Daniel pt., 21 lut 2020 o 08:28 Daniel Stenberg via curl-library napisał(a): > > On Thu, 20 Feb 2020, Daniel Stenberg via curl-library wrote: > > > But even so, the buffer size might very well be set to smaller sizes than > > you'd want the HTTP/2 window size to be. Can we avoid a new option for > > window size without having users suffer? > > Jay brought the suggestion [1] that we could just have it set fixed to (the > much more sensible) 1MB as a middle ground - and I like the simplicity of > that... > > [1] https://github.com/curl/curl/issues/4939#issuecomment-589383895 > > -- > > / daniel.haxx.se | Commercial curl support up to 24x7 is available! >| Private help, bug fixes, support, ports, new features >| https://www.wolfssl.com/contact/ > --- > Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library > Etiquette: https://curl.haxx.se/mail/etiquette.html --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: a HTTP/2 window sizing dilemma!
On Thu, 20 Feb 2020, Daniel Stenberg via curl-library wrote: But even so, the buffer size might very well be set to smaller sizes than you'd want the HTTP/2 window size to be. Can we avoid a new option for window size without having users suffer? Jay brought the suggestion [1] that we could just have it set fixed to (the much more sensible) 1MB as a middle ground - and I like the simplicity of that... [1] https://github.com/curl/curl/issues/4939#issuecomment-589383895 -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
a HTTP/2 window sizing dilemma!
Hello team! I'm currently working on issue #4939. It made me run into a little issue with how we do the HTTP/2 window sizing and I've realized we need to change our ways. # What the window means The announced window size is the amount of data we tell the other side it can send do us and that we can handle it. # What we do now We set the window *extremely* large (1 GB) to basically switch off its functionality and let the server cram over as much data it possibly can. # A side effect We don't deal with paused HTTP/2 streams correctly, we found out. When such a transfer is paused (which my PR in progress does), we zero the HTTP/2 window fine but since we already advertized 1GB "availability", the other side might still go on and send us that gigabyte and libcurl will then buffer all of that in a huge realloced buffer until the stream actually pauses (since the app has asked for the transfer to be paused libcurl won't call the write callback again until unpaused). Not ideal. Not at all. # Changing the HTTP/2 window size I want to figure out a better default window size which then at pause time will drastically reduce the amount of memory libcurl might need to buffer for this to work. Right now, I'm working with setting the window size to the same value as the buffer size, as applications already are already in control of that and if you download from for example localhost or very nearby servers applications might already have that value somewhat increased from the default 16K. But even so, the buffer size might very well be set to smaller sizes than you'd want the HTTP/2 window size to be. Can we avoid a new option for window size without having users suffer? The other side of the connection can only send a window-full amount of data until it gets increased in a returning packet, so with a 16K window we limit the transfer speed to 16K per RTT. At 100ms distance, that's 160K/second. Pretty lousy. With a 100K window at a 1ms distance we can get 100M/second but at a 100ms distance it's only 1M/second... I would imagine that users who intends and wants to occasionally pause HTTP/2 transfers might want a fairly small window to avoid a lot of buffering. But users who never intends to pause could still rather stick with 1GB and never have the server pause because it thinks the other end can't take more... # A new setopt option? I'm against the idea of new setopts as much as anyone else. But can we avoid this? #4939 = https://github.com/curl/curl/issues/4939 -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
