Fw: Tcp window size question [7:26861]
- Original Message - From: "Shawn Goodson" To: "z z" Sent: Wednesday, November 21, 2001 10:23 AM Subject: Re: Tcp window size question [7:26861] > This is common. The tcp window size "should" drive performance and can > really make a difference in bulk transfers, but many applications seem to be > constrained by their own code and do not utilize the systems TCP values. > Sybase and Oracle based applications do the same thing. If you look at other > applications on your network you will probably see similar results. If it is > an application you have control over you could replace it with one that can > take advantage of real window size. Here is a good place to start if you > want to look into it; > http://www.psc.edu/networking/research.html If you find any tricks let me > know. > > > Aloha > Shawn > > > - Original Message ----- > From: "z z" > To: > Sent: Tuesday, November 20, 2001 7:28 AM > Subject: Tcp window size question [7:26861] > > > > Hi > > I used a sniffer to monitor my network traffic. I > > found even if the tcp window size is very big (around > > 32000), my ftp session is still getting one ack after > > every two pakets sent. > > > > So who is deciding how frequent the ack will be sent? > > > > I thought it should be decided by the TCP window size. > > Please correct me. > > > > __ > > Do You Yahoo!? > > Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. > > http://geocities.yahoo.com/ps/info1 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=27076&t=26861 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Tcp window size question [7:26861]
In theory you should see the sneder sending more segments exponentially 1,2,4,8,... and 1 ack for for each group of segments until the senders congestion window hits the recievers advertised window. However it did not happen on my test either. Can anyone produce a tcpdump that shows a sender sending more than 2 segments when MTU is 1500? If anyone knows why the sender does not ever send more than 2 packets i'd be grateful for an explanation. Especially if you could refer me to an RFC. I did the same test a large file transfer across the internet and also received an ack packet for every 2 data packets for the whole entire transfer. 09:49:06.330931 eth0 > wolf.newsalert.com.1672 > v-man.net.ftp: P 88:105(17) ack 217 win 32120 (DF) [tos 0x10] 09:49:06.341529 eth0 wolf.newsalert.com.1673: S 1878175317:1878175317(0) win 16384 (DF) 09:49:06.341568 eth0 > wolf.newsalert.com.1673 > v-man.net.ftp-data: S 2805766005:2805766005(0) ack 1878175318 win 32120 (DF) 09:49:06.349094 eth0 wolf.newsalert.com.1673: . 1:1(0) ack 1 win 17520 (DF) 09:49:06.351366 eth0 wolf.newsalert.com.1672: P 217:290(73) ack 105 win 17520 (DF) 09:49:06.361861 eth0 wolf.newsalert.com.1673: . 1:1461(1460) ack 1 win 17520 (DF) 09:49:06.361917 eth0 > wolf.newsalert.com.1673 > v-man.net.ftp-data: . 1:1(0) ack 1461 win 30660 (DF) [tos 0x8] 09:49:06.364826 eth0 > wolf.newsalert.com.1672 > v-man.net.ftp: . 105:105(0) ack 290 win 32120 (DF) [tos 0x10] 09:49:06.379515 eth0 wolf.newsalert.com.1673: . 1461:2921(1460) ack 1 win 17520 (DF) 09:49:06.387360 eth0 wolf.newsalert.com.1673: . 2921:4381(1460) ack 1 win 17520 (DF) 09:49:06.387380 eth0 > wolf.newsalert.com.1673 > v-man.net.ftp-data: . 1:1(0) ack 4381 win 30660 (DF) [tos 0x8] 09:49:06.404864 eth0 wolf.newsalert.com.1673: . 4381:5841(1460) ack 1 win 17520 (DF) 09:49:06.412699 eth0 wolf.newsalert.com.1673: . 5841:7301(1460) ack 1 win 17520 (DF) 09:49:06.412718 eth0 > wolf.newsalert.com.1673 > v-man.net.ftp-data: . 1:1(0) ack 7301 win 30660 (DF) [tos 0x8] 09:49:06.420541 eth0 wolf.newsalert.com.1673: . 7301:8761(1460) ack 1 win 17520 (DF) 09:49:06.431021 eth0 wolf.newsalert.com.1673: . 8761:10221(1460) ack 1 win 17520 (DF) 09:49:06.431042 eth0 > wolf.newsalert.com.1673 > v-man.net.ftp-data: . 1:1(0) ack 10221 win 30660 (DF) [tos 0x8] 09:49:06.438889 eth0 wolf.newsalert.com.1673: . 10221:11681(1460) ack 1 win 17520 (DF) 09:49:06.446735 eth0 wolf.newsalert.com.1673: . 11681:13141(1460) ack 1 win 17520 (DF) 09:49:06.446755 eth0 > wolf.newsalert.com.1673 > v-man.net.ftp-data: . 1:1(0) ack 13141 win 30660 (DF) [tos 0x8] 09:49:06.454567 eth0 wolf.newsalert.com.1673: . 13141:14601(1460) ack 1 win 17520 (DF) 09:49:06.462536 eth0 wolf.newsalert.com.1673: . 14601:16061(1460) ack 1 win 17520 (DF) 09:49:06.462556 eth0 > wolf.newsalert.com.1673 > v-man.net.ftp-data: . 1:1(0) ack 16061 win 30660 (DF) [tos 0x8] ""VoIP Guy"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > You are correct in that the tcp window size sets the freq. of acks. The > receiver decides the window size based on a "credit system" based on how > well it received your packets in the past. Unfortunately, it's an unfair > system since you have no control of how the packets do across the network, > especially in the harsh world of WRED, Frame Relay switch DE's, and other > outside influences. > > As for why you are getting on ack every two packets without it ever > increasing is beyond me. It should go 2, 4, 8, 16, etc.. > > > ""z z"" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > Hi > > I used a sniffer to monitor my network traffic. I > > found even if the tcp window size is very big (around > > 32000), my ftp session is still getting one ack after > > every two pakets sent. > > > > So who is deciding how frequent the ack will be sent? > > > > I thought it should be decided by the TCP window size. > > Please correct me. > > > > __ > > Do You Yahoo!? > > Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. > > http://geocities.yahoo.com/ps/info1 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=27004&t=26861 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Tcp window size question [7:26861]
This question was answered about two months ago. The ack has to do with a timer from when TCP/IP loads on the system. Check the archive for a better explanation. Brett -Original Message- From: VoIP Guy [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 20, 2001 4:45 PM To: [EMAIL PROTECTED] Subject: Re: Tcp window size question [7:26861] You are correct in that the tcp window size sets the freq. of acks. The receiver decides the window size based on a "credit system" based on how well it received your packets in the past. Unfortunately, it's an unfair system since you have no control of how the packets do across the network, especially in the harsh world of WRED, Frame Relay switch DE's, and other outside influences. As for why you are getting on ack every two packets without it ever increasing is beyond me. It should go 2, 4, 8, 16, etc.. ""z z"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Hi > I used a sniffer to monitor my network traffic. I > found even if the tcp window size is very big (around > 32000), my ftp session is still getting one ack after > every two pakets sent. > > So who is deciding how frequent the ack will be sent? > > I thought it should be decided by the TCP window size. > Please correct me. > > __ > Do You Yahoo!? > Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. > http://geocities.yahoo.com/ps/info1 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=26997&t=26861 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Tcp window size question [7:26861]
It's not as simple as just looking at the window size. First, the "who" is the receiving station. The "how frequent" depends. Normally, a TCP stack implements what is called "delayed ACK", meaning it will not simply just send an ack the instant it receives a packet that requires an ack. It will normally wait some small amount of time (somewhere around 200-500ms) to see if it has any data to send that it can piggyback on the ack (this is good for slow networks). However, delayed acks don't come into play if the reciver gets multiple packets requiring an ack. On a fast network, the receiver is always getting multiple segments that require an ack, so it won't wait and will typically send an ack after the first 2 or 3 segments requiring an ack, depending on how fast the TCP stack can process the segments. This is a good thing since if the receiver waited until the max number of TCP segments had arrived per the window size, the sender will be idle until it receives an ack of all of the outstanding segments (even a delay of 10-20ms can be "long" on a fast network). A sender cannot send additional TCP segments once it sends the max allowed by the window, so it will sit there until it gets an ack. By sending acks every 2 or 3 segments, the receiver ensures that the sender can continually put packets on the wire and keep the traffic flowing smoothly. If you have a long delay, high bandwidth network such as a satellite link, it's possible the sender could completely fill the window size before receiving an ack (this is why it's generally a good idea to have very large window sizes on these types of networks). This can lead to long delays waiting for the ack from the receiver. It's also possible for the sender to fill the window if the receiver is a very slow computer since the sender can send TCP segments faster than the receiver can process them. Again, this can lead to long delays while the sender waits for acks of it's already sent segments. This topic and many others related to TCP/IP are given excellent coverage in "TCP/IP Illustrated Vol 1" by the late, great Richard Stevens. I highly recommend it. HTH, Kent -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of z z Sent: Tuesday, November 20, 2001 9:28 AM To: [EMAIL PROTECTED] Subject: Tcp window size question [7:26861] Hi I used a sniffer to monitor my network traffic. I found even if the tcp window size is very big (around 32000), my ftp session is still getting one ack after every two pakets sent. So who is deciding how frequent the ack will be sent? I thought it should be decided by the TCP window size. Please correct me. __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=27010&t=26861 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Tcp window size question [7:26861]
You are correct in that the tcp window size sets the freq. of acks. The receiver decides the window size based on a "credit system" based on how well it received your packets in the past. Unfortunately, it's an unfair system since you have no control of how the packets do across the network, especially in the harsh world of WRED, Frame Relay switch DE's, and other outside influences. As for why you are getting on ack every two packets without it ever increasing is beyond me. It should go 2, 4, 8, 16, etc.. ""z z"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Hi > I used a sniffer to monitor my network traffic. I > found even if the tcp window size is very big (around > 32000), my ftp session is still getting one ack after > every two pakets sent. > > So who is deciding how frequent the ack will be sent? > > I thought it should be decided by the TCP window size. > Please correct me. > > __ > Do You Yahoo!? > Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. > http://geocities.yahoo.com/ps/info1 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=26902&t=26861 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Tcp window size question [7:26861]
When 2 machines are communicating over a network, as an example an ftp client and server, each one has their own receive and send windows. If the reciever of the data can empty its buffers as its receives data quickly enough it will acknowledge the packets right then. It will not wait to receive the whole advertised window size worth of data before acking. The cases where you may see more data and less acks is when you have a fast sender sending to a slow receiver. This property of TCP data handling is called the sliding window protocol. Its explained in great detail in TCP/IP illustrated volume 1 by Richard Stevens, a great book. Theses windows can be seen on UNIX machines with the netstat -an command. sam sneed ""z z"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Hi > I used a sniffer to monitor my network traffic. I > found even if the tcp window size is very big (around > 32000), my ftp session is still getting one ack after > every two pakets sent. > > So who is deciding how frequent the ack will be sent? > > I thought it should be decided by the TCP window size. > Please correct me. > > __ > Do You Yahoo!? > Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. > http://geocities.yahoo.com/ps/info1 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=26922&t=26861 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Tcp window size question [7:26861]
Hi I used a sniffer to monitor my network traffic. I found even if the tcp window size is very big (around 32000), my ftp session is still getting one ack after every two pakets sent. So who is deciding how frequent the ack will be sent? I thought it should be decided by the TCP window size. Please correct me. __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=26861&t=26861 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
