Re: Design: Adding ASSOCIATED_ONLY

[James M Snell <[e-mail]>]

In the short term (for the implementer's draft) I'm perfectly fine
deferring this particular item, I just wanted to make sure the issue
was documented and available for discussion. The pull request has been
submitted and can easily sit there for a bit while we figure the other
items out :-) ...

On Wed, Jun 19, 2013 at 12:46 PM, Mike Belshe <[e-mail]> wrote:
>
>
>
> 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.
>
>
> And so it seems that even people that wrote that spec have forgotten! :-)
>
> But, given what we know now, I still think that sending RST_STREAM for each
> stream is sufficient and simplest.
>
> Mike
>
>
>>
>>
>> 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.
>>>> >>
>>>> >
>>>>
>>>
>>
>