TCP receive window behavior

Hi,
I noticed that the window advertised by a receiving TCP grows from a small
value as the data transfer proceeds. What is the reason for this? Why
isn't it set initially to however much buffer space is available at the
receiver.
Please correct me if this isn't the right place for this question.
Thanks,
Anant.

Anant Padmanath Mudambi <(E-Mail Removed)> wrote:

> I noticed that the window advertised by a receiving TCP grows from a small
> value as the data transfer proceeds. What is the reason for this? Why
> isn't it set initially to however much buffer space is available at the
> receiver.

The Linux TCP code wants to decide on its own what the "right" window
size should be.

rick jones
--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

On 2005-06-10, Anant Padmanath Mudambi <(E-Mail Removed)> wrote:
> Hi,
> I noticed that the window advertised by a receiving TCP grows from a small
> value as the data transfer proceeds. What is the reason for this? Why
> isn't it set initially to however much buffer space is available at the
> receiver.
>
The receive window is a good way to throttle downloads and its never a good
idea to saturate a connection so there is no point having a too large a TCP
window than the connection can take (or the server is willing to give).

The purpose of the receive window, in case you don't know, is to act as a
buffer as the end-points wait for the ACK's to arrive so it knows how much
data needs to be re-sent if there is something wrong. If something goes
wrong the *whole*[1] receive window is transmitted whih can take some time.

Keeping the RWIN nice and small and growing it to only as far as the link
will support makes the retransmission element less expensive.

Hope that clears things up

Cheers

Alex

[1] SACKs (Selective ACKs) tell the sender what range needs retransmitting so
a large receive window should no longer hurt connections, however not
everything supports SACK's and scaling RWIN's and SACK's are only
optional modifications to the original TCP protocol

> Please correct me if this isn't the right place for this question.
> Thanks,
> Anant.

> I noticed that the window advertised by a receiving TCP grows from a small
> value as the data transfer proceeds. What is the reason for this? Why
> isn't it set initially to however much buffer space is available at the
> receiver.

Your university library should have some references that cover this.
Books by Comer and Stevens do, for instance. You might also get
somewhere googling for "slow-start", or look at RFC 2001.

Allen McIntosh <(E-Mail Removed)> wrote:
>> I noticed that the window advertised by a receiving TCP grows from a small
>> value as the data transfer proceeds. What is the reason for this? Why
>> isn't it set initially to however much buffer space is available at the
>> receiver.

> Your university library should have some references that cover this.
> Books by Comer and Stevens do, for instance. You might also get
> somewhere googling for "slow-start", or look at RFC 2001.

Will the Comer and Stevens texts actually cover Linux's behaviour in
this regard?

And what the Linux kernel is doing with the _receive_ window, while
similar to slow-start is _not_ slow-start. Slow-start is something
that happens on the sending side. What the linux kernel is doing at
the receive side is not covered in RFC 2001. Whether that is covered
in some other RFC I do not know.

rick jones
--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
- Rick Jones
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Alexander Clouter wrote:

> The purpose of the receive window, in case you don't know, is to act as a
> buffer as the end-points wait for the ACK's to arrive so it knows how much
> data needs to be re-sent if there is something wrong. If something goes
> wrong the *whole*[1] receive window is transmitted whih can take some
> time.
>
> Keeping the RWIN nice and small and growing it to only as far as the link
> will support makes the retransmission element less expensive.

I thought the purpose of the receive window, was to determine how much
outstanding data the receiver was prepared to allow, and it's the transmit
window, that gradually grows as transmission progresses. Initially, the
transmit window will not send more data, while there's unacknowledged data.
Then as confidence grows, the transmitter ramps up the transmit window,
allowing more outstanding data. When there's an ack time out, the transmit
window immediately resets to the initial value. With this method, TCP
transmissions start gradually, to avoid overloading the path to the
destination.

Thanks for the responses.
Since the sender uses min(cwnd, receiver wnd) to decide whether to
send more data, wouldn't it be wrong if the receiver wnd < cwnd because
of Linux's receive window growth behavior? And if that never happens then
what's the point of having it behave that way?
Is this behavior Linux specific or is it required by some standard/RFC?

Thanks,
Anant.

On Fri, 10 Jun 2005, James Knott wrote:

> Alexander Clouter wrote:
>
> > The purpose of the receive window, in case you don't know, is to act as a
> > buffer as the end-points wait for the ACK's to arrive so it knows how much
> > data needs to be re-sent if there is something wrong. If something goes
> > wrong the *whole*[1] receive window is transmitted whih can take some
> > time.
> >
> > Keeping the RWIN nice and small and growing it to only as far as the link
> > will support makes the retransmission element less expensive.
>
> I thought the purpose of the receive window, was to determine how much
> outstanding data the receiver was prepared to allow, and it's the transmit
> window, that gradually grows as transmission progresses. Initially, the
> transmit window will not send more data, while there's unacknowledged data.
> Then as confidence grows, the transmitter ramps up the transmit window,
> allowing more outstanding data. When there's an ack time out, the transmit
> window immediately resets to the initial value. With this method, TCP
> transmissions start gradually, to avoid overloading the path to the
> destination.
>
>
>

Anant Padmanath Mudambi wrote:

> Since the sender uses min(cwnd, receiver wnd) to decide whether to
> send more data, wouldn't it be wrong if the receiver wnd < cwnd because
> of Linux's receive window growth behavior? And if that never happens then
> what's the point of having it behave that way?
> Is this behavior Linux specific or is it required by some standard/RFC?
>

The sender can never send more than the receiver allows. If the receive
window is reduced to less than the current outstanding data, the
transmitter must stop sending, until the outstanding is reduced to below
the receive window. I'm not sure what you're getting at, with the 2nd part
of your question.

On Sun, 12 Jun 2005, James Knott wrote:

> Anant Padmanath Mudambi wrote:
>
> > Since the sender uses min(cwnd, receiver wnd) to decide whether to
> > send more data, wouldn't it be wrong if the receiver wnd < cwnd because
> > of Linux's receive window growth behavior? And if that never happens then
> > what's the point of having it behave that way?
> > Is this behavior Linux specific or is it required by some standard/RFC?
> >
>
> The sender can never send more than the receiver allows. If the receive
> window is reduced to less than the current outstanding data, the
> transmitter must stop sending, until the outstanding is reduced to below
> the receive window. I'm not sure what you're getting at, with the 2nd part
> of your question.
>

Let me try and explain my question better. Suppose that the receiving
application is fast enough that the receiver window is never reduced.
Say the receiver has a receive buffer space of R bytes. Linux starts off
by advertising a rcv wnd smaller than R and as the data comes in
increases it to eventually settle at R. In this case I think min(cwnd,
receiver wnd) should equal cwnd for all 'receiver wnd' < R. Otherwise the
sender is throttled because of the way Linux increases 'receiver wnd',
even though the receiver may have enough space to accept more data.
If that's right then the receiver might as well start off by advertising a
receive window of R.

Anant.

Anant Padmanath Mudambi wrote:

> Let me try and explain my question better. Suppose that the receiving
> application is fast enough that the receiver window is never reduced.
> Say the receiver has a receive buffer space of R bytes. Linux starts off
> by advertising a rcv wnd smaller than R and as the data comes in
> increases it to eventually settle at R. In this case I think min(cwnd,
> receiver wnd) should equal cwnd for all 'receiver wnd' < R. Otherwise the
> sender is throttled because of the way Linux increases 'receiver wnd',
> even though the receiver may have enough space to accept more data.
> If that's right then the receiver might as well start off by advertising a
> receive window of R.

As far as I know, the ramp up is controlled by the sender, not the receiver.
The receive windows is simply how much data the receiver is prepared to
leave unacknowledged. It is the senders responsibility to gradually
increase to that receive window value. There's a good description in one
of the books by Commer (IIRC), about the process. It describes not only
the ramp up of the transmit window, but also determining how long to wait
for acks and resetting the values should some data not be acked in time
etc. It pretty well covers all you're looking for.