Re: Question on flow control for a single file transfer

"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."

If a specific deployment wants to trade off performance for lower
buffering, then flow control for the single stream case makes sense.
Perhaps this should just be a configurable option. In any case, I'd
definitely want the ability to go as fast as 1.x.




On Sun, Nov 3, 2013 at 9:50 PM, Roberto Peon <grmocg@gmail.com> wrote:

>
>
>
> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>
>