RE: Design Issue: Max Concurrent Streams Limit and Unidirectional Streams

[RUELLAN Herve <[e-mail]>]

I've got the feeling that we should limit in some way the number of promised streams: too many promised streams could hurt an intermediary.

One way to do this is to say that a PUSH_PROMISE creates a new stream. In this way it is counted against the SETTINGS_MAX_CONCURRENT_STREAMS. We would also have to mandate a client to half-close all PUSH_PROMISE streams.


While reading the current spec, my understanding on whether a PUSH_PROMISE created a new stream wandered back and forth, and I think some clarification could be useful.

In particular the first paragraph of 3.4.1:
"There is no coordination or shared action between the client and server required to create a stream. Rather, new streams are established by sending a frame that references a previously unused stream identifier."

The "Promised-Stream-ID" of the PUSH_PROMISE frame could be considered as being the reference to an unused stream identifier, therefore creating the stream.

The rest of 3.4.1 and 3.8.5 on the contrary say that a PUSH_PROMISE frame doesn't create a new stream.

I would propose the following edit to this first paragraph of 3.4.1:
"There is no coordination or shared action between the client and server required to create a stream. Rather, new streams are established by sending a frame that references in its "Stream Identifier" field a previously unused stream identifier."

Hervé.

> -----Original Message-----
> From: Martin Thomson [mailto:[e-mail]]
> Sent: jeudi 25 avril 2013 21:26
> To: James M Snell
> Cc: [e-mail]
> Subject: Re: Design Issue: Max Concurrent Streams Limit and Unidirectional
> Streams
> 
> On 25 April 2013 10:50, James M Snell <[e-mail]> wrote:
> > https://github.com/http2/http2-spec/issues/78
> >...
> > If a client sets a limit of 4 concurrent streams, and the server
> >initiates 4 separate PUSH_PROMISE streams that the server half-closes
> >but that are never half-closed by the client, the server will not be
> >able to initiate new push streams for the duration of the session.
> 
> Yep, it's a problem.  We got rid of the unidirectional flag that addressed this.  I
> can't speak for others, but I was aware of the issue at the time, but I had a
> solution in mind.  That never got written down, partly because we didn't
> have this discussion :)
> 
> On first blush, the only way to avoid the problem is to expect the framing
> layer to be aware of what is going on above, but that's probably not sensible.
> But there's a better way:
> 
> Each stream has two separate state variables, each with three state
> values: no packet yet, open, half-closed.  Streams that have inbound ==
> open || outbound == open are "in use" and count toward the stream limit.
> Documenting this might help clarify how the accounting is done.
> 
> Importantly, this means that promised streams do not count toward the
> limit.  It does however also imply that implementations will need to be
> careful about how they allocate stream resources.  Pushes complicate that a
> little because the lifecycle of headers doesn't match stream lifecycles.  Again,
> I'd suggest an approach where implementations defer commitment of flow
> control buffers until the first flow-controlled frame arrives (memory pre-
> allocation might be advisable for performance reasons, but that would not be
> an actual
> commitment) and to ensure that any state for send and receive don't have
> the same lifecycle.