TCP Window Size and Network Bandwidth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-15-2015 07:17 AM - edited 03-05-2019 02:18 AM
TCP Window Size and Network Bandwidth
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 (1, 2 or 3 T1's at each office). I captured traffic to investigate. I selected a series of 4 packets for 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?
- Labels:
-
Other Routing
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-15-2015 08:30 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Without actually knowing what you're looking at, unable to confirm your analysis, but there are other variables to consider. First, large TCP windows need to be agreed upon by both sender and receiver during TCP handshake. Second, the TCP sender maintains its own send window which is often smaller than the receiver's receive window. (The send window, I believe, is not "visible" within any packet.) Lastly some "backup" applications roll their own protocol and/or violate TCP standards when using TCP.
What you might consider, is whether the receiver's RWIN supports the BDP between it and the sender. Years ago, I dealt with a case of data transfers being too slow across a LFN. I had the receiving host increase its RWIN from its default to 64 KB and transfer rate increased by a factor of 5.
