Re: Stream State and PRIORITY Frames

[Scott Mitchell <[e-mail]>]

On Tue, Jan 17, 2017 at 10:35 AM, Scott Mitchell <[e-mail]>
wrote:

>
>
> On Tue, Jan 17, 2017 at 10:25 AM, Cory Benfield <[e-mail]> wrote:
>
>>
>> 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
>> > 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.
>
>
I recall where my confusion stems from. Section 5.1.2 contradicts the
statements in Section 8.2.2 you referenced. Section 5.1.2 explicitly states
that "reserved" streams do not count toward SETTINGS_MAX_CONCURRENT_STREAM
S [5].

[5] https://tools.ietf.org/html/rfc7540#section-5.1.2
> Streams that are in the "open" state or in either of the "half-closed"
states count toward the maximum number of streams that an endpoint is
permitted to open. Streams in any of these three states count toward the
limit advertised in the SETTINGS_MAX_CONCURRENT_STREAMS setting. Streams in
either of the "reserved" states do not count toward the stream limit.



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