TCP socket does not close when the ACK of a previous FIN segment is lost - simulation keeps running indefinitely

[Mauro Vidotto]

Hi all,
I am working on ns3.10. I found a problem when the ACK corresponding to  a previous FIN segment is lost.

Topology:

n0----------------n1----------------n2
         p2p               p2p

n0 is the source node (source application starts at 1second and ends at 49 seconds)
n1 acts as router and implements droptail queue.
n2 is the sink node (sink application starts at 0 seconds and ends at 58 seconds)

With this topology and the configuration provided in the file "testcase.cc" the original intention was to overflow the buffer of n1 to see how the congestion control algorithm of TCP behaved.
The problem detected is that the simulation is never ending (unless you set a Simulator::Stop at the end of the script), n2 is always scheduling a retransmission for the FIN segment and n0 complains about this segment for being out of range (sequence number out of range).
After several test and analysing the pcap captures I got to the conclusion that this problem is only presented when the ACK (n0->n2) of a previous FIN package (n2->n0) is lost .


Fragments of log Output:

58 [node 2] TcpSocketBase:Close(0x89fbe70)
58 [node 2] TcpSocketBase:DoClose(0x89fbe70)
58 [node 2] TcpSocketBase:SendEmptyPacket(0x89fbe70, 1)
58 [node 2] Schedule retransmission timeout at time 58 to expire at time 60
58 [node 2] ESTABLISHED -> FIN_WAIT_1
58 [node 2] TcpSocketBase:Close(0x89fb1f8)
58 [node 2] TcpSocketBase:DoClose(0x89fb1f8)
58 [node 2] TcpSocketBase:CloseAndNotify(0x89fb1f8)
58 [node 2] LISTEN -> CLOSED
58.0057 [node 0] Socket 0x89fb678 forward up 192.168.1.2:8080 to 192.168.0.1:49153
58.0057 [node 0] TcpSocketBase:ProcessEstablished(0x89fb678, 8080 > 49153 [ FIN  ACK ] Seq=1 Ack=642641 Win=65535)
58.0057 [node 0] TcpSocketBase:PeerClose(0x89fb678, 8080 > 49153 [ FIN  ACK ] Seq=1 Ack=642641 Win=65535)
58.0057 [node 0] Accepted FIN at seq 1
58.0057 [node 0] ESTABLISHED -> CLOSE_WAIT
58.0057 [node 0] TCP 0x89fb678 calling NotifyNormalClose
58.0057 [node 0] TcpSocketBase:SendEmptyPacket(0x89fb678, 16)
RxDrop at 58.007


60 [node 2] TcpSocketBase:SendEmptyPacket(0x89fbe70, 17)
60 [node 2] Schedule retransmission timeout at time 60 to expire at time 62
60.0057 [node 0] Socket 0x89fb678 forward up 192.168.1.2:8080 to 192.168.0.1:49153
60.0057 [node 0] At state CLOSE_WAIT received packet of seq 1 out of range [2:1]
62 [node 2] TcpSocketBase:SendEmptyPacket(0x89fbe70, 17)
62 [node 2] Schedule retransmission timeout at time 62 to expire at time 64
62.0057 [node 0] Socket 0x89fb678 forward up 192.168.1.2:8080 to 192.168.0.1:49153
62.0057 [node 0] At state CLOSE_WAIT received packet of seq 1 out of range [2:1]
64 [node 2] TcpSocketBase:SendEmptyPacket(0x89fbe70, 17)
64 [node 2] Schedule retransmission timeout at time 64 to expire at time 66
64.0057 [node 0] Socket 0x89fb678 forward up 192.168.1.2:8080 to 192.168.0.1:49153
64.0057 [node 0] At state CLOSE_WAIT received packet of seq 1 out of range [2:1]



Can some one comment on this issue?

I am attaching to the email the file "testcase.cc" that I was using to analyse the problem and the log output I got when running it.

Thanks in advance
Mauro Vidotto

[Chris Dennett]

Hi Mauro, try with assets enabled in debug mode too, and see if you
get any problems. There's a number of TCP asserts that will be
breached with bad behaviours. I'm wondering if you're getting a
similar problem to the one which I reported to the list a while back
(although it is interaction with real Java apps, mainly a TCP stress
test).

Cheers,
Chris

> --
> You received this message because you are subscribed to the Google Groups
> "ns-3-users" group.
> To post to this group, send email to ns-3-...@googlegroups.com.
> To unsubscribe from this group, send email to
> ns-3-users+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/ns-3-users?hl=en.
>

[John Abraham]

I believe this is a bug. I filed
https://www.nsnam.org/bugzilla/show_bug.cgi?id=1256
I also suspect the fix may be non-trivial.

>  testcase.log.tar.gz
> 357KViewDownload
>
>  testcase.cc.tar.gz
> 2KViewDownload

[Mauro Vidotto]

Hi John,

Thanks for the answer.

I was thinking that this issue could be a bug also.

One more comment on this problem:
Analyzing the pcap capture of the node n2 it is possible to see that after n2 sends the FIN segment and before the retransmissions of the FIN segment is done n2 sends some segment with its sequences number equal to 2 (it seems that the sequence number was advanced after the FIN segment was sent even when the FIN segment has a size of 0 in its payload- RFC specifies this, I believe). From this packages in the capture I suspect (I have not analysed all the code of the TCP stack!) that the sended segments are kept in some kind of internal buffer/queue in case they have to be retransmited. If some segment have to be retransmitted they will be copied/taken from this queue, the retransmitted packet will be an exact copy of its first transmission (the tcp header will not be modified, specially the Sequence number). This is why node n0 sees the retransmissions of the FIN segment but with the sequence number equal to 1 (n0 just ignores this retransmissions as as for him the sequence number should be 2 or higher). Maybe retransmission of the FIN segment should  be treated as a special case (sequence number advanced?). I don't know what the RFC specifies for the case of losing the ACK of a FIN segment, what should be the correct behaviour of the nodes (any idea which RFC specifies this?).

By the way, is it possible for us (users of ns3) to subscribe to get some kind of notice (email) when some puts information in bugzilla for an specific BUG?
 

Regards
Mauro Vidotto

2011/9/6 John Abraham <john...@gmail.com>

--

[John Abraham]

Yes, that was one of the problems identified in the bug


2. The SND.NXT (m_TxNextSequence) was bumped up for CLOSING/FIN_WAIT1/
LAST_ACK
states.However the very nature of these states imply that the end-
point has
completed sending its highest sequence number which is the FIN
sequence number

You could get a ns-3 bugzilla account (sign-up as a new user) & then
add your name to the cc-list
-john

> 2011/9/6 John Abraham <johnj...@gmail.com>