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.

enter image description here

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?


Thank you for your answer. However, I need some elaboration here.

enter image description 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.


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?


You can take a look at the below tcptrace for the first part of the stream:

enter image description here

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:

enter image description here

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

  • Have you checked out the sharkfest presentations from Hansang Bae? He in particular is passionate about TCP analysis with wireshark and has several good tips and tricks in his presentations. Very important to check out if you haven't already.
    – Jeff Meden
    Sep 27, 2016 at 14:03
  • I don't see how you got to "server sent 8, got an ACK". Please see my comment to my own answer, in short I think that "server sent 10, then waited for ACK, after it received the ACK it sent 2 more".
    – hertitu
    Sep 28, 2016 at 14:55
  • I updated my answer to address your 2 updates, but note that the end of your update2 seems to be incomplete. If my updated answer does not address all your questions or concerns, let us know.
    – hertitu
    Sep 29, 2016 at 7:59
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin
    Jan 5, 2021 at 1:49

2 Answers 2


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).

  • Why would it pause at all though, if like he says the ICW is 10x then at any given time it has 8 packets of room in the window so even if that particular ack was delayed for some reason it shouldn't have been the reason to slow transmission.
    – Jeff Meden
    Sep 27, 2016 at 14:01
  • 1
    @JeffMeden: I'm not sure I understand your comment so maybe allow me to rephrase. What I guess happened is that the server sent 10 segments (frames 31-32,34-35,37-38,40-41,43-44), then paused until it received frame 33 ( the ACK to the first 2 segments), then sent frame 47 & 48. Again this is an assumption and a server-side capture would be required to confirm.
    – hertitu
    Sep 27, 2016 at 14:37
  • Ah yes, the age old bandwidth vs latency. I was taking your response more to explain the difference in wireshark capture details but indeed the latency (if that high) would be a basic limit in the tcp throughput and impact FTP performance.
    – Jeff Meden
    Sep 27, 2016 at 14:55

First, the highlighted packet is part of another conversation. You should filter. However, the RTT is closer to 50ms, and that's about the pause length? What can happen is the application layer is sending a block at a time to TCP and waiting for an ACK before sending the next block. Look at how much the SEQ# increases between PSH bits and that is the application send block size.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.