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

On Fri, May 3, 2013 at 9:52 AM, 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.

Well, there are really several issues here...

1. The server endpoint would be allowed to initiate an unbounded
number of push streams, up to MAX_CONCURRENT_STREAMS at any given
time, but with no reasonable upper limit on the overall total number
of streams. For instance, given a MAX_CONCURRENT_STREAMS of 10, it
could initiate 10 streams and close them, initiate 10 more and close
those, initiate 10 more.. ad infinitum. Generally speaking, I don't
believe this is really a serious issue, however. The receiving end can
simply opt to reject pushed streams from misbehaving servers once a
particular threshold was reached (which is where I was going with the
credit limit proposal before).

2. There may be (as you suggest) a gap of time between when the server
sends it's FINAL frame on a pushed stream and the time when a client
might send it's FINAL (if any FINAL frame comes at all). Here, again,
however, the MAX_CONCURRENT_STREAMS bounds the total number of open
streams the server can push at any given time and the client can opt
to reject additional streams if the flow becomes unmanageable.

Modeling this out, I believe that clients will definitely have to
implement some protections against abuse but those protections do not
need to be standardized. Clients would simply implement whatever
algorithm they wish to determine whether or not to accept new pushed
streams. MAX_CONCURRENT_STREAMS would cover only streams that are
initiated by and opened for the sending peer. If a peer closes it's
side, it decrements the counter for that peer. Half-open streams in
the other direction would not count. A receiving peer that is dealing
with a misbehaving endpoint can use RST_STREAM to refuse new pushes or
send a SETTINGS with a new, more restrictive MAX_CONCURRENT_STREAMS
value.

Btw... Another possible dimension we could consider is a new
RST_STREAM error code indicating that a stream is being rejected
because too many streams are being opened too quickly.

- James

Received on Friday, 3 May 2013 17:36:21 UTC