Reason for delay in Fast-Retransmission from Server

asked 2020-04-04 20:10:22 +0000

Harneet Singh
3 ●1 ●2 ●4

updated 2020-04-05 08:00:31 +0000

Hi Everyone,

I am trying to understand that after receiving 3 DUP ACKS from the client a few times, why Server sent the TCP Retransmission very late.

In Frame 531 we can see that the next sequence from the Server should be 499853 but the server sends a higher sequence number 501265 and TCP says that the previous segment is not captured. In frame 534, the Client sends the ACK 499583 and in 535, it sends the same ACK value 499853 as DUP ACK.

Then again, the Client sent 4 DUP ACKS starting 544-547. In Frame 548 again sent a higher sequence number of 516797. The client sent 3 Dup ACKS starting 551-553 and the server again sent a higher sequence number of 521033.

Finally, the client again sent 3 DUP ACKS from 557-559 and the Server sent the sequence number of 499583 as TCP FAST RETRANSMISSION in frame 560.

Can anyone explain to me the reason that why Server did not send the segment starting 499583 in frame 548 and rather it was sent in 560. I understand as per the Congestion algorithm Fast Retransmission should have been done as soon as 3 DUP ACKs were received.

I appreciate any insight on the same. Below is the link for the PCAP:-

https://easyupload.io/jzl28b

Password for the file - Admin@123

edit retag flag offensive close merge delete

Comments

Is there a password on the file? Can you make it public?

Chuckc ( 2020-04-04 21:36:34 +0000 )edit

Please share the password for the download so we can have a look at the tracefile.

One very common reason for not seeing the fast retransmission after 3 DUP-ACK's is when you are capturing on the receiving side. In that case, there are still packets on the wire before the 3 DUP-ACKs reach the server and trigger the fast retransmission (this takes 1 roundtrip). Did you capture on the receiving or the sending side?

SYN-bit ( 2020-04-04 23:24:34 +0000 )edit

Hi Guys, Sorry I missed to add the password It's been added now. Please check if PCAP is accessible.

@SYN- BIt - I don't think that scenario is applicable here as Server sent the segments with higher sequence numbers twice after it received 3 DUP ACKS and only it was the third time Server sent the data. This was captured on the client machine and the server is sending the data.

Harneet Singh ( 2020-04-05 08:09:55 +0000 )edit

add a comment

answered 2020-04-05 09:13:48 +0000

SYN-bit

18528 ●9 ●343 ●255 https://SYN-b.it

From the 3-way-handshake I see that there is a RTT of ~150ms for this TCP connection. I also see that you are capturing on the client (192.168.0.105) as the delta between the SYN and the SYN/ACK is high and the delta between the SYN/ACK and the ACK is low. Also the ACK has a length of 54 bytes, which is lower than the minimum length of an ethernet packet. This usually means you capture on the client itself and the packet was captured before the NIC could add the padding.

Then between frame 531 and frame 532 a segment got lost and therefor you see DUP-ACKs for all the segments that are coming in. As there is a RTT of 150ms, it takes a while for the DUP-ACKs to reach the server to trigger a fast retransmission. If you look at the delta time between frame 539 (the third DUP-ACK) and frame 560 (the fast retransmission), you can see that ~146 ms have passed. This is in line with the iRTT of ~150ms. All the extra DUP-ACKs are for all the packets that were already on their way from the server to the client before it has received the first 3 DUP-ACKs.

edit flag offensive delete link

Comments

Thank you SYN-bit for the explanation. I see that the time diff is approx 147 between 539 and 560 and that's less than 150 and it makes sense to me.

Harneet Singh ( 2020-04-05 09:46:20 +0000 )edit

I'm glad it cleared things up :-)

Could you accept the answer by clicking on the checkmark? This way other people know it has been answered...

SYN-bit ( 2020-04-05 11:12:39 +0000 )edit

Done... :)

Harneet Singh ( 2020-04-05 11:15:05 +0000 )edit

Perfect, thanks! BTW there are some interesting parts in the trace file where wireshark does not show the correct analysis (for instance, frame 61 should be marked as Out-of-order instead of fast retransmission). Do you mind if we will use this trace file as a source for Quality Assurance? If needed I can anonimize the trace first.

SYN-bit ( 2020-04-05 11:25:53 +0000 )edit

Yeah, I see that. Like it marked 55 and 62. Please go for it.

It's just a random trace that I took on my machine to understand a few things. Trying to improve my skills :)

Harneet Singh ( 2020-04-05 11:30:45 +0000 )edit

Hi Hameet, I'm digging a little deeper in your trace file and it seems this trace was filtered out of a bigger capture file. Is that correct? Would it be possible to share the original file we me personally too? In case there is sensitive information in it and you are not able to share it, could you send me the output of the command:

tshark -r <file> -Y ip.src ==192.168.0.105 -T fields -e frame.num -e ip.id

and also a screenshot of the capture file properties?

You can find my email on my users-page here :-)

SYN-bit ( 2020-04-05 14:39:27 +0000 )edit

Impressive :). Below is the link for the file:-

https://easyupload.io/imkxnu

There is no sensitive information inside it. I plan to watch your Tshark video from sharkfest soon as I heard that term today for the first time. Thanks for your help.:)

Harneet Singh ( 2020-04-05 16:29:29 +0000 )edit

Thanks! Hmmm... seems that all packets were captured. Interesting trace!

SYN-bit ( 2020-04-05 18:56:30 +0000 )edit

add a comment

Reason for delay in Fast-Retransmission from Server

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Reason for delay in Fast-Retransmission from Server edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Reason for delay in Fast-Retransmission from Server