Ask Your Question

How to determine throughput/bandwidth from a capture (as used in TCP window scaling)

asked 2017-11-23 20:08:07 +0000

Nik108 gravatar image

Guys I need to determine the throughput available between TCP client/server based on a capture. I have a case where TCP window of a server is not scaling and a customer blames bandwidth. I need to prove or disprove this. any help will be really appreciated Nik

edit retag flag offensive close merge delete


Christian_R gravatar imageChristian_R ( 2017-11-23 21:07:41 +0000 )edit

HI. Here it is :

this was captured from closest to server interface

so the TCP window size stays same from packet 301 (4194304) - all the way almost to the end. the customer says it be due to some network bandwidth buffers... how can i refute this based on capture info?

from what i understand, there are only 2 factors - bandwidth and latency to check (i mean besides retransmits - which are not present) latency - RTT 0.076 s how do we check if bandwidth can be the problem here?

Nik108 gravatar imageNik108 ( 2017-11-24 20:10:45 +0000 )edit

maybe i should rephrase my question - what determines the final windows scaling factor? example FTP client initiates a TCP connection and has a 1GIG interface. Window scaling is enabled.

RTT is 76ms in the original SYN packet it had: MSS is 1460 window size value: 65535 window scale: 7 (multiply by 128)

SYN-ACK from opposite side: MSS is 1260 window size value: 8192 window scale: 14 (multiply by 16384)

in final ACK it came to: Window size value: 32768 window size scaling factor: 128 calculated window size: 4194304

(for the rest of FTP transfer it stayed on this value: 4194304)

so question regarding initiating side (FTP client):

1)How at the end the window size reduced to 32768 on the initiating side? 2) Why if the interface is set to GIG - it did not use the 14 as window scale ? but used 7?what could have determined that - is it ...(more)

Nik108 gravatar imageNik108 ( 2017-11-26 01:50:54 +0000 )edit

1 Answer

Sort by » oldest newest most voted

answered 2018-12-21 07:49:44 +0000

updated 2018-12-21 07:56:52 +0000

Your throughput limitation isn’t related to Receive Window sizes (or network bandwidth limits). It is entirely limited by the rate that the sending server is delivering data to the network. It would appear to be a send buffer limitation (but could be FTP delivering data to TCP in the server) with a buffer size of 128 KB.

There are never more that 128 KB of bytes in flight and data is sent in blocks of 64 KB. So there are never more than 2 x 64 KB “blocks” in flight. A new 64 KB “block” cannot begin to be transmitted until the whole 64 KB (from two bursts ago) is acknowledged.

Unfortunately, due to capturing inside the server, we are seeing packets that appear to be very large – but would be broken up into normal sized packets after we captured them – and as they leave the server.

The bursts of 64 KB always appear as one very large 63,648 byte packet followed by a smaller 1888 byte packet. The agreed MSS is 1260 and so in real life, our 64 KB burst would appear on the wire as 52 or 53 normal sized packets. The last packet in the burst has a PUSH flag. The sender has to wait for the ACK to that last packet before it starts a new 64 KB block.

You need to check your server configuration for anything that would limit the output to 128 KB per RTT. Possible culprits could be send buffer space limits in TCP, a setting in the FTP server or something else.

At the network or client side, you should investigate the “extra 45 ms” that will make more sense when you see the charts below.

It would be good to see a simultaneous capture from both the sender and receiver.

Some TCP-Trace charts tell the story.

The flow rate (slope of the packets) is very consistent for most of the flow, but we do see an increase just before the end. Something changes in the blue circle.

Full Flow

In the consistent part of the early flow, there are 2 x 64 KB bursts every 125 ms. The minimum RTT is 76 ms and we see the ACK for the first packet in the burst arrive after 76 ms. The ACK for the second-last packet in the burst arrives after 80 ms.

We can deduce that if we had a packet capture taken at the receiver, the stack of real-life normal sized packets would look similar to the ACK line in the blue circled area. That is, the last packet would be 4 ms behind the first. Based on the rate we see ACKs, it would appear that there is an available bandwidth of somewhere around 100 Mbps.

The most important piece of information on this chart is that the ACK for the very last packet in the 64 KB burst is always an extra 45 ms later than we might expect.

The red circles show the ACK line ... (more)

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2017-11-23 20:08:07 +0000

Seen: 614 times

Last updated: Dec 21 '18