0

The considered application (server) has a number of clients connected. It processes each message from the client and sends two output messages. The output messages are generated sequencially and written to the socket. I observe that occassionnaly the second output message is delayed by a big time for a client. I'm trying to understand the reason for this.

Below is the filtered TCP flow between the application and the client captured from the client side.

enter image description here

  1. 14908 is the input message from client. 14910 and 15337 are the two ouput messages
  2. 14910 is not delayed. But 15337 is delayed around 40ms.
  3. As I can see, the 15337 packet is not sent until the ack 15336 is received.

The application sends a packet to TCP layer if the socket does not return EWOULDBLOCK or EAGAIN . I'm assuming the socket is not blocked because the window published in #14908 is 1424 and #15336(len=229) shouldn't send it to EWOULDBLOCK.

So can you please help me understand what causes the TCP layer from delaying the sending of #15337 until the ack for #15336?

migrated from networkengineering.stackexchange.com Oct 8 at 13:52

This question came from our site for network engineers.

  • 2
    The stack is simply waiting for more send data. The application needs to use the Urgent option on the TCP socket, so a send buffer is actually transmitted earlier. – Zac67 Oct 4 at 18:19
  • @Zac67But 15337 is not out-of-band data for the application. It has same priority as 14910 – PasanW Oct 4 at 18:51
  • Unfortunately, the behavior of your host OS/application are off-topic here. You could try to ask this question on Server Fault for a business network, or on Stack Overflow for programming help. We could help with the network, but you have not given us a good network description or diagram, the network device models, and the network device configurations. It appears that the network is working, but you have a host problem. – Ron Maupin Oct 5 at 0:20
  • Please do not cross-post on SE sites. You have asked at least twice on Server Fault and once here. Choose one site and delete the question on the others, or you may find all the questions deleted as cross-posts. – Ron Maupin Oct 5 at 18:07
  • "So can you please help me understand what causes the TCP layer from delaying the sending of #15337 until the ack for #15336?" We can give you answers about TCP theory, but your particular host TCP implementation is off-topic here, so, no, we cannot help with that. You are now definitely in off-topic territory. – Ron Maupin Oct 6 at 15:24
3

14908 is the input message from client. 14910 and 15337 are the two ouput messages.

14910 is the response to the client and clearly has the PSH flag set so was sent immediately by the server. The server then waits for the ACK from the client before sending 15337.

14910 is not delayed. But 15337 is delayed around 40ms.

This is the time it takes the ACK (15336) to transit from the client to the server, for the server to process it and for the next packet to transit from the server to the client.

As I can see, the 15337 packet is not sent until the ack 15336 is received.

Correct. This is how TCP generally operates.

So can you please help me understand what causes this delay.

You definitely do not provide enough information for us to provide you an answer with any certainty. You are also hamstringing our understanding by providing an image of a filtered capture rather than the capture.

You can note that roughly the same time difference exists between packet 15337 and packet 15756 (slightly shorter at 39.87ms vs 39.93ms). The difference in packet count between the this exchange is 419 vs the first exchange at 426.

So best guess is that this "delay" is the result of the client sending/receiving a significant amount of other traffic between the time it sends the ACK to the server and the next packet arrives from the server.

I couldn't tell you more than that as I don't have the packet capture and can't tell you what that other traffic might be. Nor can I tell you what kind of hardware the client is running or how much load the client might be under. But all of these details are getting outside the scope of this site anyhow.

  • About your comment 'This is how TCP generally operates'.. It suggests you are saying every sent packet shoud be acked by receiver for the next packet to be transmitted. Then why do I see many times when x.48 sends 2,3 or 4 packets before x.50 acks it? – PasanW Oct 5 at 16:05
  • 3
    No it doesn't suggest any such thing. Note the use of the PSH flag (which I point out). This flag in effect tells TCP to immediately "send this window" of data even if it isn't actually full or time to send it. It then waits for the ACK before sending the next window. This is how TCP generally operates. – YLearn Oct 5 at 16:11
  • Yes. But 15337 also has the PSH flag. I really can't understand why it is not sent without waiting for the ACK. – PasanW Oct 5 at 16:14
  • 3
    Because it is part of the next window. Think of it this way, the next window doesn't "open" until the ACK is received. Once it "opens" and the segment is received, it is again immediately sent even though that window isn't full. If both segments should be sent together, then the application should not be setting PSH on the data in 14910. – YLearn Oct 5 at 16:18
  • So the summary is if we do PSH into the current window TCP will never send the next packet until the ACK for the first is received (until it is filled or time to send triggers). I didn't know that. Thanks a lot for you help. – PasanW Oct 5 at 16:26

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.