Re: Stream limits draft posted

On Fri, Nov 10, 2023, at 14:16, Stefan Eissing wrote:
> +1
>
> I think clients will not wait for the MAX_STREAMS from the server. I 
> assume they want to send right away instead of waiting for a while. The 
> server might support it or not. How long are they willing to wait for 
> this?

In the meeting, it was suggested that we require clients to wait for SETTINGS before opening streams.  I think that is a good idea and entirely possible, without significant performance penalties.

In TLS 1.3, the server can send SETTINGS immediately, which means that the client only needs to read a few more bytes before it can start sending.

The minor pain here, as David Benjamin will likely remind us, is that it is a little awkward sending data from the server before seeing the client Finished.  So we'd probably want to experiment here.

We can also require that a client remember the value of the setting for use in 0-RTT.

For 0-RTT, we discussed the problem of which SETTING value to remember, because the value can be updated (thanks Alan for the reminder).  However, we could allow the client to remember any value, because the server will use MAX_STREAMS and therefore has no reason to send multiple values for MAX_CONCURRENT_STREAMS.

I think that this would be feasible for us to implement as a client.  It's a small performance degradation in TLS 1.2, so we might start with a small assumed value in that case, but most of our connections are TLS 1.3 now, so that might be manageable.  I don't have data about how many connections have HTTP/2 without TLS 1.3 offhand to help decide.  Both are independently the most common protocol version with similar amounts of usage.  We'd want to investigate those numbers to really decide what the impact would truly be.

Received on Saturday, 11 November 2023 07:51:20 UTC