0

I try to understand the TCP behavior, especially re-transmission.

I did a small experiment and find the curious thing.

The only last packet is re-transmitted. Why do this happen?

I think if the last packet is time-out, then the other packets have to be time-out because All packets in the flow have same RTT and RTO.

At first, I think it is due to delayed ack. Therefore, I did a same experiment with setsockopt TCP_QUICKACK. But I saw the same phenomenon. ( But I am not sure yet, that the cause of this is not delayed ack. )

Could you give me a little help? Thank you for reading :)

For example,

[1] H1->H2 send a 1500 bytes packet

[2] H1->H2 send a 1500 bytes packet

[3] H1->H2 send a 1500 bytes packet

...

[n] H1->H2 send a 800 bytes packet [the last packet]

[n+1] H1->H2 re-send a 800 bytes packet [the last packet]

[n+2] H2->H1 send an ACK.

[the raw data from wireshark]

1735203 51.249349738    10.0.0.1    10.0.0.2    TCP 1514    35250 → 50021 
[ACK] Seq=16124342 Ack=1 Win=58 Len=1448 TSval=902298 TSecr=902296

1735204 51.249349999    10.0.0.1    10.0.0.2    TCP 1514    35250 → 50021 
[ACK] Seq=16125790 Ack=1 Win=58 Len=1448 TSval=902298 TSecr=902296

1735205 51.249350340    10.0.0.1    10.0.0.2    TCP 866 35250 → 50021 
[PSH, ACK] Seq=16127238 Ack=1 Win=58 Len=800 TSval=902298 TSecr=902296

1735207 51.258283589    10.0.0.1    10.0.0.2    TCP 866 
[TCP Retransmission] 35250 → 50021 [PSH, ACK] Seq=16127238 
Ack=1 Win=58 Len=800 TSval=902301 TSecr=902298

1735208 51.258288919    10.0.0.2    10.0.0.1    TCP 66  50021 → 35250 
[ACK] Seq=1 Ack=16128038 Win=32766 Len=0 TSval=902301 TSecr=902298

EDIT:

** Attached captured files **

https://www.dropbox.com/s/1mtgtv5xof6octn/host2_data.pcapng?dl=0

https://www.dropbox.com/s/1mtgtv5xof6octn/host2_data.pcapng?dl=0

Each files is the packet captured at each host.

If you don't mind, please check the files.

Improve this question

1 Answer 1

Reset to default
1

I think if the last packet is time-out, then the other packets have to be time-out because All packets in the flow have same RTT and RTO.

No. If the last segment transmission times out it's because it hasn't been ACKed within the RTO. All segments before seem to have been properly ACKed as they're not retransmitted.

This can be caused by a delayed ACK (when its delay+RTT is larger than RTO), or the segment or its ACK has actually been lost. A delayed ACK should be well below a realistic (RTO minus RTT), but it's not impossible to cause a retransmission.

Improve this answer
7
  • Thank you for your comment. You mean a delay ACK make this situation that only the last segment is lost and re-tranmitted. Could you explain it in detail? I know the behavior of delayed ACK that many segments can be acknowledged by at a time. But I couldn't understand how it make only the last segment re-transmitted. I appreciate you:)
    – nimdrak
    Aug 31, 2019 at 14:16
  • 1
    The destination can delay an ACK in anticipation of additional data, saving the (single-segment) ACK overhead when it can ACK multiple segments just a bit later. Of course, an ACK delayed for too long (RTO-RTT) can cause a retransmission.
    – Zac67 ♦
    Aug 31, 2019 at 16:35
  • I appreciate your comment. But in the case that ACK is delayed for saving ACK overhead, not only the last segment but also the others wait a ACK from receiver. Therefore, I think all segments have to re-transmitted, not only the last segment. Could you fix my logic?
    – nimdrak
    Sep 1, 2019 at 7:19
  • 1
    You were talking about a retransmit of the last segment, so apparently, all previous segments have been ACKed.
    – Zac67 ♦
    Sep 1, 2019 at 7:57
  • 1
    The pcaps show 10.0.0.2 ACKing all the time. Where's the problem?
    – Zac67 ♦
    Sep 1, 2019 at 12:18

Your Answer

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

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