Re: Design: Adding ASSOCIATED_ONLY

[Amos Jeffries <[e-mail]>]

On 20/06/2013 7:30 a.m., Mike Belshe wrote:
>
>
>
> On Wed, Jun 19, 2013 at 11:26 AM, James M Snell <[e-mail] 
> <mailto:[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.

Possibly. I can also think of a very likely scenario which this will 
cause problems for.

1) Middleware which is caching the pushed resources will not be happy to 
have them terminated incompletely received even if the user has closed 
the main non-cacheable stream.

2) Middleware serving the pushed objects up to multiple clients in 
parallel will be quite put out to have the streams discontinued 
underneath it simply because they were associated as secondary resources 
with _one_ particular client who went away.

Per-stream reset frames can be recieved and the reset easily dropped if 
the stream is shared by multiple active clients or otherwise desired to 
be kept going. Retaining additional state on every stream to record the 
associations it has to all other streams is an unwelcome complexity.

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

Same here.

Amos