Re: HTTP/2 flow control <draft-ietf-httpbis-http2-17>

On 21/03/2015 5:50 a.m., Bob Briscoe wrote:
> Jason,
> 
> At 16:00 19/03/2015, Jason Greene wrote:
>> I think thats a good argument for why it’s not suitable for
>> rate-limiting relative to a variable bandwidth product of a single
>> connection (which i took as your use-case a).
> 
> I believe there is no need for an intermediate node to do flow control
> for individual streams. It does need to control the whole envelope
> within which all the streams are flowing through the proxy's app-layer
> buffer memory (e.g. due to a thick incoming pipe feeding a thin outgoing
> pipe). The best mechanism for controlling the app-layer buffer
> consumption of the aggregate connection is for the intermediate node to
> control the TCP receive window of the incoming stream.
> 
> That doesn't preclude the intermediate node passing on any per-stream
> flow control messages emanating from the ultimate receiver so that the
> ultimate sender controls each stream's rate, which will alter the
> balance between streams within the overall envelope at the proxy.
> 
> I explained all this in my review.

You seem to not be considering the common case where multiple incoming
pipes potentially match or exceed the size of the pipe they are being
multiplexed to.

Passing the WINDOW_UPDATE from clients to server pipes as-is has great
potential for HOL blocking at the server if any one of the clients
requests a large object with large window size.

Assiging a dedicated Nth of the server pipe to each client leads to
under-utilization if any of the clients pauses. And is very difficult to
guage in advance of N clients existing.

These also happen in reverse when one client fetches from N servers.

And can happen simultaneously in both directions in a multiplexed mesh
of connections. So that server X flooding its connection to client B can
fill client B's pipe and prevent server Y being able to deliver some
frames for client-B which HOL-block server Y from sending client A's
response.


The HTTP/2 scheme allows the intermediary to dynamically offer or
withhold window space/credits to prevent any given stream causing those
problems.


Amos

Received on Friday, 20 March 2015 19:05:26 UTC