This is a capture of a TCP session when I was downloading 10Mb file from an FTP server. The server is 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 has 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 begin sending new segments.

I wonder, why the sever 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 on the same moment, client sent one delayed ACK for 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 in 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 more 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

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

This is a capture of a TCP session when I was downloading 10Mb file from an FTP server. The server is 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 has 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 begin sending new segments.

I wonder, why the sever 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?

This is a capture of a TCP session when I was downloading 10Mb file from an FTP server. The server is 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 has 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 begin sending new segments.

I wonder, why the sever 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 on the same moment, client sent one delayed ACK for 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 in 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 more 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