Re: Flow control for server push

I think as a measure of last resort the client can close the TCP 
connection and is then save from further pushes. Currently the number of 
subresources of a page seems to be unlimited, for example a simple 
script can generate unlimited number of transactions. This is 
independent if push or pull is used. Wouldn't it be more appropriate to 
limit the number of subresources? Even the number of connections to 
other domains is not limited. What about limiting secure request to be 
handled end to end secure 1:1, e.g. a single connection would be enough 
to retrieve the complete page.

Option 1 seems to limit the number of subresources only for push. Option 
2 limits the number of concurrent pushes like it is currently attempted. 
This allows the client to slow down the server but doesn't limit the 
total number of pushes on a page. Is this the what you want to achieve? 
Btw. the WAP WSP push has this option (confirmed push) together with a 
limit on the number of concurrent pushes.

Regards,

Roland


Am 02.05.2016 um 04:26 schrieb Martin Thomson:
> An issue has come up in webpush that I think bears some discussion here.
>
> There is no flow control for server pushes that don't include data.
>
> As long as a server push contains no data, there is no way to
> practically limit to how many pushes can be generated by the server.
> We have several mechanisms that might have worked, but none of these
> actually engage in this case:
>
>    - Concurrent stream limit: PUSH_PROMISE causes the promised stream
> to enter a reserved state, which is not counted toward the stream
> limit.  The HEADERS on that stream that completes the push will
> immediately end the stream, so the concurrent streams count never
> really increases.
>
>   - Flow control: PUSH_PROMISE and HEADERS are the only messages that
> are sent in this case.  Flow control for the affected stream never
> enters the picture, and connection-level flow control isn't touched
> either because no message payloads are sent.
>
>   - TCP receive window: As a measure of last resort, the TCP receive
> window will eventually close.  However, the best guidance we've given
> implementations is to drain the TCP receive window as quickly as
> possible to avoid head of line blocking and other stalling problems.
> That means that a good implementation will leave this window as wide
> open as possible.  In that case, the only effective limit on the rate
> of inbound pushes will be the bandwidth of the connection bottleneck.
>
> Given effective compression of the PUSH_PROMISE and HEADERS, the
> number of actual pushes that could be generated is likely very high,
> even if each one contains unique information.  This is not likely to
> be a problem for web browsing cases, but it could be a problem for
> other applications using HTTP.
>
> The only mitigation we currently have is application-specific changes,
> but I think that isn't ideal.  If things like pushing 304 are to
> become more widespread, then I think that we might need to do
> something about this.
>
> Two options have been proposed:
>
> 1. A header field that limits the number of pushes in response to any
> given request, maybe something that builds on Herve's push policy
> work.
>
> 2. Explicit acknowledgment of each push, plus separate configuration
> for the maximum number of unacknowledged pushes.  This probably needs
> to be an optional, negotiated feature.
>
> I'm interested in what people think here.
>

Received on Monday, 2 May 2016 09:55:21 UTC