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

I guess I kinda think that we're worrying too much about this corner of the
spec. I don't view it as a big deal in practice. The problem described
happens when MAX_CONCURRENT_STREAMS is too low to allow enough parallelism
per roundtrip. I would advise people to simply increase their
MAX_CONCURRENT_STREAMS in that case. I kinda think this is only problematic
when we have very high latencies and devices that can't handle high
parallelism, like an interplanetary refrigerator that speaks HTTP/2 for
some reason. <shrug>

I am unsure how to feel about a ENHANCE YOUR CALM code as it's not well
defined. I don't mind RST_STREAMs on exceeding limits, like the initial
MAX_CONCURRENT_STREAMS, since they're usually the result of a race (the
possible initial SETTINGS frame race) and we won't have to keep continually
sending RST_STREAMs to rate limit appropriately.


On Fri, May 3, 2013 at 3:02 PM, James M Snell <jasnell@gmail.com> wrote:

> The impact on client-to-server initiated streams is another reason why
> I suggested the credit-based approach and why it would likely be good
> to have an RST_STREAM "ENHANCE YOUR CALM" error code [1]. If the
> client misbehaves and sends too much too quickly, we have flow
> control, settings, rst_stream and goaway options to deal with it.
>
> [1]
> http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Server_Error
>
> On Fri, May 3, 2013 at 10:34 AM, William Chan (陈智昌)
> <willchan@chromium.org> wrote:
> > As I understand the proposal, which I believe ties into the issue James
> > raised at the beginning here, the goal is to be able to open and close a
> > directional stream without an ACK, which I am nervous about as I said
> above
> > without much detail. Concretely speaking, a HTTP GET is a
> HEADERS+PRIORITY
> > frame with a FINAL flag or an extra DATA frame with FINAL flag. This
> means
> > that the request effectively never gets counted against the directional
> > stream limit, as controlled by the receiver which sends a
> > MAX_CONCURRENT_STREAMS setting, since it open and closes the direction in
> > the same frame (or closes in the subsequent empty DATA frame).
> >
> >
> > On Fri, May 3, 2013 at 1:52 PM, Martin Thomson <martin.thomson@gmail.com
> >
> > wrote:
> >>
> >> On 3 May 2013 09:44, William Chan (陈智昌) <willchan@chromium.org> wrote:
> >> > I'd like server folks to chime in, but doing this makes me feel a bit
> >> > nervous. I feel this effectively disables the directional concurrent
> >> > streams
> >> > limit. The bidirectional full-close essentially acts like an ACK, so
> >> > removing it might result in an unbounded number of streams.
> >>
> >> I think that I know what you mean here, but can you try to expand a
> >> little?  Do you refer to the possible gap between close on the
> >> initiating direction and the first frame on the responding direction;
> >> a gap that might cause the stream to escape accounting?  I think that
> >> is a tractable problem - any unbounded-ness is under the control of
> >> the initiating peer.
> >
> >
>