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 huuuuuge 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