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

[Martin Thomson <[e-mail]>]

On 29 April 2013 10:40, William Chan (陈智昌) <[e-mail]> wrote:
> 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

s/solves/mitigates/  - they aren't free

> * 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).

MAX_CONCURRENT_STREAMS also helps with the buffer size problem.

> * 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)?

You have to signal what you intend to push to give the client a chance
to reject it.  That's all.  So the only things that have to be in the
promise are resource identification things (:scheme, :host, :path),
and maybe (maybe) things that help identify cache (content-type, vary,
cache-control)

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

I don't believe that the proposal improves the situation enough (or at
all) to justify the additional complexity.  That's something that you
need to assess for yourself.  This proposal provides more granular
control, but it doesn't address the core problem, which is that you
and I can only observe each other actions after some delay, which
means that we can't coordinate those actions perfectly.  Nor can be
build a perfect model of the other upon which to observe and act upon.
 The usual protocol issue.