Re: Design: Adding ASSOCIATED_ONLY

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

Received on Wednesday, 19 June 2013 18:27:13 UTC