Re: Design: Adding ASSOCIATED_ONLY

[Mike Belshe <[e-mail]>]

On Wed, Jun 19, 2013 at 12:41 PM, William Chan (陈智昌)
<[e-mail]>wrote:

> 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 <[e-mail]> 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 <[e-mail]>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 <[e-mail]> 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 <
>>> [e-mail]>
>>> > wrote:
>>> >>
>>> >> On 19 June 2013 10:56, James M Snell <[e-mail]> 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.
>>> >>
>>> >
>>>
>>>
>>
>