- From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Date: Fri, 22 Aug 2014 17:49:40 +0300
- To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
On Fri, Aug 22, 2014 at 01:42:44PM +0900, Tatsuhiro Tsujikawa wrote: > 2014/08/22 0:53 "Amos Jeffries" <squid3@treenet.co.nz>: > > > > 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. What if client connection gets into state where connection window is zero, but stream windows are nonzero? If the stream windows on proxy are nonzero and the proxy connection window is nonzero, those streams are candidates for sending for backend. Except that the proxy can't forward that data (due to the zero connnection window to the client). And if such buffered data is substracted from proxy connection window, the window can pretty quickly shrink to zero, stalling all streams. Now, it isn't only the framing-layer connection window. There is TCP connection window as well. So even if framing connection window is nonzero, it may not be possible to send data. 100% buffering for all streams would obviously get around this, but that could use lots of memory. -Ilari
Received on Friday, 22 August 2014 14:50:07 UTC