Re: TCP window size bugs and patch (Re: 3 issues)
On Fri, 8 Nov 2002 Marc.Herbert --at-- ens-lyon.fr wrote:
> On 7 Nov, Kevin Gibbs wrote:
> > Well I think that all of this functionality will be added to the next
> > version but not in this fashion. Thanks for pointing out the send vs.
recv
> > issue, had not ran accross that so far. I did notice the server sending
> > code and had problems with it myself, but TCP at the theoritical
> > standpoint is only limited by reciever window and available bandwidth.
>
> >From the iperf & co website :
> <http://dast.nlanr.net/Projects/Autobuf_v1.0/autotcp.html>
>
> "To maximize the performance, [the sender should set it's send buffer
> size] and the receiver should set its receive buffer size to no less
> than the capacity of the TCP pipe. Usually this number is the product of
> bandwidth and round-trip-time (bandwidth-delay product)."
>
> This is rather obvious, considering that the sender must keep in its
> send buffer all the data not yet acknowledged. When the througput*delay
> product is high, the send buffer desesperatly needs to be high.
Yes you are correct, but I used "at the theoritical standpoint" for a
reason. Namely that the send window size is effectively controlled by the
recievers window size and the available bandwidth. (eg. recieve window =
8k and bandwidth*delay = 1k then a send window above 9k is never
realized) The setting of send window size is needed because TCP
implementations generally allocate the maximum window at connection time
and it can not grow after that. This is an implementation issue not a
theoritical TCP requirement.
> > I believe this is why there is no setting for max send window size on
newer
> > Windows TCP implementations.
>
> > As a result it is hard for a client (sender)
> > to determine the best window since it has no control over either of the
> > above variables.
>
> Well, Iperf seems highly portable, I do not clearly understand why it
> should give up some useful features just because Windows does not
> support them anymore...? But maybe I did not understand what you said ?
I think you did misunderstand. The Windows implementation was in
referrence to the limit being imposed by the reciever window and
bandwidth as noted above and my belief that Windows will dynamically
allocate a larger send window if one is needed. (I am not sure about
this, but it would be a logical reason). This contrasts to the static
allocation of most other implementations and has nothing to do with the
statement below.
As far as the difficulty of the client to determine the best window is
that as noted above if the send window is above the 9k in the example
there is no increase in performance no matter what the window is set at.
Therefore it is neccesary for the server to send data to the client in
order for the change of window size on the client to be of any value. This
is the case for TCP in general and has nothing to do with the Windows
implementation or any other for that matter.
Kevin
--
Mitch Kutzko | mitch --at-- dast.nlanr.net | mitch --at-- ncsa.uiuc.edu | 217-333-1199
http://hobbes.ncsa.uiuc.edu/