Flow control for server push

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 02:27:24 UTC