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

TCP-Retransmission

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

nimdrak
3 ●1 ●2 ●5

updated 2019-09-01 13:22:12 +0000

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/1mtgtv5xof6...

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/fmgkpybhiod...

Thank you for reading!

edit retag flag offensive close merge delete

Comments

The PSH flag usually causes the the receiver to ACK to sender. Is your application (very) very time sensitive? There is about 9 ms between the initial transmission and the retransmission if I look at Time column. Maybe H1 was expecting an ACK in less than 9 ms? What is the expected RTO here?

Spooky ( 2019-09-01 02:21:33 +0000 )edit

@Spooky I always appreciate your help. Actually the application is mininet-virtual network. it is consist of only two hosts and a switch. Therefore, RTT and RTO is very short, I think. If you don't mind, could you check the captured files? https://www.dropbox.com/s/1mtgtv5xof6...https://www.dropbox.com/s/1mtgtv5xof6... Thank you so much.

nimdrak ( 2019-09-01 07:45:22 +0000 )edit

Can you post link for host1_data.pcapng please. Both links are for host2_data.pcapng. Thanks.

Spooky ( 2019-09-05 23:12:08 +0000 )edit

@Spooky Sure! I’m sorry. https://www.dropbox.com/s/5i1bgnv33ei...

nimdrak ( 2019-09-06 00:51:17 +0000 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2019-09-07 02:21:33 +0000

Spooky

191 ●47 ●7 https://www.wireshark.org

Looking at host1_data.pcapng

Up until frame 11774, .2 sends an ACK for every segment received from .1

But at this point the window size has reached 16MB and .2 can start sending an ACK only after receiving the last segments of a series with PSH flag. (Use Statistics - TCP Stream Graphs - Window Scaling to illustrate .1 to .2 window size increase.)

There are a few "intermediate" ACK here and there. They are seen for segments without PSH flag but I'm guessing there is something configured on .2 forcing it to send ACK before last segment with PSH flag.

Here's my analysis of what you are seeing:

Frames 15612 to 15656

New series of segments ending with one with PSH flag

Frame 15657

.1 retransmit last segment in series likely because it took too long for .2 to ACK. (RTO was 0.0019 base on last frame #15656 in series)

Frame 15658

Initial ("late") ACK for frame 15656 (RTT to ACK is 0.002)

Frane 15659

New ACK for retransmitted frame 15657

Frames 15660 to 15704

New series of segments ending with one with PSH flag

Frames 15704 to 15720

Series of ACK for latest series where .2 begins with one ACK per segment for 15704 to 15719 and then jumps to ACK later segments in the series but still does not ACK the last segment that has PSH flag.

Frame 15721

.1 retransmit last segment in series likely because it took too long for .2 to ACK. (RTO was 0.006 based on last frame #15704 in series)

Frame 15722

Initial ("late") ACK for 15704 OR ACK for retransmitted 15721 (RTT to ACK 0.006)

Frames 15723 to 15749

New series of segments ending with one with PSH flag

Frames 15750 to 15764

.2 sends ACK up to frame 15737

Frames 15765 to 15782

Segments for the rest of the series that started with #15723 and ending with segment showing PSH flag

Frame 15783

.2 sends ACK for last segment with PSH

Rest of capture

.1 will keep sending series of segments with the last one having PSH flag
.2 will ACK last segment in series (but also sometimes within series)

It looks to me like there will be retransmission from .1 when .2 takes longer than 0.002 to ACK.

(I tried looking at host2_data.pcapng but it shows weird timing for some packets. A frame from .1 with a higher number than the previous frame from .2 will show a lower timestamp. Not sure why that is.)

Hope this helps.

Cheers,

Spooky

edit flag offensive delete link

Comments

Before studying your answer, I deeply appreciate you. Actually I thought whether I have to give up. But I will not thanks to you. Thank you so much.

nimdrak ( 2019-09-10 00:45:01 +0000 )edit

add a comment

answered 2019-09-01 07:11:47 +0000

hackslash
1 ●3

updated 2019-09-01 16:17:01 +0000

grahamb

flag of United Kingdom of Great Britain and Northern Ireland

23835 ●4 ●976 ●227 https://www.wireshark.org

Long time ago , as u thk , tcp will retrans all packets even if only one lost, but later designer thk this way is tool slow and waste lots of time, so they design some options to heal this prob, like sack

h1-->h2   send 1460 bytes [num 1 ]
h1-->h2   send 1460 bytes [num 2 ]
h1-->h2   send 1460 bytes [num 3 ]
h1-->h2   send 1460 bytes [num 4 ]  (lost !!)
h2-->h1   send ack=3(that means i receive num 3 packet and packets which number lower than 3)
h1-->h2   send 1460 bytes [num 5 ]
h1-->h2   send 1460 bytes [num 6 ]
h2-->h1   send ack=6(i receive num 6 and num 5), sack=5-6,dup_ack=4(i didnt receive num 4, pls resent)
h1-->h2   send 1460 bytes [num 7 ]
h2-->h1   send ack=7(i receive num 7) sack=5-7,dup_ack=4(i didnt receive num 4, pls resent)
h1-->h2   send 1460 bytes [num 8 ]
h2-->h1   send ack=8(i receive num 8), sack=5-8,dup_ack=4(i didnt receive num 4, pls resent)
h1-->h2   send 1460 bytes [num 4 ]
h1-->h2   send 1460 bytes [num 9]
h1-->h2   send 1460 bytes [num 10 ]

continue ......

edit flag offensive delete link

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

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

Comments

2 Answers

Comments

Your Answer

Question Tools

Stats

Related questions

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

Comments

2 Answers

Comments

Your Answer

Question Tools

Stats

Related questions

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