Re: Design: Adding ASSOCIATED_ONLY

[Jeff Pinner <[e-mail]>]

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