Re: Stream State and PRIORITY Frames

On Tue, Jan 17, 2017 at 10:25 AM, Cory Benfield <cory@lukasa.co.uk> wrote:

>
> On 17 Jan 2017, at 18:16, Scott Mitchell <scott.k.mitch1@gmail.com> 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
> > 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
>
> > 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:
>

Ahh yes I forgot about this. Thanks for reminding me.

Any thoughts on limiting the stream priority?


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