Re: MAX_CONCURRENT_STREAMS=0 and PUSH_PROMISE

For reasons of DoS prevention, a proxy may wish to throttle the push'd
entity-body data by limiting the concurrency without messing around with
the flow-control (since that would also slow down the main-resource
transfer, unless on separate connections).
As an example DoS attack, a client could start out a connection with push
enabled, then disable it in an attempt to run the proxy out of memory/make
the proxy do useless work.
The proxy may still wish to get the push-promise metadata, however, as it
both indicates what work might have been done (so it can anaylze the effect
of things), and as a first-order effect, allows the proxy to determine what
elements it can serve from cache instead of spending CPU on IO, which is
pretty expensive.
-=R




On Tue, Jul 23, 2013 at 4:43 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 23 July 2013 15:38, Roberto Peon <grmocg@gmail.com> wrote:
> > I'm a proxy guy, actually.
>
> Everyone writing a stack deals with these problems at some level.
> Some will just have to worry about concurrency and queuing at a
> different layer, that's all :)
>
> After some offline discussion, I understand that we still (perhaps
> grudgingly) need a way to signal that a client is unwilling to receive
> pushes.  However, that operates at two levels:
> a) a client is unwilling to receive pushes, ever
> b) a client is currently unwilling to receive pushes, but will accept
> promises (i.e., the requests) in the expectation that it can receive
> the corresponding responses in time
>
> The concern here is that setting the maximum concurrent streams to
> zero could be used to communicate either situation, and that sometimes
> the distinction is important.
>
> I think that onus is on Roberto to more effectively motivate the need
> for this distinction.
>
> If indeed we agree that the two cases are distinct, then we probably
> need to consider ways to communicate this distinction effectively.  A
> separate setting that expressly disables push promise or limits the
> number of promises might work.
>