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

I read this entire thread and don't really see the problem we want to
solve. Can someone clarify? Let me reviewe the paint points as I understand
them:
* Stream data buffers are expensive - flow control solves this
* Stream headers are potentially expensive - MAX_CONCURRENT_STREAMS
mitigates this, although I'm not entirely convinced this is a complete
solution, especially when you can keep adding HEADERS for a stream without
bound (headers are problematic since you have to process them due to the
shared compression context).
* Stream ids are cheap. They're ids and don't require much context.
Historically PUSH_PROMISEs were cheap, but now that they can carry header
blocks, we've regressed on that. I forget why we added the header blocks
into the PUSH_PROMISE, can someone remind me (better yet, link to the
appropriate email thread)?

As far as the potential problem above, the root problem is that when you
have limits you can have hangs. We see this all the time today with
browsers (it's only reason people do domain sharding so they can bypass
limits). I'm not sure I see the value of introducing the new proposed
limits. They don't solve the hangs, and I don't think the granularity
addresses any of the costs in a finer grained manner. I'd like to hear
clarification on what costs the new proposed limits will address.


On Thu, Apr 25, 2013 at 2:50 PM, James M Snell <jasnell@gmail.com> wrote:

> https://github.com/http2/http2-spec/issues/78
>
> In the current draft (-02), we state that:
>
> A. Any endpoint can initiate and half-close a fully unidirectional
> stream that does not require any action or acknowledgement from the
> receiving peer. Once half-closed, these remain in a constant
> half-closed state with the receiving peer having the option of sending
> frames for that stream at any time for the full duration of the
> session.
>
> B. An endpoint MUST NOT exceed the maximum concurrent streams limit
> set by it's peer and that streams initiated by the endpoint that are
> half-closed in any direction count towards this limit.
>
> C. Unless I missed it somewhere, clients are never required to
> half-close PUSH_PROMISE streams.
>
> The potential problem here is simple:
>
> 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.
>
>