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 ?
On Mon, Jun 17, 2013 at 12:50 AM, Varun Sharma <vsdssd@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
On Mon, 17 Jun 2013 10:03:02 -0400, Greg Freemyer said:
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).)
Up to 64K if you don't support RFC1323 window scaling, which pretty much everybody does, because even at 10mbit speed, 64K only allows a 6.4ms RTT before a full window prevents you from using more bandwidth (in other words, if your RTT is over 6.4ms, your performance starts dropping). And if you're at 100mbit or gigabit or higher, the allowable RTT drops even more. With RFC1323 window scaling, the windows can get to multiple megabytes in size - enough to do line-rate 40 gbit/sec cross country. And even faster: http://www.extremetech.com/extreme/141651-caltech-and-uvic-set-339gbps-inter...
On Mon, Jun 17, 2013 at 10:45 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Mon, 17 Jun 2013 10:03:02 -0400, Greg Freemyer said:
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).)
Up to 64K if you don't support RFC1323 window scaling, which pretty much everybody does, because even at 10mbit speed, 64K only allows a 6.4ms RTT before a full window prevents you from using more bandwidth (in other words, if your RTT is over 6.4ms, your performance starts dropping). And if you're at 100mbit or gigabit or higher, the allowable RTT drops even more.
With RFC1323 window scaling, the windows can get to multiple megabytes in size - enough to do line-rate 40 gbit/sec cross country. And even faster:
http://www.extremetech.com/extreme/141651-caltech-and-uvic-set-339gbps-inter...
Thanks It's been 10 years since I did a deep dive into TCP/IP sliding windows and it was for a 19.2KB satellite based network, so window scaling was not used. Greg
participants (3)
-
Greg Freemyer -
Valdis.Kletnieks@vt.edu -
Varun Sharma