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 welldefined 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
Application/
Traffic/
Exponential
API
Agent/UDP
Simulated applications
Application/FTP
API
Agent/TCP/FullTcp
The diagram illustrates how agents and applications are
hooked together and communicate with one another via
the 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
Create src, dest. nodes & a link
Create agents & starting traffic generator
•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"
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
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 clientserver 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!