Re: Question on flow control for a single file transfer

On Sun, Nov 3, 2013 at 9:19 PM, Peter Lepeska <bizzbyster@gmail.com> wrote:

> Roberto,
>
> I'm not getting your point. When the sender is the browser (for uploads)
> the data is buffered in the TCP stack on the end user's machine,
>

Incorrect, it is buffered on both ends of the TCP connection.
For typical TCP implementations this will end up being a BDPs worth or so.
As an example, with a 30ms ping time, and a 10Mb connection, you're talking
~4MB.
If the other side of this is contended, I may need to throttle back. I also
have no need of a full BDP's worth of buffer sitting there doing nothing
for some other user.


> so this would have no impact on servers at scale. When the sender is the
> server (for downloads), there should be no scaleability-related difference
> if data is buffered in the user mode application or in the kernel, if it is
> in TCP's buffer. Why is there a scalability advantage buffering in the user
> mode process (when we respect the remote peer's receive window) as opposed
> to the TCP stack in the kernel?
>
>
See above. Kernel buffers are not free, they still count.


> I recognize that I have less implementation experience at scale, but I
> still don't understand your argument. Trying to though...
>
> "Speaking as someone who has some implementation experience at scale,
> when the receiver asserts flow control or other policy, and the csender
> fails to respect it, it will be assumed to be malicious and the connection
> is far likelier to be terminated."
>
> We don't have app-level flow control today (in HTTP 1.x implementations)
> so why would this be assumed to be malicious? I'm just suggesting we put in
> the spec that receiver advertised windows not be respected when there is
> only one active stream. If it is the standard and this behavior is in
> standards-compliant browsers, why would we assume this to be malicious?
>

The standard is not that today, nor do I hope it becomes that, since
predicting the future is.. difficult, and the same rules need be in effect
for all connections, whether or not they end up with two or more streams.

I don't like exceptions, and the one you proposed there includes a
desynchronization race condition (at least until additional complexity is
heaped on top). Yuck.

Regardless, any implementation which uses more server memory than another
is going to the chopping block before any others since that server cannot
verify that the behavior is not malicious.

>
> Peter
>
>
> On Sun, Nov 3, 2013 at 8:49 PM, Roberto Peon <grmocg@gmail.com> wrote:
>
>> Peter, this isn't true. Servers care about things other than maximizing
>> bdp to a single connection, and in general care about performance across
>> more connections.
>>
>> Speaking as someone who has some implementation experience at scale, when
>> the receiver asserts flow control or other policy, and the csender fails to
>> respect it, it will be assumed to be malicious and the connection is far
>> likelier to be terminated.
>>
>> Resource utilization constraints exist to constrain utilization. Doing so
>> can impact bandwidth utilization, true, but sometimes this is exactly what
>> is intended as a tradeoff for some other property, e.g. maximizing
>> utilization of a more contended resource.
>>
>> The fact that this contention is not seen by the client doesn't mean
>> anything. There is almost alwatlys more than one client or client
>> connection. I do not want to be forced to override tcp's auto buffer
>> estimating by imposing a max window in the implementation, as that will
>> impact latency later, but I also don't want huge buffers in kernel space
>> soaking up precious memory.
>> -=R
>> On Nov 3, 2013 8:06 PM, "Peter Lepeska" <bizzbyster@gmail.com> wrote:
>>
>>> If a receiver cannot absorb any more data, it will not make a buffer
>>> available to TCP.
>>>
>>> Don't forget that in HTTP 1.x we don't do flow control. We leave that to
>>> the transport layer and this works well. Layering flow control on top of
>>> flow control can only result in slower flows. This slowdown is necessary
>>> when two or more streams are being sent at once but let's not take this hit
>>> in the simple case of one stream.
>>>
>>> Peter
>>>
>>> On Sunday, November 3, 2013, William Chan (陈智昌) 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>