Doubt on the window size advertise

Hi folks, I'm doing a test here to better understand TCP/IP and its
implementation on Linux.
I finished to read the Stevens book Vol1.

What I'm trying to do is to create a server, and then connect to it to
send 10 packages of 1024 bytes each. What's the problem??

When they exchange the SYN flags its all ok, and the advertised window
from server is 5792 and the client's window is 5840. At this point,
fine.

But when the first packet of 1024 bytes is sent, both the client and
server advertise a 46-bytes window.

And then, as the packets get ACKed, it grows from the client side, the
window grows by 1 segment at time, I thought it should be the
congestion avoidance, right?

But why 46 bytes window size??

The client never changes its window size, its 46 bytes for the entire
connection, as it has no receiving data, it should state at this
point.


The tcpdump of this connection is in: http://pastebin.com/m6784db94

Thanks

On May 7, 2:02*pm, dutche <dut...@gmail.com> wrote:

> The client never changes its window size, its 46 bytes for the entire
> connection, as it has no receiving data, it should state at this
> point.

Window scaling.

DS

dutche wrote:
> Hi folks, I'm doing a test here to better understand TCP/IP and its
> implementation on Linux.
> I finished to read the Stevens book Vol1.
>
> What I'm trying to do is to create a server, and then connect to it to
> send 10 packages of 1024 bytes each. What's the problem??
>
> When they exchange the SYN flags its all ok, and the advertised window
> from server is 5792 and the client's window is 5840. At this point,
> fine.
>
> But when the first packet of 1024 bytes is sent, both the client and
> server advertise a 46-bytes window.

As David says - it's window scaling at this point both ends know they
can use it. In the syn syn/acks I guess the RFCs specify unscaled values
in case the other end doesn't know about window scaling.

>
> And then, as the packets get ACKed, it grows from the client side, the
> window grows by 1 segment at time, I thought it should be the
> congestion avoidance, right?

This change of size is nothing to do with slow start or congestion
avoidance. AIUI there is a separate internal congestion window used for
this.

If you dump a windows XP connection you will see that it just advertises
64k straight away.

Linux does this, dynamic right sizing, I believe it's called to avoid
allocating lots of buffer memory for connections before it is really needed.

I am no TCP expert, there is a group - comp.protocols.tcpip which was
active last time I looked.