Re: Design: Adding ASSOCIATED_ONLY

[Mike Belshe <[e-mail]>]

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

The reason I don't find this interesting is because most sites will never
experience it.  You have to have multiple tabs able to share a connection
for prioritization to have any meaning.

So the use case you're referring to is:
   * user has multiple tabs open to the same site
   * the site does significant amount of background traffic which create
congestion for the foreground tab.

I think this is contrived.


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

If you knew today that 99% of the time the number of push streams you'd
have to cancel was 2, you wouldn't care.
On the other hand, if the typical number of push streams was 100000, you'd
care.

My gut tells me it will be closer to 2 to 100000, but you may disagree.
 Either way, its not a problem we have, and the "inefficiency" is not that
inefficient!

You can pack about 200 stream resets into a single TCP/ethernet packet
so.... isn't that good enough?

I think multiple RST frames is just fine.



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

Fair enough. Every detail we add is complexity which makes deployment and
adoption and compatibility more difficult.  If I had to prioritize over
deployability for the core features (multiplexing & the parts that have
been proved to work already) vs scalability for the
yet-never-used-in-production features, I choose the former.

Best,
Mike



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