Ex No 3
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Ex No 3 as PDF for free.
More details
- Words: 2,280
- Pages: 11
Ex no: Date: Simulation of TCP using NS-2 Aim: To simulate a network consisting of TCP (Tahoe, Reno and new Reno) and to find the congestion window size. Description: Flow control Algorithm: In a connection between a client and a server, the client tells the server the number of bytes it is willing to receive at one time from the server; this is the client's receive window, which becomes the server's send window. Likewise, the server tells the client how many bytes of data it is willing to take from the client at one time; this is the server's receive window and the client's send window. Since the window size can be used in this manner to manage the rate at which data flows between the devices at the ends of the connection, it is the method by which TCP implements flow control, one of the “classical” jobs of the transport layer. Flow control is vitally important to TCP, as it is the method by which devices communicate their status to each other. By reducing or increasing window size, the server and client each ensure that the other device sends data just as fast as the recipient can deal with it. Flow control is a technique whose primary purpose is to properly match the transmission rate of sender to that of the receiver and the network. It is important for the transmission to be at a high enough rate to ensure good performance, but also to protect against overwhelming the network or receiving host. Congestion control is primarily concerned with a sustained overload of network intermediate devices such as IP routers. TCP uses the window field, briefly described previously, as the primary means for flow control. During the data transfer phase, the window field is used to adjust the rate of flow of the byte stream between communicating TCPs.
In this simple example, there is a 4-byte sliding window. Moving from left to right, the window "slides" as bytes in the stream are sent and acknowledged.7 The size of the window and how fast to increase or decrease the window size is an area of great research. Congestion Control TCP congestion control and Internet traffic management issues in general is an active area of research and experimentation. This final section is a very brief summary of the standard congestion control algorithms widely used in TCP implementations today. Slow Start Slow Start, a requirement for TCP software implementations is a mechanism used by the sender to control the transmission rate, otherwise known as sender-based flow control. This is accomplished through the return rate of acknowledgements from the receiver. In other words, the rate of acknowledgements returned by the receiver determine the rate at which the sender can transmit data. When a TCP connection first begins, the Slow Start algorithm initializes a congestion window to one segment, which is the maximum segment size (MSS) initialized by the receiver during the connection establishment phase. When acknowledgements are returned by the receiver, the congestion window increases by one segment for each acknowledgement returned. Thus, the sender can transmit the minimum of the congestion window and the advertised window of the receiver, which is simply called the transmission window. Slow Start is actually not very slow when the network is not congested and network response time is good. For example, the first successful transmission and acknowledgement of a TCP segment increases the window to two segments. After successful transmission of these two segments and acknowledgements completes, the window is increased to four segments. Then eight segments, then sixteen segments and so on, doubling from there on out up to the maximum window size advertised by the receiver or until congestion finally does occur.
Congestion Avoidance During the initial data transfer phase of a TCP connection the Slow Start algorithm is used. However, there may be a point during Slow Start that the network is forced to drop one or more packets due to overload or congestion. If this happens, Congestion Avoidance is used to slow the transmission rate. However, Slow Start is used in conjunction with Congestion Avoidance as the means to get the data transfer going again so it doesn't slow down and stay slow. In the Congestion Avoidance algorithm a retransmission timer expiring or the reception of duplicate ACKs can implicitly signal the sender that a network congestion situation is occurring. The sender immediately sets its transmission window to one half of the current window size (the minimum of the congestion window and the receiver's advertised window size), but to at least two segments. If congestion was indicated by a timeout, the congestion window is reset to one segment, which automatically puts the sender into Slow Start mode. As data is received during Congestion Avoidance, the congestion window is increased. However, Slow Start is only used up to the halfway point where congestion originally occurred. This halfway point was recorded earlier as the new transmission window. After this halfway point, the congestion window is increased by one segment for all segments in the transmission window that are acknowledged. This mechanism will force the sender to more slowly grow its transmission rate, as it will approach the point where congestion had previously been detected. Fast Retransmit When a duplicate ACK is received, the sender does not know if it is because a TCP segment was lost or simply that a segment was delayed and received out of order at the receiver. If the receiver can re-order segments, it should not be long before the receiver sends the latest expected acknowledgement. Typically no more than one or two duplicate ACKs should be received when simple out of order conditions exist. If however more than two duplicate ACKs are received by the sender, it is a strong indication that at least one segment has been lost. The TCP sender will assume enough time has lapsed for
all segments to be properly re-ordered by the fact that the receiver had enough time to send three duplicate ACKs. When three or more duplicate ACKs are received, the sender does not even wait for a retransmission timer to expire before retransmitting the segment (as indicated by the position of the duplicate ACK in the byte stream). This process is called the Fast Retransmit algorithm Immediately following Fast Retransmit is the Fast Recovery algorithm. Fast Recovery Since the Fast Retransmit algorithm is used when duplicate ACKs are being received, the TCP sender has implicit knowledge that there is data still flowing to the receiver. Why? The reason is because duplicate ACKs can only be generated when a segment is received. This is a strong indication that serious network congestion may not exist and that the lost segment was a rare event. So instead of reducing the flow of data abruptly by going all the way into Slow Start, the sender only enters Congestion Avoidance mode.Rather than start at a window of one segment as in Slow Start mode, the sender resumes transmission with a larger window, incrementing as if in Congestion Avoidance mode. TCP Agents: The TCP agent does not generate any application data on its own. Instead, the simulation user can connect any trafc generation module to the TCP agent to generate data. Two applications are commonly used for TCP: FTP and Telnet. The various types of TCP are: • Reno TCP: The Reno TCP agent is very similar to the Tahoe TCP agent, except it also includes fast recovery, where the current congestion window is .inflated. by the number of duplicate ACKs the TCP sender has received before receiving a new ACK. The Reno TCP agent does not return to slow-start during a fast retransmit. Rather, it reduces sets the congestion window to half the current window and resets ssthresh_ to match this value.
• Newreno TCP This agent is based on the Reno TCP agent, but which modifies the action taken when receiving new ACKS. In order to exit fast recovery, the sender must receive an ACK for the highest sequence number sent. Thus, new partial ACKs. (those which represent new ACKs but do not represent an ACK for all outstanding data) do not deflate the window (and possibly lead to a stall, characteristic of Reno). • Vegas TCP This agent implements “Vegas” TCP. It was contributed by Ted Kuo. The one-way TCP sending agents currently supported are: • Agent/TCP - a “tahoe” TCP sender • Agent/TCP/Reno - a “Reno” TCP sender • Agent/TCP/Newreno - Reno with a modication • Agent/TCP/Sack1 - TCP with selective repeat (follows RFC2018) • Agent/TCP/Vegas - TCP Vegas • Agent/TCP/Fack - Reno TCP with .forward acknowledgment. The one-way TCP receiving agents currently supported are: • Agent/TCPSink - TCP sink with one ACK per packet • Agent/TCPSink/DelAck - TCP sink with congurable delay per ACK • Agent/TCPSink/Sack1 - selective ACK sink (follows RFC2018) • Agent/TCPSink/Sack1/DelAck - Sack1 with DelAck The two-way experimental sender currently supports only a Reno form of TCP: • Agent/TCP/FullTcp • Note: Still under development Procedure: •
create the simulator object
•
create the nodes and link the nodes together
•
setup the application and Transport agent
•
Connect the Transport agent of the sender with the Application agent
•
Connect the Agents to the node, Similarly connect the Transport agent of the receiver with the Receiver node
•
Connect the Sender and the Receiver Agents
•
schedule the start of the simulation
•
schedule the end of the simulation
•
run
Program: Case (I) Two Flows Start at 10.0 sec and Stops at 210.sec: Tahoe TCP: #Simulation of TCPset ns [new Simulator] set f0 [open tahoe0.tr w]set f1 [open tahoe1.tr w]set f2 [open tahoe2.tr w]set nr [open taho.tr w]$ns trace-all $nr set nf [open taho.nam w]$ns namtrace-all $nf proc finish { } { global ns f0 f1 nr nf f2 $ns flush-trace close $f0 close $f1 close $f2 close $nf exec nam taho.nam & exec xgraph tahoe0.tr tahoe1.tr tahoe2.tr -geometry 800 400 & exit 0 }set n0 [$ns node]set n1 [$ns node]set n2 [$ns node]set n3 [$ns node]set n4 [$ns node]set n5 [$ns node]set n6 [$ns node]set n7 [$ns node]#Creation of Links:$ns duplex-link $n0 $n2 1Mb 10ms DropTail$ns duplex-link $n1 $n2 1Mb 10ms DropTail$ns duplex-link $n2 $n3 3Mb 10ms DropTail$ns duplex-link $n3 $n4 2Mb 10ms DropTail$ns duplex-link $n3 $n5 2Mb 10ms DropTail$ns duplex-link $n6 $n2 1Mb 10ms DropTail$ns duplex-link $n3 $n7 2Mb 10ms DropTail #Orientation of nodes:$ns duplex-link-op $n0 $n2 orient right-up$ns duplex-link-op $n2 $n3 orient middle$ns duplex-link-op $n1 $n2 orient right-down$ns duplex-link-op $n3 $n4 orient right-up$ns duplex-link-op $n3 $n5 orient right-down$ns duplex-link-op $n2 $n6 orient left$ns duplex-link-op $n3 $n7 orient right#Connection of node1 with node5set tcp0 [new Agent/TCP]$ns attach-agent $n1 $tcp0set ftp0 [new Application/FTP]$ftp0 set packetSize_ 500$ftp0 set interval_ 0.005$ftp0 attach-agent $tcp0set sink0 [new Agent/TCPSink]$ns attach-agent $n4 $sink0$ns connect $tcp0 $sink0 #Connection of node1 with node4set tcp1 [new Agent/TCP]$ns attach-agent $n0 $tcp1set ftp [new Application/FTP]$ftp set packetSize_ 500$ftp set interval_ 0.005$ftp attachagent $tcp1set sink [new Agent/TCPSink]$ns attach-agent $n5 $sink$ns connect $tcp1 $sink set tcp2 [new Agent/TCP]$ns attach-agent $n6 $tcp2set ftp2 [new Application/FTP]$ftp2 set packetSize_ 500$ftp2 set interval_ 0.005$ftp2 attach-agent $tcp2set sink2 [new Agent/TCPSink]$ns attach-agent $n7 $sink2$ns connect $tcp2 $sink2 #Setting color for the nodes$tcp0 set fid_ 1$tcp1 set fid_ 2$tcp2 set fid_ 3proc record {} { global tcp0 tcp1 tcp2 f0 f1 f2 set ns [Simulator instance] set time 0.01 set wnd0 [$tcp0 set cwnd_] set wnd1 [$tcp1 set cwnd_] set wnd2 [$tcp2 set cwnd_] set now [$ns now] puts $f0 "$now $wnd0" puts $f1 "$now $wnd1" puts $f2 "$now $wnd2" $tcp0 set bytes_ 0 $tcp1 set bytes_ 0 $tcp2 set bytes_ 0 $ns at [expr $now+$time] "record"}$ns color 1 Red$ns color 2 Green$ns color 3 Brown#Schedule events for the CBR and FTP agents$ns at 0.1 "record"$ns at 0.5 "$ftp0 start"$ns at 1.4 "$ftp start"$ns at 1.9 "$ftp2 start"$ns at 4.1 "$ftp stop"$ns at 4.4 "$ftp2 stop"$ns at 3.5 "$ftp0 stop"$ns at 5.0 "finish"$ns run
Reno Tcp: #Connection of node1 with node5set tcp0 [new Agent/TCP/Reno]$ns attach-agent $n1 $tcp0set ftp0 [new Application/FTP]$ftp0 set packetSize_ 500$ftp0 set interval_ 0.005$ftp0 attach-agent $tcp0set sink0 [new Agent/TCPSink]$ns attach-agent $n4 $sink0$ns connect $tcp0 $sink0 #Connection of node1 with node4set tcp1 [new Agent/TCP/Reno]$ns attach-agent $n0 $tcp1set ftp [new Application/FTP]$ftp set packetSize_ 500$ftp set interval_ 0.005$ftp attach-agent $tcp1set sink [new Agent/TCPSink]$ns attach-agent $n5 $sink$ns connect $tcp1 $sink set tcp2 [new Agent/TCP/Reno]$ns attach-agent $n6 $tcp2set ftp1 [new Application/FTP]$ftp1 set packetSize_ 500$ftp1 set interval_ 0.005$ftp1 attach-agent $tcp2set sink1 [new Agent/TCPSink]$ns attach-agent $n7 $sink1$ns connect $tcp2 $sink1 New Reno TCP: #Connection of node1 with node5set tcp0 [new Agent/TCP/Newreno]$ns attach-agent $n1 $tcp0set ftp0 [new Application/FTP]$ftp0 set packetSize_ 500$ftp0 set interval_ 0.005$ftp0 attach-agent $tcp0set sink0 [new Agent/TCPSink]$ns attach-agent $n4 $sink0$ns connect $tcp0 $sink0 #Connection of node1 with node4set tcp1 [new Agent/TCP/Newreno]$ns attach-agent $n0 $tcp1set ftp [new Application/FTP]$ftp set packetSize_ 500$ftp set interval_ 0.005$ftp attach-agent $tcp1set sink [new Agent/TCPSink]$ns attach-agent $n5 $sink$ns connect $tcp1 $sink set tcp2 [new Agent/TCP/Newreno]$ns attach-agent $n6 $tcp2set ftp1 [new Application/FTP]$ftp1 set packetSize_ 500$ftp1 set interval_ 0.005$ftp1 attach-agent $tcp2set sink1 [new Agent/TCPSink]$ns attach-agent $n7 $sink1$ns connect $tcp2 $sink1 Vegas TCP: #Connection of node1 with node5set tcp0 [new Agent/TCP/Vegas]$ns attach-agent $n1 $tcp0set ftp0 [new Application/FTP]$ftp0 set packetSize_ 500$ftp0 set interval_ 0.005$ftp0 attach-agent $tcp0set sink0 [new Agent/TCPSink]$ns attach-agent $n4 $sink0$ns connect $tcp0 $sink0 #Connection of node1 with node4set tcp1 [new Agent/TCP/Vegas]$ns attach-agent $n0 $tcp1set ftp [new Application/FTP]$ftp set packetSize_ 500$ftp set interval_ 0.005$ftp attach-agent $tcp1set sink [new Agent/TCPSink]$ns attach-agent $n5 $sink$ns connect $tcp1 $sink set tcp2 [new Agent/TCP/Vegas]$ns attach-agent $n6 $tcp2set ftp1 [new Application/FTP]$ftp1 set packetSize_ 500$ftp1 set interval_ 0.005$ftp1 attach-agent $tcp2set sink1 [new Agent/TCPSink]$ns attach-agent $n7 $sink1$ns connect $tcp2 $sink1
Output: Simulation Output:
X graph: Tahoe TCP:
Reno TCP:
New Reno TCP:
Vegas TCP:
Result: Thus the program for simulating a TCP was written and the output was Verified.
In this simple example, there is a 4-byte sliding window. Moving from left to right, the window "slides" as bytes in the stream are sent and acknowledged.7 The size of the window and how fast to increase or decrease the window size is an area of great research. Congestion Control TCP congestion control and Internet traffic management issues in general is an active area of research and experimentation. This final section is a very brief summary of the standard congestion control algorithms widely used in TCP implementations today. Slow Start Slow Start, a requirement for TCP software implementations is a mechanism used by the sender to control the transmission rate, otherwise known as sender-based flow control. This is accomplished through the return rate of acknowledgements from the receiver. In other words, the rate of acknowledgements returned by the receiver determine the rate at which the sender can transmit data. When a TCP connection first begins, the Slow Start algorithm initializes a congestion window to one segment, which is the maximum segment size (MSS) initialized by the receiver during the connection establishment phase. When acknowledgements are returned by the receiver, the congestion window increases by one segment for each acknowledgement returned. Thus, the sender can transmit the minimum of the congestion window and the advertised window of the receiver, which is simply called the transmission window. Slow Start is actually not very slow when the network is not congested and network response time is good. For example, the first successful transmission and acknowledgement of a TCP segment increases the window to two segments. After successful transmission of these two segments and acknowledgements completes, the window is increased to four segments. Then eight segments, then sixteen segments and so on, doubling from there on out up to the maximum window size advertised by the receiver or until congestion finally does occur.
Congestion Avoidance During the initial data transfer phase of a TCP connection the Slow Start algorithm is used. However, there may be a point during Slow Start that the network is forced to drop one or more packets due to overload or congestion. If this happens, Congestion Avoidance is used to slow the transmission rate. However, Slow Start is used in conjunction with Congestion Avoidance as the means to get the data transfer going again so it doesn't slow down and stay slow. In the Congestion Avoidance algorithm a retransmission timer expiring or the reception of duplicate ACKs can implicitly signal the sender that a network congestion situation is occurring. The sender immediately sets its transmission window to one half of the current window size (the minimum of the congestion window and the receiver's advertised window size), but to at least two segments. If congestion was indicated by a timeout, the congestion window is reset to one segment, which automatically puts the sender into Slow Start mode. As data is received during Congestion Avoidance, the congestion window is increased. However, Slow Start is only used up to the halfway point where congestion originally occurred. This halfway point was recorded earlier as the new transmission window. After this halfway point, the congestion window is increased by one segment for all segments in the transmission window that are acknowledged. This mechanism will force the sender to more slowly grow its transmission rate, as it will approach the point where congestion had previously been detected. Fast Retransmit When a duplicate ACK is received, the sender does not know if it is because a TCP segment was lost or simply that a segment was delayed and received out of order at the receiver. If the receiver can re-order segments, it should not be long before the receiver sends the latest expected acknowledgement. Typically no more than one or two duplicate ACKs should be received when simple out of order conditions exist. If however more than two duplicate ACKs are received by the sender, it is a strong indication that at least one segment has been lost. The TCP sender will assume enough time has lapsed for
all segments to be properly re-ordered by the fact that the receiver had enough time to send three duplicate ACKs. When three or more duplicate ACKs are received, the sender does not even wait for a retransmission timer to expire before retransmitting the segment (as indicated by the position of the duplicate ACK in the byte stream). This process is called the Fast Retransmit algorithm Immediately following Fast Retransmit is the Fast Recovery algorithm. Fast Recovery Since the Fast Retransmit algorithm is used when duplicate ACKs are being received, the TCP sender has implicit knowledge that there is data still flowing to the receiver. Why? The reason is because duplicate ACKs can only be generated when a segment is received. This is a strong indication that serious network congestion may not exist and that the lost segment was a rare event. So instead of reducing the flow of data abruptly by going all the way into Slow Start, the sender only enters Congestion Avoidance mode.Rather than start at a window of one segment as in Slow Start mode, the sender resumes transmission with a larger window, incrementing as if in Congestion Avoidance mode. TCP Agents: The TCP agent does not generate any application data on its own. Instead, the simulation user can connect any trafc generation module to the TCP agent to generate data. Two applications are commonly used for TCP: FTP and Telnet. The various types of TCP are: • Reno TCP: The Reno TCP agent is very similar to the Tahoe TCP agent, except it also includes fast recovery, where the current congestion window is .inflated. by the number of duplicate ACKs the TCP sender has received before receiving a new ACK. The Reno TCP agent does not return to slow-start during a fast retransmit. Rather, it reduces sets the congestion window to half the current window and resets ssthresh_ to match this value.
• Newreno TCP This agent is based on the Reno TCP agent, but which modifies the action taken when receiving new ACKS. In order to exit fast recovery, the sender must receive an ACK for the highest sequence number sent. Thus, new partial ACKs. (those which represent new ACKs but do not represent an ACK for all outstanding data) do not deflate the window (and possibly lead to a stall, characteristic of Reno). • Vegas TCP This agent implements “Vegas” TCP. It was contributed by Ted Kuo. The one-way TCP sending agents currently supported are: • Agent/TCP - a “tahoe” TCP sender • Agent/TCP/Reno - a “Reno” TCP sender • Agent/TCP/Newreno - Reno with a modication • Agent/TCP/Sack1 - TCP with selective repeat (follows RFC2018) • Agent/TCP/Vegas - TCP Vegas • Agent/TCP/Fack - Reno TCP with .forward acknowledgment. The one-way TCP receiving agents currently supported are: • Agent/TCPSink - TCP sink with one ACK per packet • Agent/TCPSink/DelAck - TCP sink with congurable delay per ACK • Agent/TCPSink/Sack1 - selective ACK sink (follows RFC2018) • Agent/TCPSink/Sack1/DelAck - Sack1 with DelAck The two-way experimental sender currently supports only a Reno form of TCP: • Agent/TCP/FullTcp • Note: Still under development Procedure: •
create the simulator object
•
create the nodes and link the nodes together
•
setup the application and Transport agent
•
Connect the Transport agent of the sender with the Application agent
•
Connect the Agents to the node, Similarly connect the Transport agent of the receiver with the Receiver node
•
Connect the Sender and the Receiver Agents
•
schedule the start of the simulation
•
schedule the end of the simulation
•
run
Program: Case (I) Two Flows Start at 10.0 sec and Stops at 210.sec: Tahoe TCP: #Simulation of TCPset ns [new Simulator] set f0 [open tahoe0.tr w]set f1 [open tahoe1.tr w]set f2 [open tahoe2.tr w]set nr [open taho.tr w]$ns trace-all $nr set nf [open taho.nam w]$ns namtrace-all $nf proc finish { } { global ns f0 f1 nr nf f2 $ns flush-trace close $f0 close $f1 close $f2 close $nf exec nam taho.nam & exec xgraph tahoe0.tr tahoe1.tr tahoe2.tr -geometry 800 400 & exit 0 }set n0 [$ns node]set n1 [$ns node]set n2 [$ns node]set n3 [$ns node]set n4 [$ns node]set n5 [$ns node]set n6 [$ns node]set n7 [$ns node]#Creation of Links:$ns duplex-link $n0 $n2 1Mb 10ms DropTail$ns duplex-link $n1 $n2 1Mb 10ms DropTail$ns duplex-link $n2 $n3 3Mb 10ms DropTail$ns duplex-link $n3 $n4 2Mb 10ms DropTail$ns duplex-link $n3 $n5 2Mb 10ms DropTail$ns duplex-link $n6 $n2 1Mb 10ms DropTail$ns duplex-link $n3 $n7 2Mb 10ms DropTail #Orientation of nodes:$ns duplex-link-op $n0 $n2 orient right-up$ns duplex-link-op $n2 $n3 orient middle$ns duplex-link-op $n1 $n2 orient right-down$ns duplex-link-op $n3 $n4 orient right-up$ns duplex-link-op $n3 $n5 orient right-down$ns duplex-link-op $n2 $n6 orient left$ns duplex-link-op $n3 $n7 orient right#Connection of node1 with node5set tcp0 [new Agent/TCP]$ns attach-agent $n1 $tcp0set ftp0 [new Application/FTP]$ftp0 set packetSize_ 500$ftp0 set interval_ 0.005$ftp0 attach-agent $tcp0set sink0 [new Agent/TCPSink]$ns attach-agent $n4 $sink0$ns connect $tcp0 $sink0 #Connection of node1 with node4set tcp1 [new Agent/TCP]$ns attach-agent $n0 $tcp1set ftp [new Application/FTP]$ftp set packetSize_ 500$ftp set interval_ 0.005$ftp attachagent $tcp1set sink [new Agent/TCPSink]$ns attach-agent $n5 $sink$ns connect $tcp1 $sink set tcp2 [new Agent/TCP]$ns attach-agent $n6 $tcp2set ftp2 [new Application/FTP]$ftp2 set packetSize_ 500$ftp2 set interval_ 0.005$ftp2 attach-agent $tcp2set sink2 [new Agent/TCPSink]$ns attach-agent $n7 $sink2$ns connect $tcp2 $sink2 #Setting color for the nodes$tcp0 set fid_ 1$tcp1 set fid_ 2$tcp2 set fid_ 3proc record {} { global tcp0 tcp1 tcp2 f0 f1 f2 set ns [Simulator instance] set time 0.01 set wnd0 [$tcp0 set cwnd_] set wnd1 [$tcp1 set cwnd_] set wnd2 [$tcp2 set cwnd_] set now [$ns now] puts $f0 "$now $wnd0" puts $f1 "$now $wnd1" puts $f2 "$now $wnd2" $tcp0 set bytes_ 0 $tcp1 set bytes_ 0 $tcp2 set bytes_ 0 $ns at [expr $now+$time] "record"}$ns color 1 Red$ns color 2 Green$ns color 3 Brown#Schedule events for the CBR and FTP agents$ns at 0.1 "record"$ns at 0.5 "$ftp0 start"$ns at 1.4 "$ftp start"$ns at 1.9 "$ftp2 start"$ns at 4.1 "$ftp stop"$ns at 4.4 "$ftp2 stop"$ns at 3.5 "$ftp0 stop"$ns at 5.0 "finish"$ns run
Reno Tcp: #Connection of node1 with node5set tcp0 [new Agent/TCP/Reno]$ns attach-agent $n1 $tcp0set ftp0 [new Application/FTP]$ftp0 set packetSize_ 500$ftp0 set interval_ 0.005$ftp0 attach-agent $tcp0set sink0 [new Agent/TCPSink]$ns attach-agent $n4 $sink0$ns connect $tcp0 $sink0 #Connection of node1 with node4set tcp1 [new Agent/TCP/Reno]$ns attach-agent $n0 $tcp1set ftp [new Application/FTP]$ftp set packetSize_ 500$ftp set interval_ 0.005$ftp attach-agent $tcp1set sink [new Agent/TCPSink]$ns attach-agent $n5 $sink$ns connect $tcp1 $sink set tcp2 [new Agent/TCP/Reno]$ns attach-agent $n6 $tcp2set ftp1 [new Application/FTP]$ftp1 set packetSize_ 500$ftp1 set interval_ 0.005$ftp1 attach-agent $tcp2set sink1 [new Agent/TCPSink]$ns attach-agent $n7 $sink1$ns connect $tcp2 $sink1 New Reno TCP: #Connection of node1 with node5set tcp0 [new Agent/TCP/Newreno]$ns attach-agent $n1 $tcp0set ftp0 [new Application/FTP]$ftp0 set packetSize_ 500$ftp0 set interval_ 0.005$ftp0 attach-agent $tcp0set sink0 [new Agent/TCPSink]$ns attach-agent $n4 $sink0$ns connect $tcp0 $sink0 #Connection of node1 with node4set tcp1 [new Agent/TCP/Newreno]$ns attach-agent $n0 $tcp1set ftp [new Application/FTP]$ftp set packetSize_ 500$ftp set interval_ 0.005$ftp attach-agent $tcp1set sink [new Agent/TCPSink]$ns attach-agent $n5 $sink$ns connect $tcp1 $sink set tcp2 [new Agent/TCP/Newreno]$ns attach-agent $n6 $tcp2set ftp1 [new Application/FTP]$ftp1 set packetSize_ 500$ftp1 set interval_ 0.005$ftp1 attach-agent $tcp2set sink1 [new Agent/TCPSink]$ns attach-agent $n7 $sink1$ns connect $tcp2 $sink1 Vegas TCP: #Connection of node1 with node5set tcp0 [new Agent/TCP/Vegas]$ns attach-agent $n1 $tcp0set ftp0 [new Application/FTP]$ftp0 set packetSize_ 500$ftp0 set interval_ 0.005$ftp0 attach-agent $tcp0set sink0 [new Agent/TCPSink]$ns attach-agent $n4 $sink0$ns connect $tcp0 $sink0 #Connection of node1 with node4set tcp1 [new Agent/TCP/Vegas]$ns attach-agent $n0 $tcp1set ftp [new Application/FTP]$ftp set packetSize_ 500$ftp set interval_ 0.005$ftp attach-agent $tcp1set sink [new Agent/TCPSink]$ns attach-agent $n5 $sink$ns connect $tcp1 $sink set tcp2 [new Agent/TCP/Vegas]$ns attach-agent $n6 $tcp2set ftp1 [new Application/FTP]$ftp1 set packetSize_ 500$ftp1 set interval_ 0.005$ftp1 attach-agent $tcp2set sink1 [new Agent/TCPSink]$ns attach-agent $n7 $sink1$ns connect $tcp2 $sink1
Output: Simulation Output:
X graph: Tahoe TCP:
Reno TCP:
New Reno TCP:
Vegas TCP:
Result: Thus the program for simulating a TCP was written and the output was Verified.
