Re: Flow control for server push

Hi Martin,

On Mon, May 02, 2016 at 03:36:14PM +1000, Martin Thomson wrote:
> Hi Willy,
> 
> On 2 May 2016 at 15:20, Willy Tarreau <w@1wt.eu> wrote:
> > 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.
> 
> That opportunity passed already, so we'd be making a new setting.

Yes definitely.

> > 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.
> 
> The question I have is whether this is a good proxy for the thing
> we're concerned about.

My gut feeling is that it could be. Pretty much inaccurate but at least
enforces *some* limits. I don't have numbers unfortunately.

> That's the problem I have with any option that
> attempts to establish a budget.  Are we budgeting for the right thing?

We're definitely not but I guess it could be representative enough of
a number of requests and/or on-wire volume in a given environment.

> I agree that we could rathole indefinitely on the question of bytes
> (pre-encoding, post-encoding?) vs messages. But is the additional
> granularity of header field count adding value?

Well, for one thing it would clearly be inexact/inaccurate so would
probably be used more as a hint than anything else. I tend to think
that there's an order of magnitude between the request count and the
header field count, and very small order of magnitude between the
header field count and the on-wire byte count. All in all we'd have
a metric which is comprised between the two we can be interested in
(requests and bytes), which is related to the two and more tied to
each of them than each of them is tied to the other one. Hence why
I suspect it could provide good enough results to address both goals.

> (I'm purposefully ignoring secondary benefits of your proposal here: I
> really wish that servers would have some incentive to stop sending me
> useless headers, e.g., see slide 15 of [1].)
> 
> My experience suggests that the incremental effort of processing an
> extra header field is negligible, since most header fields are
> basically ignored. Whereas the push itself implies a direct and
> tangible cost.

I agree. My purpose is not to really limit the number of header fields,
but clearly to use them as a single proxy for both metrics that people
may be interested in. If we only address request count, some people
will complain that network traffic varies too much for a given value,
and if we fix network bytes, some people will explain that it allows
between 1 and 1000 requests and cannot serve to limit them.

Or we can decide to limit both exactly and we'd have again the issue of
the unknown output size.

At best it would be used as a courtesy setting : "please try not to send
me more than XYZ header fields, I won't care if you're slightly wrong".
A server could easily decide that a request is 10 header fields and
divide this value by 10 to limit the pushes. A client could decide that
a field is 4.37 bytes and divide a congestion window by this to limit
buffering.

That's just an idea, I know it can sound surprizing and will not be
shocked if people tell me it's bullshit, I just think it could overall
work pretty well :-)

Cheers,
Willy

Received on Monday, 2 May 2016 12:23:04 UTC