TCP Out-of-order by server and not Fast Retransmit

asked 2020-02-25 16:41:03 +0000

Carlos Pupiales gravatar image

updated 2020-02-25 16:51:41 +0000

grahamb gravatar image

Hi guys,

I'm expriencing a kind of "bug" with TCP and wireshark. I have an iperf session between server and client with an intermediate buffer which try to deal with multipath. I mean, the server generates TCP traffic, then this traffic arrives to an intermediate node where packets are send through different paths (considering lower layers aspects) and then the traffic is recombined (considering lower layers aspects) in the recepcion node. Therefore, to ensure in-sequence delivery to Transport Layer I buffer the out-of-order packets until fill the gap.

After testing my implementation, I see that sometimes TCP does't generate a Fast-Retransmit after receiving a third duplictae ack and follows this behaviour:

Receives this ACK from client:

172.16.0.11 5201 → 60474 [ACK] Seq=1 Ack=12059930 Win=1336320 Len=0 TSval=1370662236 TSecr=3494474186 SLE=12061342 SRE=12062754

Then server sends two more packets:

172.16.0.1  60474 → 5201 [ACK] Seq=12734866 Ack=1 Win=28544
172.16.0.1  60474 → 5201 [ACK] Seq=12736278 Ack=1 Win=28544

Then the sever generates an out-of-order packet, why?

172.16.0.1  [TCP Out-Of-Order] 60474 → 5201 [ACK] Seq=12059930 Ack=1 Win=28544

Then inmediately the server receives almost 400 duplicate acks and the Fast Retransmit is not generated:

172.16.0.11 [TCP Dup ACK 13390#1] 5201 → 60474 [ACK] Seq=1 Ack=12059930 Win=1336320 Len=0 TSval=1370662236 TSecr=3494474186 SLE=12064166 SRE=12065578 SLE=12061342 SRE=12062754

Therefore I have the following questions:

  1. Why server sends this TCP Out-Of-Order? What does this mean?
  2. Why a Fast Retransmission is not generated after third TCP Dup ACK?
  3. Why a Retransmission is not generated (apparently), but following the tcp windows scaling I see the effect of Retranmission in the throughput (I mean slow start process begins after the TCP Out of order packet sent by the server)?

I share with you the pcap file (https://drive.google.com/open?id=1hGsVH2e0ZWnSbXgcqlmnCT2v_8OP7dvk) in order you can analyze it. The mentioned issue starts in frame Nº 13390, time 4.085388.

Thanks in advance for your help to understant this issue.

Carlos

edit retag flag offensive close merge delete

Comments

https://ask.wireshark.org/question/90...
Maybe the explanation above helps.

Chuckc gravatar imageChuckc ( 2020-02-26 01:09:02 +0000 )edit

Are you taking into consideration the presence of TCP Selective Acknowledgements (SACK)?

The SYN packets from both systems indicated support for SACK.

Frame 13390 just happens to be the first frame with the SACK option.

Frame 13390: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
...
Internet Protocol Version 4, Src: 172.16.0.11, Dst: 172.16.0.1
Transmission Control Protocol, Src Port: 5201, Dst Port: 60474, Seq: 1, Ack: 12059930, Len: 0
...
    Acknowledgment number: 12059930    (relative ack number)
...
    Options: (24 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps, No-Operation (NOP), No-Operation (NOP), SACK
        TCP Option - No-Operation (NOP)
        TCP Option - No-Operation (NOP)
        TCP Option - Timestamps: TSval 1370662236, TSecr 3494474186
        TCP Option - No-Operation (NOP)
        TCP Option - No-Operation (NOP)
        TCP Option - SACK 12061342-12062754
            Kind: SACK (5)
            Length: 10
            left edge = 12061342 (relative)
            right edge = 12062754 (relative)
            [TCP SACK Count: 1]
    [SEQ/ACK analysis]
        [This is an ACK to the segment ...
(more)
Jim Young gravatar imageJim Young ( 2020-02-26 06:49:50 +0000 )edit

Thanks for your answer. So what I understood from your explanation is that the server receives the ACK and then a SACK and that is why the server generates the Out-of-order packet which in fact is a retransmission?

Carlos Pupiales gravatar imageCarlos Pupiales ( 2020-02-26 09:30:59 +0000 )edit
add a comment