Re: Flow control for server push

Hi Martin,

On Mon, May 02, 2016 at 12:26:55PM +1000, Martin Thomson wrote:
> There is no flow control for server pushes that don't include data.
(...)
> 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.

I think that if the purpose is to protect the client against a huge amount
of pushes, #1 would do a pretty good job and makes sense in general. It
more or less means that any agent supporting push will have to be prepared
to allocate resources to deal with these responses, and that it will sometimes
be aware of some limits. In fact SETTINGS_ENABLE_PUSH could have been a
limit instead of a bit, since not supporting push is equivalent to setting
its limit to zero.

However if the purpose is to limit network usage or protocol processing
work, then I think that we could communicate a limit on the number of
response headers. It may seem awkward at first, but over the long term
it may prove useful for a variety of purposes (eg: I'm not a browser, I
don't care about a lot of things, please be short). Then the server would
have to prevent itself from sending more pushes if the cumulated number
of push_promise+response headers reaches a limit. The limit would be used
as a budget, refilled with each request. For sure some header fields are
encoded as a single byte while others take 50 bytes, but their number does
not vary much and their average size remains more or less stable between
subsequent requests/responses over a same connection. Thus a client could
say "don't flood me with more than 200 headers fields at once" and will
know that it'll get a few push responses at best, representing at best a
few TCP segments. If I'm focusing on the number of header fields instead
of their encoded size, it's because it's significantly harder to consider
the encoding size before deciding to encode (we had an endless discussion
here regarding this in the past resulting in headers not being accounted
for the flow control).

Just my few cents,
Willy

Received on Monday, 2 May 2016 05:21:01 UTC