New TCP Socket Architecture - Revision history

Tomh: deprecate this page

2015-07-18T18:14:28Z

deprecate this page

← Older revision		Revision as of 18:14, 18 July 2015
Line 1:		Line 1:
	''This page describes ~~an on-going~~ rework on NS-3 TCP''		'''Note (July 2015)'''
			''This page describes past rework of NS-3 TCP, around the time of ns-3.8. It has stale information (i.e. the commands may no longer work and the code has changed) and is just left here for historical reference.''

	----		----

Adriantam: /* Verification */

2010-09-03T06:21:55Z

Verification

← Older revision		Revision as of 06:21, 3 September 2010
Line 194:		Line 194:
	This script is reused in the tcp-loss-response as well. It is referred as trTidy.pl below.		This script is reused in the tcp-loss-response as well. It is referred as trTidy.pl below.

	==== Case 0 ====		==== Case 0: Send one packet of data to verify the connection establishment and closing ====
	The output of "tcp-testcase --testcase=0 --verbose=1" is as follows:		The output of "tcp-testcase --testcase=0 --verbose=1" is as follows:

Line 261:		Line 261:
	From the above, with the lines marked TcpSocketBase, one can verify the TCP state machine worked correctly. Note that, in the old TCP code, the closing behaviour is slightly different. Usually in simulation, the server side of a connection is simulated by a PacketSink application and the client side is initiating the connect and close operations. In the old code, upon the client invoked Socket::Close(), a FIN packet is sent to the server and the server just respond with an ACK. In the new code, besides the ACK-to-FIN response, there will be another FIN packet sent in case the server side confirmed that it has nothing else to send. This is the case for PacketSink, as it called Socket::ShutdownSend() at the beginning. In the old code, the TCP state machine at client side will move from SYN_SENT to ESTABLISHED to FIN_WAIT_1 and FIN_WAIT_2 but never TIME_WAIT as it does not receive a FIN from the server side. We extended this to make the state machine transition complete. The last two line in the output above shows that ''two'' TCP sockets are closed. The first CLOSED state refers to the socket that handles the connected flow. The second one refers to the socket that is listening on port 50000 to wait for a new connection.		From the above, with the lines marked TcpSocketBase, one can verify the TCP state machine worked correctly. Note that, in the old TCP code, the closing behaviour is slightly different. Usually in simulation, the server side of a connection is simulated by a PacketSink application and the client side is initiating the connect and close operations. In the old code, upon the client invoked Socket::Close(), a FIN packet is sent to the server and the server just respond with an ACK. In the new code, besides the ACK-to-FIN response, there will be another FIN packet sent in case the server side confirmed that it has nothing else to send. This is the case for PacketSink, as it called Socket::ShutdownSend() at the beginning. In the old code, the TCP state machine at client side will move from SYN_SENT to ESTABLISHED to FIN_WAIT_1 and FIN_WAIT_2 but never TIME_WAIT as it does not receive a FIN from the server side. We extended this to make the state machine transition complete. The last two line in the output above shows that ''two'' TCP sockets are closed. The first CLOSED state refers to the socket that handles the connected flow. The second one refers to the socket that is listening on port 50000 to wait for a new connection.

	==== Case 1 ====		==== Case 1: Send 100 packets of data to check the sliding window operation ====

	Output with insignificant lines removed. The TCP socket has delayed ACK disabled and network buffer of 20 packets:		Output with insignificant lines removed. The TCP socket has delayed ACK disabled and network buffer of 20 packets:
Line 379:		Line 379:
	The above shows that the TCP socket notices triple duplicated acknowledgements. We will evaluate the correctness of congestion window behaviour using another test program.		The above shows that the TCP socket notices triple duplicated acknowledgements. We will evaluate the correctness of congestion window behaviour using another test program.

	==== Case 2 ====		==== Case 2: Dropping the SYN packet at three way handshake ====

	This is to verify a TCP client can survive a SYN packet lost. Output as follows:		This is to verify a TCP client can survive a SYN packet lost. Output as follows:
Line 436:		Line 436:
	The SYN packet is sent at time 0 and at time 336us, it was dropped by the intermediate hop (node 1). The SYN packet is retransmitted at time 3s.		The SYN packet is sent at time 0 and at time 336us, it was dropped by the intermediate hop (node 1). The SYN packet is retransmitted at time 3s.

	==== Case 3 ====		==== Case 3: Dropping the SYN+ACK packet at three way handshake ====

	This is to check a connection can survive a SYN+ACK lost.		This is to check a connection can survive a SYN+ACK lost.
Line 485:		Line 485:
	The SYN+ACK packet is sent by node 2 at time 672us and it was dropped by node 1 at 0.001008s. Because node 0 cannot see the SYN+ACK coming back, it resends the SYN at time 3s.		The SYN+ACK packet is sent by node 2 at time 672us and it was dropped by node 1 at 0.001008s. Because node 0 cannot see the SYN+ACK coming back, it resends the SYN at time 3s.

	==== Case 4 ====		==== Case 4: Dropping the ACK packet at three way handshake ====

	This checks the connection can survive from the lost of ACK in three way handshake.		This checks the connection can survive from the lost of ACK in three way handshake.
Line 533:		Line 533:
	The ACK to complete the three way handshake is sent at 0.001344s, and it is dropped by node 1 at 0.00168s. Node 2 receive the data packet (id 2) and this also triggers the correct state change.		The ACK to complete the three way handshake is sent at 0.001344s, and it is dropped by node 1 at 0.00168s. Node 2 receive the data packet (id 2) and this also triggers the correct state change.

	==== Case 5 ====		==== Case 5: Connection initiator send an immediate FIN packet upon receiving SYN+ACK ====

	This demonstrates the case that the server received a FIN in SYN_RCVD state. The behaviour is created by dropping the ACK packet in 3WHS and send a FIN after the client socket moved to ESTABLISHED state.		This demonstrates the case that the server received a FIN in SYN_RCVD state. The behaviour is created by dropping the ACK packet in 3WHS and send a FIN after the client socket moved to ESTABLISHED state.
Line 568:		Line 568:
	The FIN is sent at time 0.002s. At time 0.002672s, state of node 2 changed from SYN_RCVD to CLOSE_WAIT.		The FIN is sent at time 0.002s. At time 0.002672s, state of node 2 changed from SYN_RCVD to CLOSE_WAIT.

	==== Case 6 ====		==== Case 6: Simultaneous close ====

	This shows the simultaneous close of TCP sockets.		This shows the simultaneous close of TCP sockets.
Line 593:		Line 593:
	The FIN packet from node 0 is sent at time 0.036368s. Node 2 respond with ACK at time 0.061376s, which is dropped at time 0.061712. The FIN packet from node 2 is therefore the next packet arrived node 0, causing it moved to CLOSING state.		The FIN packet from node 0 is sent at time 0.036368s. Node 2 respond with ACK at time 0.061376s, which is dropped at time 0.061712. The FIN packet from node 2 is therefore the next packet arrived node 0, causing it moved to CLOSING state.

	==== Case 7 ====		==== Case 7: Lost of close initiator's FIN packet ====

	This shows a connection can survive from lost of first FIN packet.		This shows a connection can survive from lost of first FIN packet.
Line 624:		Line 624:
	The bare FIN packet is sent at time 0.04s by node 0, and is dropped at time 0.053376s. Node 0 received ACK to sequence 5001 at time 0.062048s, which moves the retransmission timeout to 0.262048s. So upon retransmission timeout, the FIN packet is resent.		The bare FIN packet is sent at time 0.04s by node 0, and is dropped at time 0.053376s. Node 0 received ACK to sequence 5001 at time 0.062048s, which moves the retransmission timeout to 0.262048s. So upon retransmission timeout, the FIN packet is resent.

	==== Case 8 ====		==== Case 8: Lost of close responder's FIN packet ====

	This demonstrates the case of losing close responder's FIN packet.		This demonstrates the case of losing close responder's FIN packet.

Adriantam: /* Result from tcp-testcases */

2010-09-02T23:33:27Z

Result from tcp-testcases

← Older revision		Revision as of 23:33, 2 September 2010
Line 192:		Line 192:
	};		};

	This script is reused in the tcp-loss-response as well. It is referred as ~~tidy~~.pl below.		This script is reused in the tcp-loss-response as well. It is referred as trTidy.pl below.

	==== Case 0 ====		==== Case 0 ====

Adriantam: /* Result from tcp-loss-response */

2010-09-02T23:24:25Z

Result from tcp-loss-response

← Older revision		Revision as of 23:24, 2 September 2010
Line 671:		Line 671:
	set yrange [0:100000]		set yrange [0:100000]
	set xrange [0:3.5]		set xrange [0:3.5]
			set xtics 0.5
			set mxtics 2
			set mytics 2
			set grid mxtics xtics ytics mytics
	set log "TcpNewReno.0.eps"		set log "TcpNewReno.0.eps"
	plot \		plot \

Adriantam: /* Result from tcp-loss-response */

2010-09-02T21:30:09Z

Result from tcp-loss-response

← Older revision		Revision as of 21:30, 2 September 2010
Line 660:		Line 660:
	done		done
	done		done
	~~The figures showing hereinafter~~ is ~~produced using GNU plot with~~ the following script:		gnuplot plot.gp
			for variant in TcpNewReno TcpReno TcpTahoe ; do
			for cnt in 0 1 2 3 4 ; do
			convert -density 150 $variant.$cnt.eps $variant.$cnt.png
			done
			done
			where plot.gp is the following GNU Plot script:
	set key left		set key left
	set terminal postscript eps enhanced color		set terminal postscript eps enhanced color
Line 746:		Line 752:
	"< grep ^r TcpTahoe.4.log \| ./trTidy.pl \| grep N0 \| perl -ne 's/^..//;s/\t.Ack=/ /;s/ Win.$//;split;print $_[0].q{ }.($_[1]%40000).q{\n}'" using 1:2 w p pt 2 lc rgb "#00FF00" title "ack", \		"< grep ^r TcpTahoe.4.log \| ./trTidy.pl \| grep N0 \| perl -ne 's/^..//;s/\t.Ack=/ /;s/ Win.$//;split;print $_[0].q{ }.($_[1]%40000).q{\n}'" using 1:2 w p pt 2 lc rgb "#00FF00" title "ack", \
	"< grep cwnd TcpTahoe.4.log \| grep seconds \| perl -pe 's/^.*to //;s/ at time / /;s/ seconds//'" using 2:1 w p pt 1 lc rgb "#FF0000" title "cwnd"		"< grep cwnd TcpTahoe.4.log \| grep seconds \| perl -pe 's/^.*to //;s/ at time / /;s/ seconds//'" using 2:1 w p pt 1 lc rgb "#FF0000" title "cwnd"
			and convert is the ImageMagick file conversion utility.
	~~(The figures shown here are in PNG format, converted by~~ ImageMagick ~~with density of 150 dpi)~~

	==== No loss ====		==== No loss ====

Adriantam: /* Result from tcp-loss-response */

2010-09-02T21:28:13Z

Result from tcp-loss-response

@@ Line 660: / Line 660: @@
      done
    done
-The figures showing hereinafter is produced using GNU plot with the following command, assuming the program's console output is stored in file console.log:
+The figures showing hereinafter is produced using GNU plot with the following script:
    set key left
    set terminal postscript eps enhanced color
-   set output "figure.eps"
+   set yrange [0:100000]
    plot \
-     "< grep ^r console.log | ./trTidy.pl | grep N0 | perl -ne 's/^..//;s/\t.*Ack=/ /;s/ Win.*$//;split;print $_[0].q{ }.($_[1]%100000).q{\n}'" using 1:2 w p pt 2 lc rgb "#00FF00" title "ack", \
+     "< grep ^r TcpNewReno.0.log | ./trTidy.pl | grep N0 | perl -ne 's/^..//;s/\t.*Ack=/ /;s/ Win.*$//;split;print $_[0].q{ }.($_[1]%100000).q{\n}'" using 1:2 w p pt 2 lc rgb "#00FF00" title "ack", \
-     "< grep cwnd console.log | grep seconds | perl -pe 's/^.*to //;s/ at time / /;s/ seconds//'" using 2:1 w p pt 1 lc rgb "#FF0000" title "cwnd"
+    "< grep cwnd TcpNewReno.0.log | grep seconds | perl -pe 's/^.*to //;s/ at time / /;s/ seconds//'" using 2:1 w p pt 1 lc rgb "#FF0000" title "cwnd"
 ==== No loss ====

Adriantam: /* Result from tcp-testcases */

2010-09-02T21:24:57Z

Result from tcp-testcases

← Older revision		Revision as of 21:24, 2 September 2010
Line 191:		Line 191:
	print;		print;
	};		};

			This script is reused in the tcp-loss-response as well. It is referred as tidy.pl below.

	==== Case 0 ====		==== Case 0 ====

Adriantam: /* Result from tcp-loss-response */

2010-09-02T21:22:28Z

Result from tcp-loss-response

← Older revision		Revision as of 21:22, 2 September 2010
Line 690:		Line 690:

	This shows the case with four consecutive losses. Same as three consecutive losses, Tahoe and Reno recovered by having retransmission timeout. NewReno, however, avoids retransmission timeout by recognising partial ACKs.		This shows the case with four consecutive losses. Same as three consecutive losses, Tahoe and Reno recovered by having retransmission timeout. NewReno, however, avoids retransmission timeout by recognising partial ACKs.

			==== Check points for tcp-loss-response ====
			There are several check points to verify the TCP behaviour using tcp-loss-response:
			* Tahoe recover using go-back-n approach. Recovery of consecutive losses are same as single loss. In the above experiments, it takes 4.8s to 5s to finish the transfer when there are any loss
			* Reno does not use the go-back-n approach. And upon the finish of fast recovery phase (i.e. when partial or full ACK is received), window deflating can be observed. In cases that does not incur RTO, the time it takes to finish the transfer is around 0.5s shorter than the Tahoe counter part in the above experiments. However, when there is RTO, it takes a longer time than Tahoe.
			* NewReno is similar to Reno. Window deflating is observed only when full ACK is received, hence only once in each lossy experiment above. It finish all cases in the shortest time amongst the three TCP variants.

Adriantam: /* Four losses */

2010-09-02T21:05:17Z

Four losses

← Older revision		Revision as of 21:05, 2 September 2010
Line 689:		Line 689:
	[[File:tcptahoe.4.png\|300px\|Tahoe with 4 losses]] [[File:tcpreno.4.png\|300px\|Reno with 4 loss]] [[File:tcpnewreno.4.png\|300px\|NewReno with 4 losses]]		[[File:tcptahoe.4.png\|300px\|Tahoe with 4 losses]] [[File:tcpreno.4.png\|300px\|Reno with 4 loss]] [[File:tcpnewreno.4.png\|300px\|NewReno with 4 losses]]

	This shows the case with four consecutive losses. Same as three consecutive ~~loss~~, Tahoe and Reno recovered ~~from the loss~~ by having retransmission timeout. NewReno, however, avoids retransmission timeout by recognising partial ACKs.		This shows the case with four consecutive losses. Same as three consecutive losses, Tahoe and Reno recovered by having retransmission timeout. NewReno, however, avoids retransmission timeout by recognising partial ACKs.

Adriantam: /* Two losses */

2010-09-02T20:53:21Z

Two losses

← Older revision		Revision as of 20:53, 2 September 2010
Line 679:		Line 679:
	[[File:tcptahoe.2.png\|300px\|Tahoe with 2 losses]] [[File:tcpreno.2.png\|300px\|Reno with 2 loss]] [[File:tcpnewreno.2.png\|300px\|NewReno with 2 losses]]		[[File:tcptahoe.2.png\|300px\|Tahoe with 2 losses]] [[File:tcpreno.2.png\|300px\|Reno with 2 loss]] [[File:tcpnewreno.2.png\|300px\|NewReno with 2 losses]]

	This shows the case with two consecutive packet losses. The duplicated acknowledgement arrives at around 1.~~27s~~. In Tahoe, retransmission is restarted from the loss packet, therefore, the consecutive losses behaves similar to single loss. Its cwnd is reset to 1 MSS at around 1.~~27s~~. In Reno, only the packet assumed ~~loss~~ is retransmitted. Therefore, the second loss creates another triple dupack and the cwnd is reduced again. At around 1.~~27s~~, the cwnd is reduced for the first time from ~~13000~~ bytes to ~~9500~~ bytes. Due to subsequent ACK, it raised to ~~17557~~ at around 1.~~56s~~, ~~by then~~ the second dupack ~~occured to cut~~ the cwnd to ~~11500~~ bytes. The full ACK received at around 1.~~77s~~ resets the cwnd to ~~8500~~ bytes. In NewReno, however, partial ACK is recognised. ~~The~~ second ~~dupack case does not reduce~~ the cwnd as the TCP is ~~now~~ in ~~fast recovery mode~~.		This shows the case with two consecutive packet losses. The duplicated acknowledgement arrives at around 1.29s. In Tahoe, retransmission is restarted (go-back-n) from the loss packet, therefore, the consecutive losses behaves similar to single loss. Its cwnd is reset to 1 MSS at around 1.29s. In Reno, only the packet assumed lost is retransmitted. Therefore, the second loss creates another triple dupack and the cwnd is reduced again. At around 1.29s, the cwnd is reduced for the first time from 15000 bytes to 10500 bytes (=15000/2+31000). Due to subsequent ACK, it raised to 20500 at around 1.40s. Then, a new ACK (partial ACK) reset cwnd to 7500 at 1.50s and the second dupack occurred at 1.59s reset the cwnd again to 12500 bytes (flight size 19000/2+31000). The full ACK received at around 1.80s resets the cwnd to 9500 bytes and proceed in congestion avoidance phase thereafter. In NewReno, however, partial ACK is recognised. At around 1.50s, when the partial ACK is received, the cwnd keep increasing (raised from 20500 to 21500) while the second lost packet (sequence number 15001) is retransmitted. At 1.74s, the full ACK is received which ends the fast recovery procedure and reset cwnd to 7500 bytes (=15000/2). Subsequently, the NewReno TCP is in congestion avoidance phase and cwnd increases in a gentle slope.

	==== Three losses ====		==== Three losses ====