Re: h2 proxy and connection flow control

2014/08/22 0:53 "Amos Jeffries" <squid3@treenet.co.nz>:
>
> On 22/08/2014 2:56 a.m., Tatsuhiro Tsujikawa wrote:
> > On Thu, Aug 21, 2014 at 11:12 PM, Patrick McManus wrote:
> >
> >>
> >>
> >>
> >> On Thu, Aug 21, 2014 at 10:09 AM, Tatsuhiro Tsujikawa wrote:
> >>
> >>>
> >>>
> >>>
> >>> ​In this scenario, proxy has no room to expand. Therefore I wrote
that​
> >>> all streams on backend connections are stalled.
> >>>
> >>>
> >> This is my point. If the proxy really has no room to expand (its out of
> >> ram) - then we've got a resource problem not a protocol problem. If it
does
> >> have more ram, then just use the protocol to open the window to match
the
> >> resources available.
> >>
> >>
> > ​So if there is no ram to spend for that connection, is stalling entire
> > connection inevitable consequence (and we should not care about it)? ​
> > Connection flow control is limit the memory commitment for proxy then
why
> > do we need to extend it in the response to a client behavior?
>
> For the browser connection the browser has explicitly indicated with its
> matching stream and connection windows that it is happy for the other
> streams to stall.
> The proxy should not allow itself to stall the server connection. Namely
> by reducing its window on all streams from that client as soon as it
> detects the clients connection window getting low.
>
> Proxies have to operate under the assumption that a number of other
> clients and/or streams will be arriving very soon and need to use
> resources. So no resource can be allocated beyond what can be passed on
> quickly.

This is great hint.  The failure I made is always update stream and
connection window at the same time. It should be updated independently. So
when Frontend Proxy sends data to Browser, it only sends connection level
WINDOW_UPDATE to Backend.  Stream level WINDOW_UPDATE is deferred until
Browser sends strean level WINDOW_UPDATE for data which is not acked.
Obviously this requires that Frontend Proxy's stream window is not larger
than Browser's.

Best regards,
Tatsuhiro Tsujikawa

>
> Amos
>
>