Revision history [back]

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

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: client:

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

Then server sends two more packets: 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
Win=28544

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

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

Then inmediately the server receives almost 400 duplicate acks and the Fast Retransmit is not generated: 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
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