Re: Design: Adding ASSOCIATED_ONLY

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