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

RUELLAN Herve <Herve.Ruellan@crf.canon.fr> Fri, 26 April 2013 10:32 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 385BA21F98C3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 26 Apr 2013 03:32:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.223
X-Spam-Level:
X-Spam-Status: No, score=-9.223 tagged_above=-999 required=5 tests=[AWL=1.027, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 U0ByGsNHFSrc for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 26 Apr 2013 03:32:05 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4791921F98BF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 26 Apr 2013 03:32:05 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UVfw4-0006UQ-LF for ietf-http-wg-dist@listhub.w3.org; Fri, 26 Apr 2013 10:31:24 +0000
Resent-Date: Fri, 26 Apr 2013 10:31:24 +0000
Resent-Message-Id: <E1UVfw4-0006UQ-LF@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <Herve.Ruellan@crf.canon.fr>) id 1UVfvy-0006Tl-Up for ietf-http-wg@listhub.w3.org; Fri, 26 Apr 2013 10:31:18 +0000
Received: from inari-msr.crf.canon.fr ([194.2.158.67]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <Herve.Ruellan@crf.canon.fr>) id 1UVfvx-0006Vj-Qr for ietf-http-wg@w3.org; Fri, 26 Apr 2013 10:31:18 +0000
Received: from mir-msr.corp.crf.canon.fr (mir-msr.corp.crf.canon.fr [172.19.77.98]) by inari-msr.crf.canon.fr (8.13.8/8.13.8) with ESMTP id r3QAUoat007864; Fri, 26 Apr 2013 12:30:50 +0200
Received: from ADELE.crf.canon.fr (adele.fesl2.crf.canon.fr [172.19.70.17]) by mir-msr.corp.crf.canon.fr (8.13.8/8.13.8) with ESMTP id r3QAUoxi029812; Fri, 26 Apr 2013 12:30:50 +0200
Received: from ADELE.crf.canon.fr ([::1]) by ADELE.crf.canon.fr ([::1]) with mapi id 14.02.0342.003; Fri, 26 Apr 2013 12:30:50 +0200
From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
To: Martin Thomson <martin.thomson@gmail.com>, James M Snell <jasnell@gmail.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Thread-Topic: Design Issue: Max Concurrent Streams Limit and Unidirectional Streams
Thread-Index: AQHOQd3ytlor/PJdZ0CP6Skli8r/5pjnMA8AgAEYQLA=
Date: Fri, 26 Apr 2013 10:30:49 +0000
Message-ID: <6C71876BDCCD01488E70A2399529D5E516416AA8@ADELE.crf.canon.fr>
References: <CABP7RbdBe-Xkx+CMvpN=_oNAqm6SyLyL+XNHRUKSqn8mjSDw1Q@mail.gmail.com> <CABkgnnW=Ve=9p2do5PncTVswTYCZqt-LMK50SYCKV1r8zEg=SQ@mail.gmail.com>
In-Reply-To: <CABkgnnW=Ve=9p2do5PncTVswTYCZqt-LMK50SYCKV1r8zEg=SQ@mail.gmail.com>
Accept-Language: en-US, fr-FR
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.20.6.135]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Received-SPF: none client-ip=194.2.158.67; envelope-from=Herve.Ruellan@crf.canon.fr; helo=inari-msr.crf.canon.fr
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-3.432, RP_MATCHES_RCVD=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UVfvx-0006Vj-Qr 5b2d237d24490dbe24a241aa89578499
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/6C71876BDCCD01488E70A2399529D5E516416AA8@ADELE.crf.canon.fr>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17600
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've got the feeling that we should limit in some way the number of promised streams: too many promised streams could hurt an intermediary.

One way to do this is to say that a PUSH_PROMISE creates a new stream. In this way it is counted against the SETTINGS_MAX_CONCURRENT_STREAMS. We would also have to mandate a client to half-close all PUSH_PROMISE streams.


While reading the current spec, my understanding on whether a PUSH_PROMISE created a new stream wandered back and forth, and I think some clarification could be useful.

In particular the first paragraph of 3.4.1:
"There is no coordination or shared action between the client and server required to create a stream. Rather, new streams are established by sending a frame that references a previously unused stream identifier."

The "Promised-Stream-ID" of the PUSH_PROMISE frame could be considered as being the reference to an unused stream identifier, therefore creating the stream.

The rest of 3.4.1 and 3.8.5 on the contrary say that a PUSH_PROMISE frame doesn't create a new stream.

I would propose the following edit to this first paragraph of 3.4.1:
"There is no coordination or shared action between the client and server required to create a stream. Rather, new streams are established by sending a frame that references in its "Stream Identifier" field a previously unused stream identifier."

Hervé.

> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: jeudi 25 avril 2013 21:26
> To: James M Snell
> Cc: ietf-http-wg@w3.org
> Subject: Re: Design Issue: Max Concurrent Streams Limit and Unidirectional
> Streams
> 
> On 25 April 2013 10:50, James M Snell <jasnell@gmail.com>; wrote:
> > https://github.com/http2/http2-spec/issues/78
> >...
> > If a client sets a limit of 4 concurrent streams, and the server
> >initiates 4 separate PUSH_PROMISE streams that the server half-closes
> >but that are never half-closed by the client, the server will not be
> >able to initiate new push streams for the duration of the session.
> 
> Yep, it's a problem.  We got rid of the unidirectional flag that addressed this.  I
> can't speak for others, but I was aware of the issue at the time, but I had a
> solution in mind.  That never got written down, partly because we didn't
> have this discussion :)
> 
> On first blush, the only way to avoid the problem is to expect the framing
> layer to be aware of what is going on above, but that's probably not sensible.
> But there's a better way:
> 
> Each stream has two separate state variables, each with three state
> values: no packet yet, open, half-closed.  Streams that have inbound ==
> open || outbound == open are "in use" and count toward the stream limit.
> Documenting this might help clarify how the accounting is done.
> 
> Importantly, this means that promised streams do not count toward the
> limit.  It does however also imply that implementations will need to be
> careful about how they allocate stream resources.  Pushes complicate that a
> little because the lifecycle of headers doesn't match stream lifecycles.  Again,
> I'd suggest an approach where implementations defer commitment of flow
> control buffers until the first flow-controlled frame arrives (memory pre-
> allocation might be advisable for performance reasons, but that would not be
> an actual
> commitment) and to ensure that any state for send and receive don't have
> the same lifecycle.