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

William Chan (陈智昌) <willchan@chromium.org> Fri, 03 May 2013 18:30 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 27EC921F968F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 3 May 2013 11:30:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.376
X-Spam-Level:
X-Spam-Status: No, score=-8.376 tagged_above=-999 required=5 tests=[AWL=1.300, 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 rXrJcJgoduR8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 3 May 2013 11:30:18 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2612821F96CC for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 3 May 2013 11:30:08 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UYKjX-00013Z-Si for ietf-http-wg-dist@listhub.w3.org; Fri, 03 May 2013 18:29:27 +0000
Resent-Date: Fri, 03 May 2013 18:29:27 +0000
Resent-Message-Id: <E1UYKjX-00013Z-Si@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 1UYKjN-00011z-J3 for ietf-http-wg@listhub.w3.org; Fri, 03 May 2013 18:29:17 +0000
Received: from mail-qa0-f45.google.com ([209.85.216.45]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UYKjK-0002zL-QS for ietf-http-wg@w3.org; Fri, 03 May 2013 18:29:17 +0000
Received: by mail-qa0-f45.google.com with SMTP id hu16so505207qab.4 for <ietf-http-wg@w3.org>; Fri, 03 May 2013 11:28:49 -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=eOF5TVOifFdmUZTiYXh1CYUe6r0+NEZckPiHTL9IFcU=; b=jbAj8mG4emPNfCJnzZlVIX4NEL/s2AUdDj+4ZaOphZIw2RnFLZu5nqqNzselKcqh2K 4u1PjYUuMRwiTxk01cAz4oWg6UXLvzyIFsoeHW0btQuVWDGpvTE8bVEm6YfssYIz069I KNUjnr+409835dJ0acxJFkhA0NWx0cpVpe2CS6ap6yhyS/0A5eQzrxY68Z8RtGTiL+AU jJsY+eTcS8zXfDkTvlMlFZTT05kF7zZz5BmEA3GZOuekptJIWXM+u83eberGfylOpZqF RypV7mBQedtgTHifo1daLEcdnaOa+jjU0zdcsoSB5amCvTHTqylDYOkKP7ANUuP9PLk7 2ASw==
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=eOF5TVOifFdmUZTiYXh1CYUe6r0+NEZckPiHTL9IFcU=; b=PBqvwQiya7qMi5BfMMN0FAPlyXMPY6aPczG3FfNp9O7RSKf8mnbAG1F65kdJ97RKia 0+NJAJq6AAq+7rrCbtx7QuAnlxw5zQ0DgxaUnkc1uPmAWuW3eloF4KWXtr/ZAJcP9BsX QGJCfiXhkG/LX3UKCXKLn1FfN30rgnVH53GcA=
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=eOF5TVOifFdmUZTiYXh1CYUe6r0+NEZckPiHTL9IFcU=; b=b81xUaAvGraPKzRyBshMkstG5ekUmPpArsrEEhgENXbYCuQQU/BSjenrL1Fn/hNA8O l8ZcZm7Mg3bR9L43Y3P8T3Qwyw0B42/H8j+EBPUD8i5TDDXBkorPhatnspxnVSg4aM8f mplyxYjNenQW/g8w5eRkBrrCGjcwddKS5XBflLJM1vVAfr13SOK1f7liRH3+DOWd4TUi RjZoMY0hymY1YOkd9flH+dG+mG3hfSj0AH8vjGKRXMxCnXLU6eNKYug+jAsIzOnE+QKS MzV3eSbBrEwbFcVUPSi099MlhuS1Ew41vU30A5Ip/BVVPrPoSt6q/u7k4maPjn4WN3P8 pTeA==
MIME-Version: 1.0
X-Received: by 10.224.222.14 with SMTP id ie14mr9764051qab.34.1367605728928; Fri, 03 May 2013 11:28:48 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.180.4 with HTTP; Fri, 3 May 2013 11:28:48 -0700 (PDT)
In-Reply-To: <CABP7RbeJ6Fhs-ncpA4cGQ8SQHayamCmUn=xCmcagwBUs6NLyxg@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>
Date: Fri, 3 May 2013 15:28:48 -0300
X-Google-Sender-Auth: bavMFYZ1re6V9nBBXr5yMOp9Yts
Message-ID: <CAA4WUYgp_b4SZ-OeXyFRiknU0OeWK5bsn-ihiFJqKk26UpHdyQ@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: James M Snell <jasnell@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=20cf3074b45caa809804dbd485d8
X-Gm-Message-State: ALoCoQmMyYFRFLX8EVohrkrPVKM/bLJ4Z0rLI8lsGU1pi+gK6M4UkB/FnFCCkuwULIUo5aDSiwNugDiQD7VRdddIwrzSF2KND6eWqN7HZhX+bWs9cE9UKhpIqYqm2BRye1wSa/qi2Bt6H3bauqauutvSvSuGSWDKk0xk+iH0X9hc45xkGMxnUSz6FT5rURv55GfFq2d5W3DB
Received-SPF: pass client-ip=209.85.216.45; envelope-from=willchan@google.com; helo=mail-qa0-f45.google.com
X-W3C-Hub-Spam-Status: No, score=-4.8
X-W3C-Hub-Spam-Report: AWL=-1.422, 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 1UYKjK-0002zL-QS 59493764e5897452d25a1dadd2b2286b
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/CAA4WUYgp_b4SZ-OeXyFRiknU0OeWK5bsn-ihiFJqKk26UpHdyQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17808
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>

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