NS2 Agents Leo Bhebhe

Contents Introduction Application Composition Attaching Transport Agents to Nodes UDP Agent TCP Agents SCTP Agents Agent SRM

Introduction In real-world systems, applications typically access network services through an applications programming interface (API). The most popular of these APIs is known as sockets. In ns, we mimic the behavior of the sockets API through a set of well- defined API functions. These functions are then mapped to the appropriate internal agent functions (e.g., a call to send(numBytes) causes TCP to increment its send buffer by a corresponding number of bytes) Applications sit on top of transport agents in ns. Running Running, e.g. an TCP simulation requires creating and configuring the agent, attaching an application-level data source (a traffic generator), and starting the agent and the traffic generator. There are two basic types of applications: Traffic generators and Simulated applications.

Example of Application Composition Traffic generators Simulated applications Agent/UDP Agent/TCP/FullTcp Application/ Traffic/ Exponential Application/FTP The diagram illustrates how agents and applications are hooked together and communicate with one another via the API API

Attaching Transport Agents to Nodes set src [new Agent/TCP/FullTcp] set sink [new Agent/TCP/FullTcp] $ns_ attach-agent $node_(s1) $src $ns_ attach-agent $node_(k1) $sink $ns_ connect $src $sink set udp0 [new Agent/UDP] $ns attach-agent $n0 $udp0 set cbr0 [new Application/Traffic/CBR] $cbr0 attach-agent $udp0 $udp0 set packetSize_ 536 ; #(max=1000) set null0 [new Agent/Null] $ns attach-agent $n1 $null0 $ns connect $udp0 $null0

UDP Agent A UDP agent accepts data in variable size chunks from an application, and segments the data if needed. UDP packets also contain a monotonically increasing sequence number and an RTP timestamp. The default maximum segment size (MSS) for UDP agents is 1000 byte: Agent/UDP set packetSize_ 1000 ;# max segment size set ns [new Simulator] set n0 [$ns node] set n1 [$ns node] $ns duplex-link $n0 $n1 5Mb 2ms DropTail set udp0 [new Agent/UDP] $ns attach-agent $n0 $udp0 set cbr0 [new Application/Traffic/CBR] $cbr0 attach-agent $udp0 $udp0 set packetSize_ 536 ;# set MSS to 536 bytes set null0 [new Agent/Null] $ns attach-agent $n1 $null0 $ns connect $udp0 $null0 $ns at 1.0 "$cbr0 start" Create src, dest. nodes & a link Create agents & starting traffic generator

TCP Agents (1/2) 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.

TCP Agents (2/2) 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

One Way TCP Senders (1/3) What can they do Attempt to capture the the essence of TCP congestion and error control behaviours Segment number and ACK computations entirely in the packet units What they can’t do Can’t mimic the real-world TCP implementations They do not have a dynamic window advertisement There’s no SYN/FIN connection establishement/teardown No data is ever transferred (e.g. no checksums or urgent data)

One Way TCP Senders (2/3) The Base TCP Sender (Tahoe TCP) Performs congestion control Round-trip-time estimation RTO Timeout Selection Creating the Agent set ns [new Simulator] ;# preamble initialization set node1 [$ns node] ;# agent to reside on this node set node2 [$ns node] ;# agent to reside on this node set tcp1 [$ns create-connection TCP $node1 TCPSink $node2 42] $tcp set window_ 50 ;# configure the TCP agent set ftp1 [new Application/FTP] $ftp1 attach-agent $tcp1 $ns at 0.0 "$ftp start“

One Way TCP Senders (3/3) 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. Sack TCP This agent implements selective repeat, based on selective ACKs provided by the receiver. It follows the ACK scheme developed with Matt Mathis and Jamshid Mahdavi. Fack TCP This agent implements “forward ACK” TCP, a modication of Sack TCP

One Way TCP Receiver (Sinks) The base TCP sink object (Agent/TCPSink ) is responsible for returning ACKs to a peer TCP source object. It generates one ACK per packet received. The size of the ACKs may be configured. The creation and configuration of the TCP sink object is generally performed automatically when creating a connection. Configuration parameters Base TCP Sink Agent/TCPSink set packetSize_ 40 Delayed-ACK TCP Sink Agent/TCPSink/Delack set interval_ 100ms SACK TCP Sink Agent/TCPSink set maxSacksBlocks_ 3

Two Way TCP Senders (1/2) The Agent/TCP/FullTcp Connections may be establised and town down (SYN/FIN packets are exchanged) Bidirectional data transfer is supported Sequence numbers are in bytes rather than packets Creating the Agent set src [new Agent/TCP/FullTcp] ;# create agent set sink [new Agent/TCP/FullTcp] ;# create agent $ns_ attach-agent $node_(s1) $src ;# bind src to node $ns_ attach-agent $node_(k1) $sink ;# bind sink to node $src set fid_ 0 ;# set flow ID field $sink set fid_ 0 ;# set flow ID field $ns_ connect $src $sink ;# active connection src to sink # set up TCP-level connections $sink listen ;# will figure out who its peer is $src set window_ 100; The creation of the FullTcp agent is similar to the other agents, but the sink is placed in a listening state by the listen method.

Two Way TCP Senders (2/2) The Agent/TCP/BayFullTcp: Different implementation of two-way TCP has been ported into ns from Kathy Nicholes/Van Jacobson's group. It is called The basic difference between BayFullTcp and FullTcp (the two-way tcp version already present in ns) are as follows: BayTcp supports a client-server application model while FullTcp makes no assumption about its application layer. The tcp-application interface is different for both; FullTcp supports partial ack (BayTcp doesn't). FullTcp supports different flavors of tcp (tahoe, reno etc) which is not the case for baytcp. Both implementations have different set of API's. There might be other finer differences between the two as well. One of our future plans is to redefine the APIs to allow fulltcp to use baytcp's client- server model.

SCTP Agents SCTP agents were developed for ns by the Protocol Engineering Lab at the University of Delaware. The SCTP agents are all two-way agents, which means they are symmetric in the sense that they represent both a sender and receiver. However, bi-directional data has not yet been implemented. Each instance of an SCTP agent is either a sender or receiver The SCTP agents currently supported are: Agent/SCTP - RFC2960 Agent/SCTP/Newreno - includes Fast Recovery Agent/SCTP/HbAfterRto - experimental extension (HEARTBEAT after RTO) Agent/SCTP/MultipleFastRtx - experimental extension (UD PEL's Multiple Fast Retransmit algorithm) Agent/SCTP/Timestamp - experimental extension (TIMESTAMP chunk) The SCTP agents are implemented in les matching the regular expression ~ns/sctp/sctp*.{cc, h}.

SCTP Agents The base SCTP Agent Supports features of RFC2960 Does not yet support Normal Establishment of an Association (rudimentary handshake) Transmission of DATA Chunks Acknowledgment on Reception of DATA Chunks Management Retransmission Timer Multihomed SCTP Endpoints Stream Identier and Stream Sequence Number Ordered and Unordered Delivery Report Gaps in Received DATA TSNs SCTP Slow-Start and Congestion Avoidance Endpoint Failure Detection Path Failure Detection Path Heartbeat (without upper layer control)

SCTP Agents The base SCTP Agent Configuration Agent/SCTP set pathMaxRetrans_ 5 ;# Changes the class variable $sctp set pathMaxRetrans_ 5 ;# Changes pathMaxRetrans_ for the $sctp object only

SCTP Agents Extensions Newreno SCTP Similar to the base SCTP agent, Introduces Fast Recovery mechanism to avoid multiple cwnd reductions in a single round-trip time. Restricts the cwnd from being increased during Fast Recovery HbAfterRto SCTP Better RTT estimatimation A heartbeat is sent immediately to the destination on which a timeout occurred. MultipleFastRtx SCTP Attempts to minimize the number of timeouts which occur Algorithm allows the same TSN to be Fast Retransmitted several times if needed without waiting for thr RTO Timestamp SCTP Introduces timestamps into each packet, thus allowing a sender to disambiguate original transmissions from retransmissions. Retransmissions on the alternate path can be used to update the RTT estimate and keep the RTO value more accurate. With timestamps, the sender has more samples for updating the RTT estimate of alternate destination(s)

Agent/SRM SRM agent performs the following functions Packet handling, Loss recovery, and Session message activity. Creating the Agent set ns [new Simulator] ;# preamble initialization $ns enableMcast set node [$ns node] ;# agent to reside on this node set group [$ns allocaddr] ;# multicast group for this agent set srm [new Agent/SRM] $srm set dst_ $group ;# configure the SRM agent $ns attach-agent $node $srm $srm set fid_ 1 ;# optional configuration $srm log [open srmStats.tr w] ;# log statistics in this file $srm trace [open srmEvents.tr w] ;# trace events for this agent The key steps in configuring a virgin SRM agent are to assign its multicast group, and attach it to a node.

THANK YOU!