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 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 ExtensionsNewreno 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!