Re: Stream limits draft posted

On Mon, Nov 06, 2023 at 04:01:55PM +0100, Martin Thomson wrote:
> 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.
> 
> We have time to discuss this week.
> 
> Cheers,
> Martin

+1

Overall, I think the feature to be a good one, and with already proven
utility in QUIC.  From an implementation perspective, I sketched out
that implementation on the server side could be coded in less than an
hour, and additional overhead and resource usage at runtime would be
minimal.


Some quick thoughts from reading the draft:

3.1 Applying Stream Limits

Suggestion:

For compatibility with existing implementations which may not support
MAX_STREAMS, it is recommended to set a SETTINGS_MAX_CONCURRENT_STREAMS
to a value less than or equal to the numbers of concurrent streams
intended to be allowed with MAX_STREAMS.  An endpoint MUST NOT enforce a
MAX_STREAMS limit lower than SETTINGS_MAX_CONCURRENT_STREAMS unless the
endpoint knows that the other endpoint supports MAX_STREAMS.


3.2 Negotiating MAX_STREAMS Usage

Correction: please clarify:

MAX_STREAMS frame must follow the initial connection preface *AND*
initial SETTINGS frame.  Doing otherwise might break existing
implementations that expect a SETTINGS frame to follow immediately
after connection preface.



Suggestion:

Require that client send MAX_STREAMS following client connection preface
and SETTINGS to indicate support for MAX_STREAMS.  Since server PUSH is
a deprecated feature in HTTP/2, sending MAX_STREAMS 0 would be an
indication that the client supports MAX_STREAMS and that the server
should produce MAX_STREAMS frames (and that the server should not send
PUSH frames unless enabled in SETTINGS and having received a larger
value for MAX_STREAMS from client).

If a client does support receipt of PUSH, then in addition to receiving,
processing, and honoring MAX_STREAMS frames from the server, this would
impose client support for *sending* MAX_STREAMS frames to allow server
PUSH streams.

This suggestion would result in no MAX_FRAMES frames produced by the
server unless the server knows that the client supports MAX_STREAMS.

Cheers, Glenn

Received on Monday, 6 November 2023 21:23:24 UTC