Re: Stream State and PRIORITY Frames

[Cory Benfield <[e-mail]>]

> On 17 Jan 2017, at 18:16, Scott Mitchell <[e-mail]> wrote:
> 
> Thanks for responses everyone. There seems to be recognition that the specification lacks clarity but there also seems to be momentum behind "Option 1".
> 
> This leads to the practical concern of bounding the amount of memory committed to streams in this state. SETTINGS_MAX_CONCURRENT_STREAMS limits number of streams in "open" or "half-closed", but the specification doesn't (to my knowledge) define a way to limit the number of "reserved" streams or "idle"/"closed" streams which have had only PRIORITY frames exchanged. The specification allows for implementations to discard PRIORITY more or less at their discretion [3], but limiting "reserved" streams is another issue. "SETTINGS_ENABLE_PUSH" is limited to 0 or 1 [4] so there is no way for a client to advertise how many "reserved" streams it is willing to accept. What are the practical approaches folks have taken to address these issues?
> 
> [3] https://tools.ietf.org/html/rfc7540#section-5.3.4 <https://tools.ietf.org/html/rfc7540#section-5.3.4>
> > The retention of priority information for streams that are not counted toward the limit set by SETTINGS_MAX_CONCURRENT_STREAMS could create a large state burden for an endpoint. Therefore, the amount of prioritization state that is retained MAY be limited.
> [4] https://tools.ietf.org/html/rfc7540#section-6.5.2 <https://tools.ietf.org/html/rfc7540#section-6.5.2>
> > The initial value is 1, which indicates that server push is permitted.  Any value other than 0 or 1 MUST be treated as a connection error (Section 5.4.1 <https://tools.ietf.org/html/rfc7540#section-5.4.1>) of type PROTOCOL_ERROR.

SETTINGS_MAX_CONCURRENT_STREAMS is used to limit the number of pushed streams.

The key thing to understand is that there are *two* values of SETTINGS_MAX_CONCURRENT_STREAMS on each connection: one set by the client and one set by the server. The one set by the server limits the number of client-initiated streams there may be (that is, streams initiated by HEADERS frames). The one set by the client limits the number of server-initiated streams there may be (that is, streams initiated by PUSH_PROMISE frames).

This is laid out explicitly in RFC 7540 Section 8.2.2:

> A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit
> the number of responses that can be concurrently pushed by a server.
> Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables
> server push by preventing the server from creating the necessary
> streams.  This does not prohibit a server from sending PUSH_PROMISE
> frames; clients need to reset any promised streams that are not
> wanted.

Cory