Re: WINDOW_UPDATE with streamid = 0 redundant?

On 2014-02-12 11:47, Daniel Sommermann wrote:
> Right, but as I understand it, the connection-level limit is meant to
> model the total buffering capability of the receiver. This amount of
> buffer space is only reduced when data on a particular stream is
> buffered. When that data is processed, we eventually send a
> WINDOW_UPDATE for that stream, but in reality, the receiver has also
> freed space in its total buffer budget by the same amount, so at some
> point, a WINDOW_UPDATE for the connection will follow for the same
> amount.
> 
> What I'm suggesting is that we make the connection-level WINDOW_UPDATE
> implicit with the stream-level WINDOW_UPDATE, since it fits with
> modeling the buffering capability of the remote side.


That does not follow.

Consider a proxy with multiple clients. The server connection window is 
unrelated to the windows for any given client, but interdependent.

1) Sending per-stream WINDOW_UPDATE of 0 when the client connection that 
stream is going to runs out of buffer space should not be allowed to 
starve all other clients by implying 0 on the connection buffer.

2) Sending a per-stream WINDOW_UPDATE of sum(client free buffer, server 
free buffer) allows the server to flood both the client and server 
connection buffers on the proxy with bytes for that one stream. 
Effectively blocking all other multiplexed traffic if that client 
happens to be slow. AND, implying false information about available the 
server connection buffer for other clients streams.

3) Sending a per-stream WINDOW_UPDATE of sum(client free buffer, server 
free buffer) along with a separate per-connection WINDOW_UPDATE of N 
server free buffer bytes allows recipients to know how much of the 
per-stream window is specific for the receiving hop buffer and to manage 
its sending of those bytes across streams.

Amos

Received on Tuesday, 11 February 2014 23:46:28 UTC