Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

asked 2019-08-31 03:33:24 +0000

nimdrak gravatar image

Is it possible to re-transmit only the last packet at TCP flow?

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

Is it possible to re-transmit only the last packet at TCP flow?

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

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

Is it possible to re-transmit only the last packet at TCP flow?

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

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.

Is it possible to re-transmit only the last packet at TCP flow?

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.

EDIT EDIT:

* Attached a captured file for understanding *

https://www.dropbox.com/s/fmgkpybhiodtqdb/picture1.png?dl=0

Thank you for reading!