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
Received on 2020-02-21