I have added 2 more captures (better) as examples. Each capture transfers the same file from the same source (Unix server). The client side is either a Windows 7 laptop or a MacBook Pro. https://www.dropbox.com/s/boxkdcmsmrsyb1l/Windows7winSCPv2.pcapng?dl=0 The captures illustrate the trouble that I am having; understanding windows size. The . The Win7 window size (65535) does seem to match the amount of data received (Bytes in flight - 2496). The MacBook capture seems more appropriate. original post. I am learning TCP window size and the impact window size has on data transfer and bandwidth. I have captured traffic between my field office server (over WAN) to a HQ backup server. I have noticed that some offices do not consume all available bandwidth. I captured traffic to investigate. I selected a series of 4 packets to analysis. First packet (of the series) - HQ server to field office server – this packet is acknowledging the previous set of data and (I assume) is setting the stage for the next set of data (using window size). Window size value = 1129 Window size scaling factor is 128 Calculated window size is 144,512 Next 3 packets – field office server to HQ server (the packet represent the data this being backed up). For these packets, I don’t believe window size is relevant. Instead the bytes in flight are important. Each of the 3 packets has a length of 1380. The bytes in flight increments by 1380 for each packet (1380, 2760 and 4140). Next packet is from HQ server to field office server. This packet acknowledges the previous set. The cycle begins again. Should the field server send more data between acknowledgements? Instead of 3 packets, I was thinking more like 13 packets (1380x13=17,940bytes * 8 bits = 143,520 which is pretty close to 144,512). Am I missing something? traffic capture file at https://www.dropbox.com/s/nw524rpzr2vh7ve/BackupCapture.pcap?dl=0 asked 15 Sep '15, 07:29  RicM edited 16 Sep '15, 12:10 |
2 Answers:
It's not two data packets per ACK, it's one ACK for every two data packets. Those are not the same thing. There is no reason to expect or try to force more packets between ACKs, because the sending system isn't waiting on the ACKs. It doesn't send two packets and then wait for an ACK before sending two more. The sending system transmits continuously, and the receiving system responds continuously with acknowledgements as the data packets are received. In this case, Delayed ACK is in use, so the receiving system sends one ACK for every two data packets, instead of one ACK for each data packet. Looking at the Windows capture file: It's encrypted, so we don't know what commands/requests and responses are going back and forth. We can see that by packet 205 the two systems seem to have negotiated whatever requests/responses are involved, and then a continuous data transfer gets underway. From that point on, the sender sends a continuous stream of 1,248-byte segments, which is the largest segment it is allowed to send based on the receiver's Maximum Segment Size of 1,260 bytes with Timestamps in the TCP options field. From packet 205 to the end, packet 40,669, there is only one place where the delta time between data packets exceeds 1 ms. The delta times between all the rest of the data packets are less than 0.5 milliseconds. From packet 205 to the end, that's 40,464 packets (both directions) in 9.788 seconds. It takes more than 19 seconds to get to packet 205, but from that point on, I'd say things are moving along very nicely. answered 17 Sep '15, 14:22  Jim Aragon |
The receive windowsize is not the only dominating factor in TCP flow clontrol. There is also the congestion window that plays a role here. The trace was taken at the receiver so what you would normally see in an inbound streaming traffic is an ACK acki-ing 'every other' packet. The RTT is around 7 ms. In your trace the sender starts sending using a 1 MSS window, then increments to 2 MSS and 3 MSS so this looks like we are either pretty early in the connection or we suffered a packet loss or timeout on the connection causing cwnd to drop. Regards Matthias answered 16 Sep '15, 22:38  mrEEde Thank you for the information and feedback. Couple of follow ups. Is there any way to force more packets between ACK's? Thinking back over the previous months/years of traffic captures, it has been rare that I have seen more than 2 packets per ACK. It is almost like there is a regedit setting on my laptop that limits data exchanges to 2 packets per ACK. Is there a formula that calculates bytes/packets per ACK? I found the following formula, but it seems different than what you are describing. Bandwidth-in-bits-per-second * Round-trip-latency-in-seconds = TCP window size in bits / 8 = TCP window size in bytes (17 Sep '15, 13:09) RicM |
This kind of discussion is hard without a capture file - can you post it on Cloudshark (and sanitize it with TraceWrangler if required first)?
Added capture information. I did not see how to attach a file.
It's unlikely anyone is going to wade through all that text. There is no way to attach a file on this site, so instead post your capture file some place publicly accessible (www.cloudshark.org recommended, but other places like Dropbox or Google Drive will work as well) and edit your question to include a link to the capture file so we can download it. I recommend including more than just six packets.