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

Roberto Peon <grmocg@gmail.com> Sat, 04 May 2013 01:51 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBEF21F8FD3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 3 May 2013 18:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.554
X-Spam-Level:
X-Spam-Status: No, score=-7.554 tagged_above=-999 required=5 tests=[AWL=-1.956, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMsPyYx+-jpk for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 3 May 2013 18:51:25 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 64C0321F8FA4 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 3 May 2013 18:51:23 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UYRcS-00047S-0p for ietf-http-wg-dist@listhub.w3.org; Sat, 04 May 2013 01:50:36 +0000
Resent-Date: Sat, 04 May 2013 01:50:36 +0000
Resent-Message-Id: <E1UYRcS-00047S-0p@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UYRcI-00046J-9O for ietf-http-wg@listhub.w3.org; Sat, 04 May 2013 01:50:26 +0000
Received: from mail-ob0-f172.google.com ([209.85.214.172]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UYRcF-00031E-8G for ietf-http-wg@w3.org; Sat, 04 May 2013 01:50:26 +0000
Received: by mail-ob0-f172.google.com with SMTP id xk17so1917263obc.31 for <ietf-http-wg@w3.org>; Fri, 03 May 2013 18:49:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qa1Ru7CpQYnWJq2yr5n7s6Aew2sHxkghxzSLBn5wGu0=; b=iGE2aWpGwm/DAPeNwDv2mHmPUCxOr9KfTFdVVkI0+lHH4sCdfHE3f9WM6ScsVIKG14 mhLBUK3nlHEXHy/7ZeXudl+tl5IKtQF+jc7jYJRwWifLUsQQqXhbm+giRiszxdO5vCZx ogVhl51RvCiKeIuDMZ437/jQ1Frv2ZguzX+SI5aqzES2I9WVVQDNSDMkQbk0QhhRj5bc evgGqP0oOOoZRpMb6az+rF8Xl2YRPa6vA7X7ulZWW7+KzuaIVICsK9fA/+RqBVZ/XxSW iCRhGL1P8Rr8BYKuSmOhuQ4b+Ngkz/NCad4wJtKvUhuDEHZP2/WGmPz+0qr+Aoig93En vHpw==
MIME-Version: 1.0
X-Received: by 10.182.143.7 with SMTP id sa7mr3525702obb.0.1367632197272; Fri, 03 May 2013 18:49:57 -0700 (PDT)
Received: by 10.76.130.139 with HTTP; Fri, 3 May 2013 18:49:57 -0700 (PDT)
In-Reply-To: <CABP7RbfqZao-kGo==UbHS3f9GFHWu048bSsUvJ3AARiq0dN60w@mail.gmail.com>
References: <CABP7RbdBe-Xkx+CMvpN=_oNAqm6SyLyL+XNHRUKSqn8mjSDw1Q@mail.gmail.com> <CAA4WUYgCiyWerT0tUUVKcbNPqdTGuXHd_MG59DjcUsEWst5t7g@mail.gmail.com> <CABkgnnVdU=cZ53Bqg5Un=E80NMpcgYO37DVmwUFW0O-i7SNf8w@mail.gmail.com> <CAA4WUYhz64FsEGgGhx91RfWwuPPxWdAkesOV-bmqWVWE7ZxdjA@mail.gmail.com> <CABP7RbcKQkn1o4WZscwNmSmm6YzqE_TKxPr4jnozNdaVqpZ7=A@mail.gmail.com> <CAA4WUYhF6rAZoYEaz4aJO6xawaJxzxGt=Bkg4H9eBOP-LBSRmQ@mail.gmail.com> <CAP+FsNezQzxdZEJY_2_0h_TR2pBbVsGyGBhQhKcm-65pt6S8rQ@mail.gmail.com> <CABP7RbevS8M0q9OxzPncqY_gE34q5-ymdg2hOX2SQgSUNkhzsw@mail.gmail.com> <CAA4WUYjAbuUqz9RdO+-p3a4EsyuS=Gv0rS-U-Vh+ZCjtDjFy6w@mail.gmail.com> <CAP+FsNec2LLZMjtGhSX-1q8qg66WtBoM5K0yMrs5m4VKXb5OVg@mail.gmail.com> <CAA4WUYgAT64jj=Am06MsA02A+eAcDrVbbgb4opO37bnMkWTPfg@mail.gmail.com> <CABP7Rbdgz=kRZPfjHK5UUfieq8uz=ToQZjFt1-+s9scj1CogmA@mail.gmail.com> <CAA4WUYjSjFKSdbj=QBLn0T4ufhzF1hUY=O=Qa2dfnkTzMXF0bg@mail.gmail.com> <CABP7RbejssYWH+nEumVX__+4TnE1ec8e1YXeY8kqWF+AgszTrg@mail.gmail.com> <CAA4WUYiRVxM78Dr+eh9ksVvW_9=S01mHxt_Wr+SyaVECmc0e-g@mail.gmail.com> <CABP7RbexX0T=yYKPeKFeGEnzMAcO7fAifZh6LfLCOngLDNQHUA@mail.gmail.com> <CABkgnnUeicCNUa70GW7Vv9-bbwLPiPM=2-_t28Qz5o6DT0jF8Q@mail.gmail.com> <CABP7RbfbmTqFHPkRvj2K6iZ=Oo7MsT3hD9Y33fmtU9HOLoDmUA@mail.gmail.com> <CAA4WUYj81k1dK-LV+=h-yto4WEpVWFaRnCQZ+h55mipYCnQeYw@mail.gmail.com> <CABkgnnVEy7LPU2sUrKVFTLpEVP4RcWnbdgs1oRvmNFujZGQBOg@mail.gmail.com> <CAA4WUYhznNY_2YBUoMq4Us5NO0r_04Caz9_O1iZUrW4kc3kNcA@mail.gmail.com> <CABP7RbeJ6Fhs-ncpA4cGQ8SQHayamCmUn=xCmcagwBUs6NLyxg@mail.gmail.com> <CAA4WUYgp_b4SZ-OeXyFRiknU0OeWK5bsn-ihiFJqKk26UpHdyQ@mail.gmail.com> <CAP+FsNdfT0du=P7TzE4pPPgzaCi2YR-jpeE1US0inm46n9Z5pQ@mail.gmail.com> <CABP7RbfqZao-kGo==UbHS3f9GFHWu048bSsUvJ3AARiq0dN60w@mail.gmail.com>
Date: Fri, 3 May 2013 18:49:57 -0700
Message-ID: <CAP+FsNf6p1fK_MH2P4vZTpt_CFWttDagY1nVdPvsdXm3tp_XuA@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=e89a8ff256224d4c7504dbdaafbc
Received-SPF: pass client-ip=209.85.214.172; envelope-from=grmocg@gmail.com; helo=mail-ob0-f172.google.com
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-2.649, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UYRcF-00031E-8G 5b8c73348ca470e1a67834ca4f58df47
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: Max Concurrent Streams Limit and Unidirectional Streams
Archived-At: <http://www.w3.org/mid/CAP+FsNf6p1fK_MH2P4vZTpt_CFWttDagY1nVdPvsdXm3tp_XuA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17829
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hey, you're the one worried about the size of the compressor state (which
would be ~4 or 8k)! :)
Headers are sometimes larger individually, and the upper limit to the size
of this state is the sum of 10s to 100s of these.

I think that, pragmatically, since there is a framing-layer solution which
ensures that one must not store headers for longer that necessary, and
which is semantic-layer agnostic, it is a decent bet.
Any approach other than declaring it as unidirectional (or equivalent)
either requires the caching of much state, or a NACK from the remote side.

That isn't to say that Martin's approach doesn't have appeal. I want to
like it, but unless we are to have unlimited streams in some limbo state,
it would require a NACK, else I won't be able to correlate sets of headers
on a stream and the NACK both requires more machinery at both ends, and
consumes more bytes on the wire.
-=R



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

> Ok.. going back over the thread in detail and over the spec again, one
> approach to addressing the overall concern here (and hopefully bring a
> bit more rigor to the overall design) is to redefine the stream states
> slightly along the same lines already suggested by Martin. Each
> endpoint would maintain its own view of the current activity state of
> every stream in a session, however, the state would only reflect the
> actions taken by the peer endpoint. There are five possible activity
> states:
>
> Unused
>   The peer endpoint has not reserved or used the stream in any way.
>
> Open
>   The endpoint has received frames on the stream from the peer, none
> of which are type RST_STREAM or have the FINAL flag set.
>
> Closed
>   The endpoint has received an RST_STREAM frame, or any frame with the
> FINAL flag set from the peer
>
> Reserved-Open
>   The peer has reserved the stream identifier for future use but
> frames have not yet been received on that stream. The receiving
> endpoint is expected to send its own frames on the same stream.
>
> Reserved-Closed
>   The peer has reserved the stream identifier for future use but
> frames have not yet been received on that stream. The receiving
> endpoint is not expected to send its own frames on the same stream.
>
> MAX_CONCURRENT_STREAMS == The number of streams in the Open state the
> endpoint will permit the peer to initiate at any given time. Once that
> limit is reached, the receiving endpoint will likely begin rejecting
> new streams using RST_STREAM. In other words, right now,
> MAX_CONCURRENT_STREAMS is defined in terms of what the sending
> endpoint must not do. This changes the definition to an indication of
> what the receiving endpoint will do once a particular threshold is
> reached. Any endpoint that wants to be able to keep creating streams
> must be diligent about sending FINAL frames, etc.
>
> As for the Request-Response bounding issue, that's really an HTTP
> semantic layer notion. I'm not fully convinced we really need to
> handle that issue in the framing layer at all.
>
>
> On Fri, May 3, 2013 at 2:20 PM, Roberto Peon <grmocg@gmail.com>; wrote:
> > The biggest rub in Martin's suggestion is that, as a stream initiator, I
> no
> > longer know for how long I should keep the original "request" headers
> > around.
> > I view that as an annoying problem (I want every response to be
> attributable
> > to a request).
> >
> > I also think it is a bit confusing-- how would it be used in cases where
> > I've sent all my data on what I thought was a unidirectional stream, and
> > then receive bytes from the other side on that stream. That'd be...
> weird.
> >
> > With the unidirectional bit (or similar declaration of half-closed
> > start-state), I now know (by fiat, essentially) that I will not receive a
> > response on that stream ID, and so I don't need to keep the "request"
> > headers around after I've finished pushing the stream. Logging
> accomplished.
> >
> >
> > I think this is an easy issue to solve by reinstating the unidirectional
> bit
> > (for now). It is certainly minimal work to have servers which do server
> push
> > set that bit.
> >
> > To Will's point, I agree that an "ENHANCE YOUR CALM" code seems
> redundant.
> > In my case I believe it redundant because the remote side has already
> > received my settings frame, or is sending without having known it (i.e.
> > within the initial RTT), and will be receiving the SETTINGS frame before
> it
> > could process this new code anyway (assuming I'm following spec and
> sending
> > SETTINGS immediately upon session establishment).
> > -=R
> >
> >
> >
> >
> >
> > On Fri, May 3, 2013 at 11:28 AM, William Chan (陈智昌) <
> willchan@chromium.org>;
> > wrote:
> >>
> >> 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.
> >>> >
> >>> >
> >>
> >>
> >
>