This is a capture of a TCP session when I was downloading the 10Mb file from an FTP server. The server has an ICW of 10x MSS, so this means that the server can initially send 10 segments without receiving an ACK from the client.
Being said that, every two segments have been ACKed in real-time, and the server has sent all the 10 segments to the client that has already ACKed all the segments. Now, the server waited from 15:40:31:864 to 15:40:31:901 for more than 50ms until it begins sending new segments.
I wonder, why the server has paused sending more segments, although all the segments have already been ACKed? I know that it waited for the RTO value, but why would the server do this when all the ACKs have received?
UPDATE1:
Thank you for your answer. However, I need some elaboration here.
Above is the RTT for the stream, and as you can see the average RTT for the first part (until SEQ# 2600000) is around 30ms. So, initially at the server side, the cwin has been populated and filled in with 10 segments ready to be sent.
Presumably:
The first two packets have already been sent from the server at -> 15:40:31.842 and has been received at the client (on which I'm capturing) at -> 15:40:31.862 at the same moment, client sent one delayed ACK to the server at -> 15:40:31.862 and presumably received by the server at -> 15:40:31.882
At this time, the cwin will be sliding, getting rid of the old two segments, and making a room for two new segments to be sent to the client, the two new segments will be ready to be sent unless the cwin or the rwin of the client is exhausted which is not in our case, or the server is waiting for an ACK, which is also not valid.
So, the server had 10 segments, sent 8, got an ACK for the first 2, slid the cwin to the right, got two new segments. Now cwin has 10 segments to go again, non-stoppable. My question is, why the server paused its transmission at this stage?
UPDATE2:
You can take a look at the below tcptrace for the first part of the stream:
The slope is relaxed (not steep), and you can see that every around 50ms there is a pause for no reason.
However, in the middle part of the connection:
The slope is much steeper without those gaps in between, and no pauses. Taking into consideration that the RTT is the same for both parts, and you can confirm this with the RTT graph
Best Answer
Assuming this is a client-side capture, you need to take into account that there is a round-trip delay between your client and server, so these timestamps show when the client sent/received packets, not when the server received/sent them.
E.g. if client sends an ACK at T=0ms, it arrives at the server at T=50ms, suppose that even if the server responds in less than 1ms the response is sent at T=50ms and it arrives at the client at e.g. T=110ms (since the delay may not be constant and can also vary per direction). So in your client side capture you would see ACK at T=0ms and next data at T=110ms, but that doesn't mean the server waited 110ms to respond. It simply means that the total time of (transmission of ACK + processing on server + transmission of data) = 110ms.
So to know for sure, you would need to capture on the server (preferably at the same time as a capture on the client). Without a server-side capture we can only guess, but it seems quite likely that you have a delay of around 20ms between your client and your server, and hence a RTT (round-trip time) of around 40ms (but again, the delay can be different for each packet).
Edit: the above values of 20/40ms were based on the timestamps you mentioned, 15:40:31:864 to 15:40:31:901 (which is actually only 37ms), but really you need to look at the first ACK (sent at 15:40:31.862, frame 33) and the data packet in frame 47, received at 15:40:31.922 so the RTT there was 60ms.
Edit after Update 1 & 2
As already mentioned in the comments, I don't think that the server send 8 segments and then paused, I think it sent 10 segments (frames 31-32,34-35,37-38,40-41,43-44), then it paused until it received frame 33 ( the ACK to the first 2 segments); after it received this ACK it then sent frame 47 & 48 etc. Again this is an assumption and a server-side capture would be required to confirm, but this seems quite normal expected behaviour to me.
As for what happens later on in the connection, without looking at actual captures it seems reasonable to assume that because of TCP Slow Start, the cwin will increase in size, so the server can send more segments before waiting for an ACK, and at some point the cwin is large enough for the server to keep sending data without waiting for ACKs (as long as the ACKs keep being received at a relatively steady rate).