Re: Design: Adding ASSOCIATED_ONLY
William Chan (陈智昌) <willchan@chromium.org> Wed, 19 June 2013 19:43 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 15C2721F9E94 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 19 Jun 2013 12:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.676
X-Spam-Level:
X-Spam-Status: No, score=-9.676 tagged_above=-999 required=5 tests=[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 22vDYrOwi+Il for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 19 Jun 2013 12:43:17 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id A212921F9E89 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 19 Jun 2013 12:43:12 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UpOH7-0007tQ-OY for ietf-http-wg-dist@listhub.w3.org; Wed, 19 Jun 2013 19:42:37 +0000
Resent-Date: Wed, 19 Jun 2013 19:42:37 +0000
Resent-Message-Id: <E1UpOH7-0007tQ-OY@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <willchan@google.com>) id 1UpOGu-0007sJ-3b for ietf-http-wg@listhub.w3.org; Wed, 19 Jun 2013 19:42:24 +0000
Received: from mail-pb0-f46.google.com ([209.85.160.46]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UpOGs-00032J-Pr for ietf-http-wg@w3.org; Wed, 19 Jun 2013 19:42:23 +0000
Received: by mail-pb0-f46.google.com with SMTP id rq2so5396592pbb.33 for <ietf-http-wg@w3.org>; Wed, 19 Jun 2013 12:41:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=emnHDAHx82wotcPyCgG2NcthsTuC4wDBrxgEUVZvZIY=; b=PfykzyZKJtTvKa+9ZIqoOMYe2rSUXE9YCMGx68k5EaiMENzfPEhOxGKXvEdGPOwOHf S52orXBOg3z9+lYldWlMwlYiCm6cLyuZ3lnto3Hnn/snXD+XVak4f5bLuRtVaMccBuX+ P0j0oyYqyI+mvGw/q3l/PmP9xHv+5xvGDBCBdXnL69FX+LkoFq9FWjYXnHLp1+vekz+Q 5OyyY9VSQ11H4+7iRNnCcZb69HxpijA1WPoSkMYhjKeAviS49eLT6Vu4WhmqVgW52mNP 7OHzlCpKFpOnrx+gKn8U3UgRpaojgKTo1GGnUHGBiRZOEHzl51ptoKO+pKiWIrhOwcNE dqmg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=emnHDAHx82wotcPyCgG2NcthsTuC4wDBrxgEUVZvZIY=; b=ivmcYqpgj3W9yUNM8SkxpUHrmbgoVWnE1CwimFpVQpwIxXNtkBoep8hV2/GNfbOvmx jR/XsrRzPpLLggCnqjXexbmkOAKImDmZhbhIWHL/20cxjhYcFVHXZYZqYzQ+DMLk+nCD Cv1N8Ty09WaGi/RtJI9taiawtEPGERqc2kzRY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=emnHDAHx82wotcPyCgG2NcthsTuC4wDBrxgEUVZvZIY=; b=DcO76lGTowG6HLPH3M3Pv8URfOhqsPziZ7W+56QcIH5BMUm94Cze+cexfRckSmCuSy 4XAzhSrazhwsI59X1rYQkRKolFO+fkTRN3ijC0kV2H0GiXVjWmS8FU9SPL0cc3d/t5dU 7Dm2KZ16pOlUW0gEUukCHriPtmP9c1dkHpcg0WU6tgV4txO2vApUOku5LNSfWEfIh3bN VcSbZernJGfi3o8QL6N+YreOdELxdAjiElsTXj1+Qi99KaFAed84RIurdUykiM0L2DIG 0JXhf0799lgDEoBAJoB8pteCagq6aqJVS+tOCBJ17fWciqPrJ1BUJC/HtJLq5R0y712J mmiw==
MIME-Version: 1.0
X-Received: by 10.66.165.97 with SMTP id yx1mr8101832pab.82.1371670916248; Wed, 19 Jun 2013 12:41:56 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.68.21.135 with HTTP; Wed, 19 Jun 2013 12:41:56 -0700 (PDT)
In-Reply-To: <CA+pLO_hAH4MhFUZTnO9wXP89gLzRgikH7rR60NQOeJ2C5zVDnw@mail.gmail.com>
References: <CABP7Rbe29dHp3LZuWEMKJdVEkuHW2jOUK0sSyBuh6PFnq=9Z1A@mail.gmail.com> <CABkgnnUKnborWAtuxwEvWx7wR=JYdOTvWHbpPd6NJ5kXK0Sw9A@mail.gmail.com> <CABaLYCuhs5zmMHD9D7qNEhhUpvzWf1THHOjS5-vTu6soMUqALA@mail.gmail.com> <CABP7RbfreVJv=RZga+Y6iHxsOhmdheyjcvZ3dTNgW3drg4j2iw@mail.gmail.com> <CA+pLO_hAH4MhFUZTnO9wXP89gLzRgikH7rR60NQOeJ2C5zVDnw@mail.gmail.com>
Date: Wed, 19 Jun 2013 12:41:56 -0700
X-Google-Sender-Auth: pvY6bLX_piV-n16E6igrQHZfCvM
Message-ID: <CAA4WUYgTw05Y+A6MEe2dyTSTZ5-6C6-Wuwx5ohVe8EsZuKxHtg@mail.gmail.com>
From: "William Chan (陈智昌)" <willchan@chromium.org>
To: Jeff Pinner <jpinner@twitter.com>
Cc: James M Snell <jasnell@gmail.com>, Mike Belshe <mike@belshe.com>, Martin Thomson <martin.thomson@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="047d7b86c528b64ceb04df8705c3"
X-Gm-Message-State: ALoCoQkhPyUcKg7pCTeKIUlgeIbfCW8ClL+Xl/bVpRKCUUHLbL0vlpv7iRDuwtNpM+7oAahdcFDRBGiOIOJCO3ZHvCIaBTXYZlkDW3y2ri508Pma40cTs+2hHQXRU+XLAa3u/hCSBRbyOaB/Ek2tsBLYMYiSHbO2mjArspNw84ddP5Eo+AzagmdVPBva/kYDrKenhDL1fPG8
Received-SPF: pass client-ip=209.85.160.46; envelope-from=willchan@google.com; helo=mail-pb0-f46.google.com
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: AWL=-2.071, 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=-1.276, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UpOGs-00032J-Pr 4fcb4c2af2134325e8f72cee85c9808d
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design: Adding ASSOCIATED_ONLY
Archived-At: <http://www.w3.org/mid/CAA4WUYgTw05Y+A6MEe2dyTSTZ5-6C6-Wuwx5ohVe8EsZuKxHtg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18301
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>
It's vague in the SPDY 3 spec but is definitely there, just not in the RST_STREAM section. See http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3#TOC-3.3.2-Client-implementation : "To cancel all server push streams related to a request, the client may issue a stream error (Section 2.4.2) with error code CANCEL on the associated-stream-id. By cancelling that stream, the server MUST immediately stop sending frames for any streams with in-association-to for the original stream." Patrick's right and no implementation of server push has read that section. I raised this point at least twice at the interim meeting. Roberto's counterpoint (from the meeting) is that adding a flag for this makes it explicit, so it won't be as easily forgotten. I'm personally lukewarm on this and would rather be explicit and send all the RST_STREAMs. But I don't have a strong opinion here. On Wed, Jun 19, 2013 at 11:43 AM, Jeff Pinner <jpinner@twitter.com> wrote: > I'm going to put the PRIORITY discussion aside for a second and only > comment on RST_STREAMs. > > I believe Patrick is correct -- I don't think anyone who implemented SPDY > implemented RST_STREAM as closing all associated streams. But IIRC that's > because that isn't how it is specified in the SPDY/3 spec. SPDY/3 Section > 3.3 mentions Push and RST_STREAM but only talks about issuing a RST on the > pushed Stream-ID. > > I think the requirement was added for HTTP/2 and isn't desirable. This was > the reason we considered adding the ASSOCIATED flag in the first place. We > wanted to clarify this issue and provide a mechanism while dropping the new > requirement. > > > > > > > On Wed, Jun 19, 2013 at 11:26 AM, James M Snell <jasnell@gmail.com> wrote: > >> Not very contrived use case: Switching away from one browser tab with >> N-active push streams. Without this, we would need to send PRIORITY >> frames for each individual pushed stream, which is bad. >> >> At the interim, as part of the updated lifecycle discussions, we all >> seemed to agree that the lifecycle of push streams was independent of >> the originating stream, given that, if I close a browser tab with >> N-active push streams, I would have to send a separate RST_STREAM for >> every push stream in addition to the originating stream. This >> eliminates that need. >> >> You're right that this would be unnecessary if push was disabled, but >> we are building push into the base protocol so we have to be able to >> efficiently handle the case where push is not disabled. There's no way >> around that. >> >> While I am quite sympathetic to the "let's not add stuff we really >> don't need" point of view, ASSOCIATED_ONLY makes a lot of sense in my >> opinion, and would make it easier and more efficient to implement the >> "independent stream lifecycle" notion. >> >> On Wed, Jun 19, 2013 at 11:13 AM, Mike Belshe <mike@belshe.com> wrote: >> > Is there a specific use case that needs this? >> > >> > I suspect there are two camps of browsers: >> > - those that disable push >> > - those that don't disable push >> > >> > If you disabled push, then these aren't needed. >> > >> > If you didn't disable push, do you really need to be able to deal with >> batch >> > operations on associated streams? (I know we can contrive a use-case >> on the >> > fly right now - that is always possible. But if we don't *really* need >> it, >> > its just more stuff in the protocol I'd rather omit until we really know >> > that it is needed.) >> > >> > Thanks, >> > Mike >> > >> > >> > >> > On Wed, Jun 19, 2013 at 11:07 AM, Martin Thomson < >> martin.thomson@gmail.com> >> > wrote: >> >> >> >> On 19 June 2013 10:56, James M Snell <jasnell@gmail.com> wrote: >> >> > https://github.com/http2/http2-spec/pull/144 >> >> > >> >> > This was a technical change brought up and discussed as part of the >> >> > "layering taskforce" breakout but was never discussed in the larger >> >> > interim discussions. >> >> > >> >> > Essentially, this PR would add an "ASSOCIATED_ONLY" flag to PRIORITY >> >> > and RST_STREAM frames that would allow terminating and reprioritizing >> >> > promised streams as a group. >> >> > >> >> > Sending PRIORITY(ASSOCIATED_ONLY) would ONLY set the priority for >> >> > associated streams, not the referenced stream. >> >> > >> >> > Sending RST_STREAM(ASSOCIATED_ONLY) would terminate ONLY the >> >> > associated streams, not the referenced stream. >> >> > >> >> > Without this, we would have to send PRIORITY and RST_STREAM for each >> >> > individual associated stream, which is obviously quite inefficient. >> >> >> >> What James omits is: >> >> >> >> RST_STREAM is currently specified to terminate all associated streams >> >> in addition to the parent stream. This would remove this coupling, >> >> which is considered by some to be problematic. >> >> >> >> It's not possible to reprioritise associated streams as a group. We >> >> did agree that associated streams would inherit a priority that is >> >> lower (by one) than the parent stream. As it stands, changing all of >> >> them requires first discovering the stream ID that will be used, then >> >> sending individual PRIORITY frames for each. >> >> >> >> There's not a lot of experience with this area of the specification. >> >> >> > >> >> >
- Re: Design: Adding ASSOCIATED_ONLY Jeff Pinner
- Design: Adding ASSOCIATED_ONLY James M Snell
- Re: Design: Adding ASSOCIATED_ONLY Martin Thomson
- Re: Design: Adding ASSOCIATED_ONLY Mike Belshe
- Re: Design: Adding ASSOCIATED_ONLY Patrick McManus
- Re: Design: Adding ASSOCIATED_ONLY James M Snell
- Re: Design: Adding ASSOCIATED_ONLY Mike Belshe
- Re: Design: Adding ASSOCIATED_ONLY William Chan (陈智昌)
- Re: Design: Adding ASSOCIATED_ONLY Mike Belshe
- Re: Design: Adding ASSOCIATED_ONLY Mike Belshe
- Re: Design: Adding ASSOCIATED_ONLY James M Snell
- Re: Design: Adding ASSOCIATED_ONLY Jeff Pinner
- Re: Design: Adding ASSOCIATED_ONLY Patrick McManus
- Re: Design: Adding ASSOCIATED_ONLY Martin Thomson
- Re: Design: Adding ASSOCIATED_ONLY Mike Belshe
- Re: Design: Adding ASSOCIATED_ONLY Amos Jeffries
- Re: Design: Adding ASSOCIATED_ONLY James M Snell
- Re: Design: Adding ASSOCIATED_ONLY Amos Jeffries