Re: Stream limits draft posted

Hi Glenn,

Thanks for the feedback.

Do you want to be a co-author?  This is very specific and useful feedback that would justify coauthorship.  If you want to hit me up privately, let me (and Lucas) know.

More inline on the specifics.

On Mon, Nov 6, 2023, at 22:23, Glenn Strauss wrote:
> 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.

I don't know if that is an approach I would take always.  It might make sense to set the value lower, so that you are more generous with a peer that supports MAX_STREAMS.

Also, there is text in the draft on this point already.  I'm not sure if this is a little redundant with existing text.

I've opened a pull request for this so we can try it on: https://github.com/martinthomson/h2-stream-limits/pull/7

I've tweaked the first "recommended" to be a "can", but I'm really not sure about the MUST NOT.  If we go here, maybe we should just point out the consequence of the change (which is a reduction in concurrency for peers that support this extension.


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

Of course, I always think of SETTINGS as part of the preface, but that's not right: https://github.com/martinthomson/h2-stream-limits/pull/6

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

So the goal is to let both client and server advertise support.  You need both or you don't know which limit you should be policing.  I don't think that we can economize here in the way you suggest.  That is, we already require that endpoints that support this send MAX_STREAMS.  As you say, the server only has to send this once if it finds out that the client doesn't support the feature, and the client only ever needs to send it once, unless it wants server push.  That's pretty cheap.

Thanks,
Martin

Received on Tuesday, 7 November 2023 15:26:46 UTC