Re: Stream State and PRIORITY Frames

[Scott Mitchell <[e-mail]>]

On Tue, Jan 17, 2017 at 10:10 PM, Tom Bergan <[e-mail]> wrote:

> On Tue, Jan 17, 2017 at 2:43 PM, Scott Mitchell <[e-mail]>
> wrote:
>
>> From my perspective I would like to see two clarifications:
>>
>> 1. It is clear to me that PRIORITY doesn't impact state. However Section
>> 5.1.1 states "first use of a new stream identifier" which makes no
>> reference to stream state. If stream state is important/implied here better
>> to be specific about it. I don't think the one-off example below this text
>> is sufficient to convey the intended implications of this statement.
>>
>> 2. Section 5.1.2 states "Streams in either of the 'reserved' states do
>> not count toward the stream limit." which seems to conflict with 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.". These two statements appear to contradict each other. Since
>> SETTINGS_MAX_CONCURRENT_STREAMS is really the only mechanism to limit
>> resources due to server push I'm assuming section 5.1.2 is overly
>> restrictive.
>>
>
> This is surprising (to me, at least) but I don't believe there is a
> contradiction. You can send an infinite number of PUSH_PROMISEs without
> hitting SETTINGS_MAX_CONCURRENT_STREAMS. A pushed stream doesn't count
> against the concurrent stream limit until you've sent the response HEADERS
> on that pushed stream.
>


If you don't include RESERVED streams in the count for
SETTINGS_MAX_CONCURRENT_STREAMS
then how do you limit the amount of RESERVED streams, and how does your
peer know about this limit? I have imposed an implementation specific
metric in the past, but this seems less preferable than relying on
something in the RFC that the peer is aware of. Either way having infinite
of something doesn't work in practice.

Because of the asymmetry of stream creation in h2 it makes more sense to me
to clarify how streams should be counted toward
SETTINGS_MAX_CONCURRENT_STREAMS.
For example:
Creating a stream in the "reserved" state will consume resources on the
client and therefore SHOULD be counted against SETTINGS_MAX_CONCURRENT_STREAMS
advertised by the client. The server MUST be prepared to accept a
RST_STREAM frame from the client in response to PUSH_PROMISE frame (if this
limit is exceeded or at any time).



> See the related question I asked previously:
> https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0599.html
>
>

Interesting.

https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0601.html
> If you limit server push by applying a stream limit, then you prevent it
from being used in time for the client to use it.

I understand the rational/motivation but practically speaking there will
have to be some limit imposed on PUSHed streams. The client can send a
RST_STREAM in response to a PUSH_PROMISE at any time. So I'm not sure why
having the server pretend like a limit doesn't exist improves the
situation. Pretending a limit doesn't exist may result in additional
network traffic that is avoidable.



> On Tue, Jan 17, 2017 at 2:27 PM, Martin Thomson <[e-mail]>
>> wrote:
>>
>>> On 18 January 2017 at 01:37, Tatsuhiro Tsujikawa <[e-mail]>
>>> wrote:
>>> > If my understanding is correct, this only refers to the new stream ID
>>> used
>>> > by HEADERS, and PUSH_PROMISE frames which open or reserve streams.  The
>>> > example text following that statement uses HEADERS which opens new
>>> stream.
>>> > PRIORITY frame does not change stream state, and there is no reason to
>>> close
>>> > all unused streams lower than bearing stream ID.  That said, I agree
>>> that
>>> > this is not crystal clear in the document.  In practice, this is
>>> probably
>>> > rather rare case.
>>>
>>> This is, I think, the expectation.
>>>
>>> I think that we probably want to clarify the point by explicitly
>>> saying that PRIORITY doesn't affect stream states.  We say that it can
>>> be sent in any state, but we don't also mention that important point.
>>> Do people here agree that an erratum on this point is appropriate
>>> here?
>>>
>>
>>
>