Re: Flow control for server push

On Mon, 2 May 2016 at 15:27 Willy Tarreau <w@1wt.eu> wrote:

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

#1 would also be a solution to an issue I brought up a while ago, which is
there is no way to enable/disable push on a per request basis, with this
could just set it to zero for requests that do not support push.


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

I think this would be very problematic to implement on the server side. In
general the code that generates a push has no idea how big the headers on
the pushed responses will be, and neither does the transport layer that
handles HTTP/2.

In many cases the only way to know how big a responses headers will be is
to do the work and generate it, which could result in the server having to
generate the page then discard it due to it being too big.

Stuart


>
> Just my few cents,
> Willy
>
>
>