A paused HTTP/2 stream doesn't actually stop the data

[bagder]

I did this

Write an application that makes multiple HTTP/2 streams over the same connection. Return CURL_WRITEFUNC_PAUSE from the write callback when you want to pause a stream.

This only stops the data from being delivered to the application. libcurl will then instead just buffer all the incoming data in memory in an ever-growing realloc()ed buffer until the stream is again unpaused or shut down. This is not intended, expected or documented.

(Pausing a HTTP/2 transfer with curl_easy_pause() has in fact the exact same behavior.)

I expected the following

Data to stop flowing over the wire for the stream until we unpause the stream again.

curl/libcurl version

All

operating system

All

[bagder]

Here's 4939.c which reproduces the problem.

[jay]

Ref: https://curl.haxx.se/mail/lib-2020-02/0051.html

Can't we just make the window something more reasonable like 1MB or something?

[bagder]

Can't we just make the window something more reasonable like 1MB or something?

That would certainly make it a simpler fix. And yeah, maybe just do that for now and then possibly do something else in a future if users really need something more flexible.

[jay]

Since I posted that I found #1102 for the history of why we added the large window. I tried that example with NGHTTP2_INITIAL_WINDOW_SIZE, 1MB and 10MB.

time src/curl https://upload.wikimedia.org/wikipedia/commons/d/d6/Seattle_7.jpg -v >/dev/null

NGHTTP2_INITIAL_WINDOW_SIZE:
real 0m27.026s
user 0m0.328s
sys 0m0.848s

1MB:
real 0m6.774s
user 0m0.252s
sys 0m0.280s

10MB:
real 0m5.689s
user 0m0.240s
sys 0m0.400s

(1 << 30):
real 0m5.586s
user 0m0.220s
sys 0m0.488s

Repeated runs deviate by about a second.

Bandwidth and latency affect a lot and I wonder if whatever the alternative is if it's better to pursue that instead.

/cc @afrind

[afrind]

I don't know the curl or nghttp2 code, but I assume that when application pauses reading from a stream, curl stops releasing flow control for it. The peer is still allowed to send up to a full stream flow control window. There isn't a good way to revoke stream flow control credit that's already granted.

The purpose of the flow control window is to communicate to the peer the amount you are willing to buffer. Setting it to something smaller than BDP can throttle performance, but setting it too large can be bad too. I think 2^30 is probably higher than any reasonable BDP. Buffering 10MB per stream may not be realistic either depending on how many concurrent streams you use and how much memory you have.

[bagder]

I think the most sensible approach forward is to set this default value large enough to "basically never cause performance problems", probably meaning a value of like 32 MB.

This will also cause a paused transfer to potentially have to buffer up to 32MB, but I can't see any easy way out of that - other than introducing a new option for such specific applications (saved for another day). Of course we should also make CURLOPT_MAX_RECV_SPEED_LARGE affect the window size, but I will leave that too as a separate exercise.