Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Receiver sends window update instead of DUP ACK

I have an issue whereby sender sends a bursty chunk of data across a WAN link of 50Mbps to receiver and some of the packets were lost in transit.

However the receiver, instead of sending DUP ACKs to sender for those packets which it did not receive (receiving instead those out of order packets with higher SEQ number), repeatedly sends many window_update packets, each time updating the receive window by 1 or 2 (window scaling is 12 ie. 4096 bytes).

This is despite the fact that the bytes in flight is much lower than the existing receive window (i.e. around 40kbytes in flight but 300*4096=1.2Mbytes of receive window.

The end result is that instead of getting multiple DUP ACKs from that receiver, therefore triggerring the sender to a fast retransmit, the sender in the end timed out based on RTO 200ms later to send the lost packet. This was ACK by receiver but the issue does not end here. The sender waited in binary backoff time ie. 400ms to send the next lost packet, and 800ms the third lost packet and so on. Throughput was slowed down tremendously.

What can I do to remediate this situation?

Questions: 1. is the receiver behaving correctly - I expected it to send DUP ACKs instead of window_update. 2. can the sender reset the RTO timer after getting the first ACK from the retransmission - I read that there are TCP New Reno partial acknowledgement that can speed up the recovery.

Receiver sends window update instead of DUP ACK

I have an issue whereby sender sends a bursty chunk of data across a WAN link of 50Mbps to receiver and some of the packets were lost in transit.

However the receiver, instead of sending DUP ACKs to sender for those packets which it did not receive (receiving instead those out of order packets with higher SEQ number), repeatedly sends many window_update packets, each time updating the receive window by 1 or 2 (window scaling is 12 ie. 4096 bytes).

This is despite the fact that the bytes in flight is much lower than the existing receive window (i.e. around 40kbytes in flight but 300*4096=1.2Mbytes of receive window.

The end result is that instead of getting multiple DUP ACKs from that receiver, therefore triggerring the sender to a fast retransmit, the sender in the end timed out based on RTO 200ms later to send the lost packet. This was ACK by receiver but the issue does not end here. The sender waited in binary backoff time ie. 400ms to send the next lost packet, and 800ms the third lost packet and so on. Throughput was slowed down tremendously.

What can I do to remediate this situation?

Questions: 1. Questions:

  1. is the receiver behaving correctly - I expected it to send DUP ACKs instead of window_update. 2. window_update.
  2. can the sender reset the RTO timer after getting the first ACK from the retransmission - I read that there are TCP New Reno partial acknowledgement that can speed up the recovery.