Re: Design: Adding ASSOCIATED_ONLY

[Jeff Pinner <[e-mail]>]

Thanks for finding that in the SPDY spec! You're right, I totally missed
reading that line.

I'm happy to wait on adding the flag but I would like to drop the
requirement that a server close all associated resources.

In the SPDY spec the life-cycles of the pushed resources were much more
tightly coupled with the original stream because there was no PUSH_PROMISE
so all streams had to be created while the original stream was still open.

With PUSH_PROMISE, the opening of the new streams can occur well after the
original stream closes so this behavior no longer makes and sense.




On Wed, Jun 19, 2013 at 12:50 PM, James M Snell <[e-mail]> wrote:

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