Re: Question on flow control for a single file transfer

Another practical example (and I’m aware that most of you don’t deal with this) is a potential future binding of IPP on top of HTTP/2.0.

One common implementation constraint for printers is memory - when the client is sending printer data (potentially 100’s of megabytes per page) it is quite common for the printer to not keep up - print heads, etc. don’t move at network speeds, and if you get a paper jam, run out of ink, etc. then you need to make sure that you leave a little buffer space for a separate query from the client so that it knows that there is a paper jam, the printer is out of ink, etc. and can report that to the user.

Thanks to multiplexing, HTTP/2.0 offers potential “savings” on the number of simultaneous connections a printer will need to manage.  But the flow control support also allows the printer to tell the client to stop/slow down to prevent a deadlock situation and provides opportunities for the client to do other work or just go to sleep until the printer is ready to accept more data.  This translates into a better user experience and potential power savings.

So really, I would advise folks to not limit HTTP/2.0 to the things you currently do with HTTP/1.1.  Sending data as fast as possible (from the client or from the server) is a laudable goal, but usually the client and server and the links that connect them are not equal in capabilities or bandwidth.  Respecting HTTP/2.0 flow control hints may actually improve the perceived performance of a file send since you can avoid log-jamming packets at the TCP level.



On Nov 3, 2013, at 10:54 PM, William Chan (陈智昌) <willchan@chromium.org> wrote:

> http://en.wikipedia.org/wiki/Flow_control_(data) says "In data communications, flow control is the process of managing the rate of data transmission between two nodes to prevent a fast sender from overwhelming a slow receiver."
> 
> Guesstimating BDP is only important if the receiver cares about maximizing throughput. Which hopefully it does, but there's no guarantee. Sometimes due to resource constraints, the receiver cannot accept that much data, and it asserts flow control in this case. And senders *need* to respect that. Otherwise a receiver with any sense, like a highly scalable server, will terminate the connection since the peer is misbehaving.
> 
> 
> On Sun, Nov 3, 2013 at 7:44 PM, Peter Lepeska <bizzbyster@gmail.com> wrote:
> Sloppiness? I don't get that. The sender's job is to transmit the data as fast as possible, not to respect the receiver's best guesstimate of available bandwidth sent ½ RTT ago. In this case, the sender's job is to keep the TCP buffer full of data so it can send it when it has the opportunity to.
> 
> Respecting the peer's receive window in the single file send case is harmless at best and detrimental otherwise.
> 
> Peter
> 
> On Sunday, November 3, 2013, William Chan (陈智昌) wrote:
> I don't feel comfortable encouraging such sloppiness, I worry about future interop. Respecting a peer's receive window isn't hard. Just do it :)
> 
> And even though wget doesn't support upload (to my knowledge, but I'm not an expert), a command line tool may upload, in which case it should definitely respect the peer's receive window.
> 
> On Nov 3, 2013 6:22 PM, "Yoav Nir" <ynir@checkpoint.com> wrote:
> 
> On Nov 3, 2013, at 1:25 PM, William Chan (陈智昌) <willchan@chromium.org> wrote:
> 
>> It's probably understood already, but just to be clear, this is receiver controlled and directional. Unless you control both endpoints, you must implement flow control in order to respect the peer's receive windows, even if you disable your own receive windows. Cheers.
>> 
>> 
> 
> This discussion started with tools like WGET. If all you're ever sending is one single request equivalent to "GET xxx", you're likely fine not considering server receive window.
> 
> For a single file, the data that the client sends to the server never exceeds the default server receive window.
> 
> 
> 

____________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair