Resent-Date: Tue, 23 Jul 2013 22:21:46 +0000
Resent-Message-Id: <E1V1kxm-0007Wo-HQ@frink.w3.org>
MIME-Version: 1.0
In-Reply-To: <CABkgnnWx5d_3U+tFQYG68+NCGC3Q2Hfm_PD0hgALeawb+PY-ZA@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>
Date: Tue, 23 Jul 2013 15:21:09 -0700
Message-ID: <CAP+FsNfauVPhGZH31_LFeQKOuPF0KcYKp7U4qMBtDUsv-Ja-cQ@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=e89a8ff25454bac71b04e23535ff
Received-SPF: pass client-ip=209.85.214.182; envelope-from=grmocg@gmail.com;
 helo=mail-ob0-f182.google.com
Subject: Re: MAX_CONCURRENT_STREAMS=0 and PUSH_PROMISE
Archived-At: <http://www.w3.org/mid/CAP+FsNfauVPhGZH31_LFeQKOuPF0KcYKp7U4qMBtDUsv-Ja-cQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

--e89a8ff25454bac71b04e23535ff
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jul 23, 2013 at 3:13 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 23 July 2013 14:32, Roberto Peon <grmocg@gmail.com> wrote:
> > Even if push promises were limited by some configuration, changes to that
> > configuration can cause this condition to occur. Thus, clients must be
> able
> > to handle PUSH_PROMISE frames by at least discarding them.
>
> I'm a little concerned by the suggestion that PUSH_PROMISE can simply
> be discarded.  It creates a reservation for a stream, which
> necessarily creates state in the client.
>

Well, the alternative is to crash :)
And by discard, I mean RST the reserved stream.
RSTing a reserved stream that the client has no intention of listening to
seems reasonable.
Market forces will force servers to mostly not do stupid crud w.r.t.
sending PUSH_PROMISE when the client really won't use it.
I could imagine smart clients that, wishing to conserve bandwidth, still
want the server to use PUSH_PROMISE like things instead of inlining, but
are happy to leave the potential latency savings on the table.
Such clients want to see what the server is advertising, even when the
number of pushed streams is limited to zero.

Also, remember that a server may push a cache validation/invalidation...


> If, as you point out, the client could lift this limit from zero, is
> there some corresponding expectation that the client remembers all of
> these reserved streams so that they can enter the right state at the
> point that the server decides to exercise the reservation?  Without
> any limits on number or the time that a reservation can remain
> outstanding, the only rational response a client implementer has is to
> reset those streams, if they don't want unbounded state commitment
> (even if it is a relatively small allocation for each stream - 2 bits
> in the best case - anything greater than zero could be problematic).
>
>
I believe the client should remember everything it hasn't RST.


> We've done a lot to protect resources on a server, but I don't think
> that a client is able to limit the commitments it has to make in order
> to continue to use a connection.
>

Given the above, do you still feel that way? :)
-=R

--e89a8ff25454bac71b04e23535ff
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Jul 23, 2013 at 3:13 PM, Martin Thomson <span dir=3D"ltr">&=
lt;<a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.tho=
mson@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 14:32, Rob=
erto Peon &lt;<a href=3D"mailto:grmocg@gmail.com">grmocg@gmail.com</a>&gt; =
wrote:<br>

&gt; Even if push promises were limited by some configuration, changes to t=
hat<br>
&gt; configuration can cause this condition to occur. Thus, clients must be=
 able<br>
&gt; to handle PUSH_PROMISE frames by at least discarding them.<br>
<br>
</div>I&#39;m a little concerned by the suggestion that PUSH_PROMISE can si=
mply<br>
be discarded. =A0It creates a reservation for a stream, which<br>
necessarily creates state in the client.<br></blockquote><div><br></div><di=
v>Well, the alternative is to crash :)</div><div>And by discard, I mean RST=
 the reserved stream.</div><div>RSTing a reserved stream that the client ha=
s no intention of listening to seems reasonable.</div>
<div>Market forces will force servers to mostly not do stupid crud w.r.t. s=
ending PUSH_PROMISE when the client really won&#39;t use it.</div><div>I co=
uld imagine smart clients that, wishing to conserve bandwidth, still want t=
he server to use PUSH_PROMISE like things instead of inlining, but are happ=
y to leave the potential latency savings on the table.</div>
<div>Such clients want to see what the server is advertising, even when the=
 number of pushed streams is limited to zero.</div><div><br></div><div>Also=
, remember that a server may push a cache validation/invalidation...</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
<br>
If, as you point out, the client could lift this limit from zero, is<br>
there some corresponding expectation that the client remembers all of<br>
these reserved streams so that they can enter the right state at the<br>
point that the server decides to exercise the reservation? =A0Without<br>
any limits on number or the time that a reservation can remain<br>
outstanding, the only rational response a client implementer has is to<br>
reset those streams, if they don&#39;t want unbounded state commitment<br>
(even if it is a relatively small allocation for each stream - 2 bits<br>
in the best case - anything greater than zero could be problematic).<br>
<br></blockquote><div><br></div><div>I believe the client should remember e=
verything it hasn&#39;t RST.</div><div>=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">

We&#39;ve done a lot to protect resources on a server, but I don&#39;t thin=
k<br>
that a client is able to limit the commitments it has to make in order<br>
to continue to use a connection.<br></blockquote><div><br></div><div>Given =
the above, do you still feel that way? :)</div><div>-=3DR=A0<br></div></div=
><br></div></div>

--e89a8ff25454bac71b04e23535ff--