cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1635
Views
0
Helpful
1
Replies

TCP Window Size and Network Bandwidth

rmeans
Level 3
Level 3

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?

 

1 Reply 1

Joseph W. Doherty
Hall of Fame
Hall of Fame

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.

Review Cisco Networking for a $25 gift card