6

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?

UPDATE1:

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.

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:

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 '16 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 '16 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 '16 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 could provide and accept your own answer. – Ron Maupin Aug 15 '17 at 3:59
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 '16 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 '16 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 '16 at 14:55
0

What you have here is TCP Slow-start. It's a normal and natural part of TCP. The sending station may know that it is plugged into a Gig port, but has no idea what the bandwidth along the way is, so it starts slow and ramps up if conditions permit, and slows down if packets get delayed or lost.

There are two common ramp up methods I see: Fibbonacci and exponential. Most are Fibbonacci and start with three data packets and wait for an ACK, then 5, 8, 13... If you have 10Mb/s bandwidth it will take about 9 RTT to ramp up to that speed. But this can be limited by other factors like a congestion, a low receive TCP window (or one that doesn't get cleared out quickly), or a low server send window (sometimes the server sends 64k and waits for an ACK before sending the next block - double buffering helps with this). As you see, as soon as you get the ack you send a burst. This burst size is also called the Congestion Window or CWD. We can't see what it is in the packets, it is an internal counter that the sender uses.

On a 100M its about 14 RTT, and Gig it's 19 RTT.

To combat this Google developed and has been using IW10. It sets the Initial CWD to 10 and adjusts from there.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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