The server socket does not forward data packet up if it has not received the ACK during 3-way handshake

[Samet Tonyalı]

Dear all,

I downloaded the ns-3-dev a couple of days ago and tested several applications running on top of TCP. While analyzing the results, I realized that one of the nodes is not receiving the data although its sender has established the connection successfully (i.e., its socket is in ESTABLISHED state). Further investigation showed that the server socket is receiving data packets but its state is still SYN_RCVD. I guess that's why the socket does not forward the data up. I concluded this because those servers whose socket is in ESTABLISHED state could receive the data while this certain server couldn't. I gave sample output from my log.

The server that can receive data:

[node 59] TcpL4Protocol:Receive(0x55fd57ad1a60, 0x55fd57d05720, tos 0x0 DSCP Default ECN Not-ECT ttl 64 id 4 protocol 6 offset (bytes) 0 flags [none] length: 216 7.1.0.69 > 7.1.0.60, 0x55fd57b2d170)
 [node 59] TcpL4Protocol:PacketReceived(0x55fd57ad1a60, 0x55fd57d05720, 0 > 0 Seq=0 Ack=0 Win=65535, 05-04-07:01:00:45, 05-04-07:01:00:3c)
 [node 59] TcpL4Protocol 0x55fd57ad1a60 receiving seq 329 ack 1 flags ACK data size 196
 [node 59] TcpL4Protocol 0x55fd57ad1a60 received a packet and now forwarding it up to endpoint/socket
 [node 59] Socket 0x55fd57e1f2f0 forward up 7.1.0.69:49153 to 7.1.0.60:8000
 [node 59] TcpSocketBase:ProcessOptionTimestamp(0x55fd57e1f2f0, 0x55fd57e5e490)
 [node 59] 59 Got timestamp=245794 and Echo=185795
 [node 59] TcpSocketBase:UpdateWindowSize(0x55fd57e1f2f0, 49153 > 8000 [ACK] Seq=329 Ack=1 Win=32768 ns3::TcpOptionTS(245794;185795) ns3::TcpOptionEnd(EOL))
 [node 59] Received (scaled) window is 131072 bytes
 [node 59] updating rWnd to 131072
 [node 59] TcpSocketBase:ProcessEstablished(0x55fd57e1f2f0, 49153 > 8000 [ACK] Seq=329 Ack=1 Win=32768 ns3::TcpOptionTS(245794;185795) ns3::TcpOptionEnd(EOL))
 [node 59] TcpSocketBase:ReceivedAck(0x55fd57e1f2f0, 49153 > 8000 [ACK] Seq=329 Ack=1 Win=32768 ns3::TcpOptionTS(245794;185795) ns3::TcpOptionEnd(EOL))
 [node 59] TcpSocketBase:ReadOptions(0x55fd57e1f2f0, 49153 > 8000 [ACK] Seq=329 Ack=1 Win=32768 ns3::TcpOptionTS(245794;185795) ns3::TcpOptionEnd(EOL))
 [node 59] TcpSocketBase:ProcessAck(0x55fd57e1f2f0, 1, 0)
 [node 59] ACK of 1, there is no need to process (we haven't data to transmit)
 [node 59] TcpSocketBase:SendPendingData(0x55fd57e1f2f0, 1)
 [node 59] TcpSocketBase:ReceivedData(0x55fd57e1f2f0, 49153 > 8000 [ACK] Seq=329 Ack=1 Win=32768 ns3::TcpOptionTS(245794;185795) ns3::TcpOptionEnd(EOL))
 [node 59] Data segment, seq=329 pkt size=164
MaskedAggregationAggregator:HandleRead(0x55fd57b4f0a0, 0x55fd57e1f2f0)
 [node 59] TcpSocketBase:RecvFrom(0x55fd57e1f2f0, 4294967295, 0)
 [node 59] TcpSocketBase:Recv(0x55fd57e1f2f0)
Aggregator Meter 59  received a packet in size of 492 bytes @ +245794947707.0ns

The one that cannot:

[node 32] TcpL4Protocol:Receive(0x55fd57a9b550, 0x55fd57e8d4c0, tos 0x0 DSCP Default ECN Not-ECT ttl 64 id 3 protocol 6 offset (bytes) 0 flags [none] length: 500 7.1.0.42 > 7.1.0.33, 0x55fd57b16b60)
 [node 32] TcpL4Protocol:PacketReceived(0x55fd57a9b550, 0x55fd57e8d4c0, 0 > 0 Seq=0 Ack=0 Win=65535, 05-04-07:01:00:2a, 05-04-07:01:00:21)
 [node 32] TcpL4Protocol 0x55fd57a9b550 receiving seq 1 ack 1 flags ACK data size 480
 [node 32] TcpL4Protocol 0x55fd57a9b550 received a packet and now forwarding it up to endpoint/socket
 [node 32] Socket 0x55fd57be12f0 forward up 0.0.0.0:0 to 7.1.0.33:8000
 [node 32] TcpSocketBase:ProcessOptionTimestamp(0x55fd57be12f0, 0x55fd57cdbf70)
 [node 32] 32 Got timestamp=100 and Echo=4165
 [node 32] TcpSocketBase:UpdateWindowSize(0x55fd57be12f0, 49153 > 8000 [ACK] Seq=1 Ack=1 Win=32768 ns3::TcpOptionTS(250076;4165) ns3::TcpOptionEnd(EOL))
 [node 32] Received (scaled) window is 131072 bytes
 [node 32] State less than ESTABLISHED; updating rWnd to 131072
 [node 32] TcpSocketBase:ProcessListen(0x55fd57be12f0, 49153 > 8000 [ACK] Seq=1 Ack=1 Win=32768 ns3::TcpOptionTS(250076;4165) ns3::TcpOptionEnd(EOL))

I am not a TCP expert, but was the socket not supposed to consider this data packet an "implicit ACK" that he couldnt receive during the 3-way handshake and forward the data packets up?

Thank you for your gentle answers in advance :)

Samet

[Samet Tonyalı]

Hi Tommaso,

I wanted to CC you because this is getting more interesting as I dig it up and seemed to me a potential bug.

In the second case above, I was thinking node 32 is in SYN_RCVD state because it had received a SYN and switched to the SYN_RCVD above in the log file (not included in the previous e-mail), but it seems it is in LISTEN state (TcpSocketBase:ProcessListen). This is weird. I think it is changing its state after a while since it has not received the ACK.

When I checked this in the web I found two entries that say the data packets should be considered as implicit ACKs.

https://stackoverflow.com/questions/16259774/what-if-a-tcp-handshake-segment-is-lost

https://networkengineering.stackexchange.com/questions/32504/what-happens-on-the-server-when-a-client-does-not-respond-to-the-syn-ack-segme

However, the case is different here because the state is LISTEN not SYN_RCVD. Is it an expected behaviour of TCP to switch from SYN_RCVD (or SYN_SENT) to LISTEN (or CLOSED) if a specific event occurs?

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+unsubscribe@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at https://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

--

Samet TONYALI

Tel: 618-303 78 11