tcp window concept

Greg Freemyer greg.freemyer at gmail.com
Mon Jun 17 10:03:02 EDT 2013


On Mon, Jun 17, 2013 at 12:50 AM, Varun Sharma <vsdssd at gmail.com> wrote:
> Hi,
>
> I am sending 5000 bytes of data in send system call.
> struct tcp_sock has max_window and snd_wnd two variable.Which are increase
> as packet sent out . whereas tcp header window variable value is fix for all
> packets.can anyone tell what is relationship b/w these windows ? and why
> max_window and snd_wnd size increase after packets  sent out ?

I haven't ever worked on Linux'es TCP/IP code, but I ported a TCP/IP
implementation 30 years ago.  (Damn I'm old).  For that reason I will
talk in theory, not code.

Do you know what the TCP window is?

TCP has a sliding window of non-acknowledged data.

So, IIRC the basic concept without a window is:

send packet with bytes x thru y
receive ACK from for end for all bytes prior to y+1
send packet with bytes y+1 thru z
receive ACK from for end for all bytes prior to z+1

On a fast lan, that might work okay, but assume you have a
geosynchronous satellite hop that adds in a couple hundred msecs of
delay between every packet and therefore you have to wait for the
packet to go up 22,000 miles, then back down, then do it again for the
ack packet.  That's 88,000 miles of delay between the send and the
ACK.  Even at the speed of light, that's a long way.

The solution from the very start of tcp/ip in the late 70's was to
have a sliding window of un-ack'ed data.  The normal default is 4 x
MSS (iirc).  That means the sender can send 4 large packets worth of
data without getting a single ACK.  (The default can be overridden up
to 64K bytes max (iirc).)

To do that, the TCP driver has to maintain a head and tail pointer for
the sliding window.  The tail pointer points to the ACK'ed data and is
updated to whatever the value in the ACK packet is every time it gets
one.  The head pointer is incremented by the amount of data in a
packet every time a new packet is sent (unless it is a resend).

With that background and using wireshark, you should be able to figure
out exactly what happens with when you are sending data.  The longer
the delay between sending the packet and receiving the ACK, the easier
it will be for you to see how the data correlates.  Therefore, use
wireshark to record a socket used to upload a file far from you from a
"ping" perspective, then start tracking exactly what is sent and what
is ack'ed and what the window values are showing you.

Greg



More information about the Kernelnewbies mailing list