Re: Stream limits draft posted

> Am 08.11.2023 um 10:00 schrieb Kazuho Oku <kazuhooku@gmail.com>:
> 
> 2023年11月6日(月) 16:04 Martin Thomson <mt@lowentropy.net>:
> https://datatracker.ietf.org/doc/html/draft-thomson-httpbis-h2-stream-limits-00
> 
> We've talked about this, but Lucas and I have scrubbed it a little.
> 
> This is not a proposal that comes with a statement of "this fixes the problem", so the discussion we have about this will be very important.  But if some servers benefit from doing things this way and clients are willing to implement, then it might be worth doing.
> 
> Thank you for publishing the draft.
> 
> If the problem can be addressed by changing the specification, then that would be great!
> 
> Regarding how, I have two comments to the current state of the draft.
> 
> One is that the current approach does not provide a hard limit on the number of streams that can be opened; this is because until SETTINGS are exchanged, clients can open any number of streams. As said previously [1], IMO it would make sense to state that endpoints implementing this extension MUST NOT open a hard-coded number of streams until it negotiates the use of the new scheme.

+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?

It seems therefore safe to assume that clients will send SETTINGS+MAX_STREAMS+HEADERS(n times). And what is the `n` that is safe here?

On the server side, even if it sends its SETTINGS+MAX_STREAMS right away, it may afterwards receive HEADERS from the client from *before* the client received MAX_STREAMS. How many streams should a server tolerate in this phase? And when will that phase end?

I think MAX_STREAMS would work fine once established on a connection. But the way to establish this for both sides needs some more work, I believe.

Cheers,
Stefan

Received on Friday, 10 November 2023 13:16:58 UTC