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]
