Resent-Date: Wed, 24 Jul 2013 00:44:13 +0000
Resent-Message-Id: <E1V1nBd-0007nm-7C@frink.w3.org>
MIME-Version: 1.0
In-Reply-To: <CABkgnnUK45jVj1f=QuJnE7w3gSWJZ_jAPq=87SLyvyGYxUt0kw@mail.gmail.com>
References: <CA+KJw_5PcUxBiUnQ00=G2C4Q6MnaB=hpNDk+9eTeZMs3Lz-CpA@mail.gmail.com>
 <CAP+FsNf7YBDfO_=fW7nPHXdUi0F+0+4S2AUm_T2gHtqYhER8MA@mail.gmail.com>
 <20130723190419.GA25817@LK-Perkele-VII>
 <CAP+FsNc5tef8WRCaH-_6z5se=vVPscSQ3+GfEF0T02q8oKq6WA@mail.gmail.com>
 <CABkgnnWx5d_3U+tFQYG68+NCGC3Q2Hfm_PD0hgALeawb+PY-ZA@mail.gmail.com>
 <CAP+FsNfauVPhGZH31_LFeQKOuPF0KcYKp7U4qMBtDUsv-Ja-cQ@mail.gmail.com>
 <CABkgnnV7ZZ_MWeuP2cDKombNWJJahES02XYTJh0OJY7yo17ytQ@mail.gmail.com>
 <CAP+FsNfgEqP2dwHsG0RD2ZizpVNw=98mTJ=1Q33b3UK8NdhjYA@mail.gmail.com>
 <CABkgnnUK45jVj1f=QuJnE7w3gSWJZ_jAPq=87SLyvyGYxUt0kw@mail.gmail.com>
Date: Tue, 23 Jul 2013 17:43:35 -0700
Message-ID: <CAP+FsNdrNYK7ZWJS79JkWewbuu82VD5BbbTiRkw9-bnZbDvHvA@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>,
 =?ISO-8859-1?B?R+Fib3IgTW9sbuFy?= <gabor.molnar@sch.bme.hu>,
 HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=047d7b2e4c4624e5b504e23733ee
Received-SPF: pass client-ip=209.85.219.44; envelope-from=grmocg@gmail.com;
 helo=mail-oa0-f44.google.com
Subject: Re: MAX_CONCURRENT_STREAMS=0 and PUSH_PROMISE
Archived-At: <http://www.w3.org/mid/CAP+FsNdrNYK7ZWJS79JkWewbuu82VD5BbbTiRkw9-bnZbDvHvA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

--047d7b2e4c4624e5b504e23733ee
Content-Type: text/plain; charset=ISO-8859-1

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.
>

--047d7b2e4c4624e5b504e23733ee
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">For reasons of DoS prevention, a proxy may wish to throttl=
e the push&#39;d entity-body data by limiting the concurrency without messi=
ng around with the flow-control (since that would also slow down the main-r=
esource transfer, unless on separate connections).<div>
As an example DoS attack, a client could start out a connection with push e=
nabled, then disable it in an attempt to run the proxy out of memory/make t=
he proxy do useless work.</div><div>The proxy may still wish to get the pus=
h-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 inste=
ad of spending CPU on IO, which is pretty expensive.</div>
<div>-=3DR<br></div><div><div><br></div><div><br></div></div></div><div cla=
ss=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Jul 23, 2013 =
at 4:43 PM, Martin Thomson <span dir=3D"ltr">&lt;<a href=3D"mailto:martin.t=
homson@gmail.com" target=3D"_blank">martin.thomson@gmail.com</a>&gt;</span>=
 wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 23 July 2013 15:38, Rob=
erto Peon &lt;<a href=3D"mailto:grmocg@gmail.com">grmocg@gmail.com</a>&gt; =
wrote:<br>

&gt; I&#39;m a proxy guy, actually.<br>
<br>
</div>Everyone writing a stack deals with these problems at some level.<br>
Some will just have to worry about concurrency and queuing at a<br>
different layer, that&#39;s all :)<br>
<br>
After some offline discussion, I understand that we still (perhaps<br>
grudgingly) need a way to signal that a client is unwilling to receive<br>
pushes. =A0However, that operates at two levels:<br>
a) a client is unwilling to receive pushes, ever<br>
b) a client is currently unwilling to receive pushes, but will accept<br>
promises (i.e., the requests) in the expectation that it can receive<br>
the corresponding responses in time<br>
<br>
The concern here is that setting the maximum concurrent streams to<br>
zero could be used to communicate either situation, and that sometimes<br>
the distinction is important.<br>
<br>
I think that onus is on Roberto to more effectively motivate the need<br>
for this distinction.<br>
<br>
If indeed we agree that the two cases are distinct, then we probably<br>
need to consider ways to communicate this distinction effectively. =A0A<br>
separate setting that expressly disables push promise or limits the<br>
number of promises might work.<br>
</blockquote></div><br></div>

--047d7b2e4c4624e5b504e23733ee--