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

William Chan (陈智昌) <willchan@chromium.org> Fri, 03 May 2013 21:36 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 285BF21F9052 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 3 May 2013 14:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.933
X-Spam-Level:
X-Spam-Status: No, score=-8.933 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 PxaKnGDPpVyH for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 3 May 2013 14:36:21 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id C49EA21F9079 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 3 May 2013 14:36:17 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UYNdo-00068Y-3E for ietf-http-wg-dist@listhub.w3.org; Fri, 03 May 2013 21:35:44 +0000
Resent-Date: Fri, 03 May 2013 21:35:44 +0000
Resent-Message-Id: <E1UYNdo-00068Y-3E@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <willchan@google.com>) id 1UYNdd-00067o-8U for ietf-http-wg@listhub.w3.org; Fri, 03 May 2013 21:35:33 +0000
Received: from mail-qc0-f173.google.com ([209.85.216.173]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UYNdc-0001Qj-6Q for ietf-http-wg@w3.org; Fri, 03 May 2013 21:35:33 +0000
Received: by mail-qc0-f173.google.com with SMTP id h29so45848qcu.32 for <ietf-http-wg@w3.org>; Fri, 03 May 2013 14:35:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lVlifMIMOHl8svjjFk8fe2k8ydLBn28dCT1skEI6LA8=; b=NT8itKx+8/cXdckFgCsKidkbpoRIinUuJeuIGAatA6cJt5/8P5jEIyQoxUn4nbN5BR lD0+GSA03TDvS4QbD2XKGRqPA725H8IWbS66xt9VFxDVlDavoM0alT8QMc5VnF/FDgi3 rzCUtOb4T4gLPclkYk2WGwZcmwcN9W+NmTFqRtQv1ak+0J5YCHNgdNmuyAbQESHgy0UR t0adUFhhosfJ8wK0CazZFq5sXpOPnD5nD2euhxbzTaW0FA9b+IhYUQ77XQa1s287mRZf MwPZiDjPaG5l4vdepFZ3DdGqz3rW4EYzv6jTVycJka7u/v9OJmNX6lKuWnVCF4/fFc5H MBLQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lVlifMIMOHl8svjjFk8fe2k8ydLBn28dCT1skEI6LA8=; b=itu7YMxOy3GOUlhp/pVyxEJz0dJ+GYV3fQdeZkxL6dHa+ovK/V6PU7DkFTwnYP2xQQ 8vqFmtRqHA/hZMd7Ol50befECyZ3PJVAs69v07iyBcTuvB5mCKTbeMZR3vEK3dsEnqWk Nih7ANwKXd7F0Wpfs+hHbM2o93+yb/ME3g0WY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=lVlifMIMOHl8svjjFk8fe2k8ydLBn28dCT1skEI6LA8=; b=DjJ3mtdY5Ob4vIhpfPltB7VX/DdqRnnX1tc9hu5WI8FO6rv55MMJV7z3zEg5j8/xgH p0HDwuYuQ8Fg2e1kjGqbBtZq9yhNeRMfrYSoDVq/LwjBI0Aub8pWMCSi9Yj3HUmUs4Cs FnpTgJzzX3/AZ2RFYBXL28GEWPeYlVbONd5HFPh6kC9HNnDmMCwHHQx3hn2FDy0Crysu f6Rt3cNHWGYHteI65Ftg9xhTYvQ3Cp7A3MYHUnnrgKbmscJJBqqTTTZOnAC8NcAnSJDa t3yzrq5SJpLpcm0zvu7EwI/NuLbMF0tGth+Zz4pm3jHc8gGdb6UgAW9IIDsQz8dlZ6zg 7yKg==
MIME-Version: 1.0
X-Received: by 10.224.199.199 with SMTP id et7mr14672906qab.31.1367616905874; Fri, 03 May 2013 14:35:05 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.180.4 with HTTP; Fri, 3 May 2013 14:35:05 -0700 (PDT)
In-Reply-To: <CAP+FsNdfT0du=P7TzE4pPPgzaCi2YR-jpeE1US0inm46n9Z5pQ@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>
Date: Fri, 3 May 2013 18:35:05 -0300
X-Google-Sender-Auth: eIF2kSSZJzvYvijFD3G5IprQRhI
Message-ID: <CAA4WUYgANXbyre3RbSgMQG60Ve72Rw-+YpPXJEJ-4CXTXq0s4w@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: Roberto Peon <grmocg@gmail.com>
Cc: James M Snell <jasnell@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=20cf300fb3e3dfb9f304dbd71f51
X-Gm-Message-State: ALoCoQk//ljzNxnuuqmVbxqndGETlLjP0Bcmjd53sQVKGa7lWhQebtO2sxtLM6YGHyxVsU6QKkoEG3wI/WHeALbkvooZXySvZcacPI5adJGan5OmX6xprOhEj34Zu9fQSyUqLI4nrdYpQ+JoIAs+JqLy2kWTvFE7jB4TbO3gww5AIY0+lrc93Bzgju8IK3PpR7rxJHx4QrE4
Received-SPF: pass client-ip=209.85.216.173; envelope-from=willchan@google.com; helo=mail-qc0-f173.google.com
X-W3C-Hub-Spam-Status: No, score=-4.8
X-W3C-Hub-Spam-Report: AWL=-1.399, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.581, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UYNdc-0001Qj-6Q 3f3988b43f24c3a2d058ee7575ca1e39
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/CAA4WUYgANXbyre3RbSgMQG60Ve72Rw-+YpPXJEJ-4CXTXq0s4w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17821
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>

On Fri, May 3, 2013 at 6: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 spent time thinking about whether or not this was a problem. I certainly
found it annoying, but it might be change aversion from SPDY. My mental
reduction of this suggestion was the coupling of directions of the stream
was moving out of the streaming layer to the application semantics layer.
At the HTTP semantic layer, where you want a response for every request,
the client can open a client=>server direction stream at the streaming
layer and register a callback for the server=>client direction stream at
the streaming layer. The client keeps the original request headers as long
as it's expecting the response stream.

I think there's a certain aesthetic layering cleanliness to Martin's
suggestion in this way by moving the coupling out from a lower layer to a
higher layer. I am still mulling it over. I also haven't thought through
the server case, so I might have missed how this is annoying for them.


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

That'd be wrong at the semantic layer and should probably trigger an error.


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

Agreed.


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