IASTED ASM 2004 Tutorial:

(1)

U ni Inn sbruck U ni Inn sbruck Informatik Informatik

IASTED ASM 2004 Tutorial:

The

ns

--

2

2 Network Simulator

Network Simulator

Michael Welzl

http://www.welzl.a

t

http://www.welzl.a

t

Distributed and Parallel Systems Group

Institute of Computer Science

University

of

Innsbruck, Austria

(2)

U ni Inn sbruck U ni Inn sbruck Informatik Informatik --2 2

Outline

simulated transit-stub ne twork (ns/nam dum p)

• ns-2 over

view

• W

riting simulation scripts

• O

btaining results

• G

ener

al network simulation hints

•T

ea

ch

in

g w

it

h n

s-2

•C

on

cl

us

io

n

(3)

ns

--

2 overview

(4)

Some thoughts about network simulation

• R

eal-world experiments sometimes impossible

• M

athematical modeling can be painful

_–Sometimes even painful

and

inaccurate!

• Simulation

cannot totally replace

real-world experiments:

– stack p rocessing delay, buffering, timing, ..

• and

vice versa!

– scal ing,

simulated vs. real time (long s

imulations), ..

• Simulation

sometimes misses the whole picture

– focus on specific layers, w rong assumptions, ..

(5)

ns

--

2 (ns

version

2)

overview

• discrete event simulator (but does not strictly follow DEVS formalism)

• O

Tcl

and C++

– O Tcl scripts, C++ m echa nism impl em entat ions,

timing critical code

• de facto

standard for

Internet

simulation

• open source!

advantages:

– facil itates buil

ding upon other work

– allows others to use your w ork

• disadvantages:

– huge and complicated code – partial ly missing, somewhat p oor documentation

(6)

What to use it for

• M

ainly research

_–Examining operational networks, e.

g. with Cisco brand na

mes: OPNET

• Focus on Internet technology

–t

he

tool for TCP simulations

• N

ot ideal for new link layer technologies etc.

_–typical

ly

neglects

everything underneath layer 3

–

there are special s

imulators for things

l

ike ATM

• But: lots of features!

–

C

SMA/CD, 802.11 now available ... if you really

want it

–

(7)

-Some ns

Some ns

--

2 features

• Lots of TCP (and r

elated) implementations

• M

obility

• Satellite nodes: specify longitude, latitude, altitude

• Inter

net routing protocols

• V

arious link loss models

• V

arious traffic generators (e.g., web, telnet, ..)

• N

etwork emulation capability (rea

l traffic traverses simulated net)

flexible, but hard to use; al

ternatives

(8)

Simulation

process

•N

ot

in

te

ra

ct

iv

e

• Script

describes scenario,

event scheduling times

• Typical

last line:

$ns

run

• ns

generates output files

• “Inter

active simulation“:

view

.nam

ou

tput file wi

th network

animator

nam

•

(9)

Typical long

--

term simulation process

• M

echanism implementation

in C++, test

with

simple

OTcl script

• Simulation

scenario dev

el

opmen

t

in

O

Tcl

• T

est

simulation with

nam

• O

ne way to

obtain

a

useful result:

perl

script

->

simulations with varying

parameter(s) ->

seve

ral output files

->

perl

script

->

result file

->

xgraph

(gnuplot, MS Excel, ..) ->

ps file

(10)

Simulation elements

•C

od

e:

C++ network elements, OTcl simulator elements and

simulation script, perl (or whatever) scripts for running simulation

and interpreting results

•n

s

to run simulation,

nam

for immediate

feedback

• V

isualization tool

(xgraph, gnuplot, ..)

C++ net w or k e le m ent s O tcl scr ip t ns tr a ce fil e us er pe rl scri p t re su lts vi su al is a tio n to ol di a gr am na m gen erate s us es na m tr a ce fi le

(11)

Writing simulation scripts

(12)

Writing simulation scripts

•O

T

cl

-w

hat you require is some Tcl knowledge

–

not complicated, but troublesome

:

e.g., line breaks can lead to syntax errors

• Some peculiarities

–

variables not declared, generic typ

e: set a 3 instead of a=3 –

expressions must be explicit:

set a [expr 3+4]

set a 3+4

stores string “3+4“ in a

–

use “$“ to read from a variable:

set a $b instead of set a b set a b stores s tring “b“ in a

•W

ri

te

o

ut

pu

t:

puts “hello world“

• O

Tcl objects: basically used like variables

_–m

et ho d c al ls :

$myobject method param1 param2

no

(13)

Code

template

(Marc Greis

tutorial

)

#Create a sim ulator object set n s [new S imulator] #Open

the nam trace file

set nf [open out.nam w ] $ns n amtrace-all $nf #Define a 'fi nish' procedure proc finish {} { _global ns nf $ns flush-trace #Close th e trace file clos e $nf #Execute nam on

the trace file

ex ec nam out.nam & exit 0 } set variable value [new Simulator] genera tes a Simulator object op en “ ou t. na m “f or writing, ass ociate with nf $ns ns-comma nd parameters log everything as nam o utput in Run nam with parameter out.nam as background process (unix)

More about Tcl & OTcl:

http://www .isi.edu/nsnam/ ns/tutorial/index.html (“finding docum entatio n“)

(14)

Code

template

/2

#

Insert your own code for topology creation

# and agent defini tions, etc. here #Call the finish procedure af ter 5 seconds sim ulation time $ns at 5.0 "fi n ish" #Run the sim ulation $ns run

$ns at time “command“ schedule co

mm

and

#Create two nodes set

n0 [$ns node] set n1 [$ns node] #Create a duplex link

between the nodes

$ns duplex-l ink $n0 $n1 1Mb 10ms D ropTail #Creat e a CBR ag en ta nd attach it to node n0 set cbr0 [new Agent/CBR] $ns attach-agent $n0 $cbr0 $cbr0 set packetSize_ 500 $cbr0 set interval_ 0.005 #Create a Null agent (a traffic sink) and attach it to node n1 set sink0 [new Agent/Null] $ns attach-agent $n1 $nul l0

#Connect the traffic source with the traffic

sink

$ns

connect

$cbr0 $sink0

#Schedule

events for the

CBR agent $ns at 0.5 "$cbr0 start" $ns at 4.5 "$cbr0 stop" Other agents: T CP, UDP, .. Agent pa rameters CBR <-> Null,TCP <-> TCPSink! “$cbr0 start“ contains no de stinatio n address

(15)

nam

(16)

Applications

• A

pps: layered on top of agents

• C

BR the “clean“ way:

set udp [new

Agent/UDP

]

$ns attach-agent $myNode $udp set cbr [new

Application/Traffic/CBR

]

$cbr set packetSize_ 500 $cbr set interval_ 0.005 $cbr attach-agent $udp $ns connect

$udp $myNullAgent $ns at 0.5 $cbr start $ns at 4.5 $cbr stop Other applications: ftp (g reedy tcp source)

telnet Traffic/Exponential Traffic/Pareto

or LossMonitor _{always connec}

t agents , so me time s als o apps ! start / sto p th

e app, not the

(17)

More agents

• C

BR

<-> Null, CB

R <-> LossMonitor

–

note: CBR agent deprecated!

• T

CP <-> TCPSink

_–one-way Tahoe implementation _–other fl

avours:

TCP/Reno, TCP/NewReno, TCP/Sack1,

TCP/Ve gas – two-way: use FullTCP at b oth sides

• T

CP-friendly connectionless protocols:

_–R

AP <-> RAP _{Rate Adaptation Protocol (rate-based AIMD + Slow Start)}

–T FR C < -> T FR C Si nk – T

CP Friendly Rate Control protocol (based on _{TCP throughput-equation)}

(18)

Transmitting user data

•T

cp

A

pp

application

-use on top of

Agent/TCP/SimpleTCP

• set tcp1 [new Agent/TCP/SimpleTCP ] set tcp2 [new Agent/TCP/SimpleTCP ] $ns attach-agen t $node1 $tcp1 $ns attach-agen t $node2 $tcp2

$ns connect $tcp1 $tcp2 $tcp2 listen ( $tcp1 listen )

•

set app1 [new

Application/TcpApp

$tcp1]

set app2 [new

Application/TcpApp

$tcp2]

$app1 connect $app2 ( $app2 connect $app1 )

• $ns at 1.0 “$app1 send 100 \"$app2 app-recv 123\““ • Application/TcpApp instproc app-recv { number } { ... } if you want to receive ... size to se nd back

(20)

Writing your own protocol

• simple (for teaching): use TcpApp

–

inefficient, not very flexible

• m

ore useful (for researchers): change ns code

• two basic approaches

1.

truly understand architecture (class

hierarchy, including “shadow objects

“ in OTcl etc.)

2.

“hack“ code –

change existing code to suit your needs

–

generally use C++ (and not O

T cl) if poss ib le works su rprisingly well; I recom m end this.

(21)

How to “hack“ ns code

• “ping“ example

in the Marc Greis tutorial

(easy

-try it!)

–

simple end-to-end protocol

• how to integrate your code in ns:

–

w

rite your code: e

.g., ping.h and ping.cc – if it‘s an agent... • “command“ method

= method call from OTcl

•

recv method

= called when a packet arrives

–

if it‘s

a new packet type: change

packet.h and tcl/lib/ns-packet.tcl – change tcl/lib/ns-default.tcl •

define and initial

ize attributes that are visib

le from OTcl – do a “ ma ke depend “, the n “ make “

• N

ote: ns manual mixes “how to use it“ with “what happens inside“

_–this is where you l

ook for d

(22)

Obtaining results

(23)

Obtaining results

proc record {} { global sink0 ns f0 #Set the time a

fter which the proc

edure should be

set

time 0.5

#How many bytes ha

ve been received by the traffic sinks?

set

bw0 [$sink0

set bytes_]

#Get the current

time

set now

[$ns

now]

#Calculate the bandwidth

(in MBit/s) and write it puts $f0 "$now [expr $ b w0/$time*8/1000000]"

#Reset the bytes_

value s o n t he traffic sinks $sink0 s et bytes_ 0 #Re-schedule the procedure $ns at [expr $now+$time] "record" } read byte counter puts [$ filehandle] “text“ wr ite te xt t o a fil e No te : puts “[expr puts “1+1“ -> 1+1

Use LossMonitor instead

of Null

agent

Im

portant:

(24)

Obtaining results

/2

• LossMonitor: simple

solution for

C

BR,

but

TCP <->

TCPSink

!

• V

ery common solution:

generate tracefile

set

f [open

out.tr

w]

$ns

trace-all $f

• Trace file format:

$agent set class_

num

(e.g. $u

dp set class_ 1)

Color your flow

in

nam:

$ns color

num color

(e.g. $ns color 1 blue)

Monitoring queues in nam

:

$ns duplex-link-o

p $node1 $no

(25)

Obtaining results

/3

• Problem:

trace files can be very large

• Solution 1:

use pipe

set

f [open

| perl

filter.pl parameters

w

]

$ns

trace-all $f

• O

ther solutions:

_–U se s

pecific trace or monitor

-more efficient! – direct output in C++ code

-even more efficient,

but less flexib le!

• N

ote: TCP

throughput

!= TCP “

goodput

“

– G ood put: bandwidth s

een by the receiving application

–

should not incl

ude retransmits! – requires modification of TCP C++ code perl script to filter irrelevant information (could b

(26)

Dynamic vs. long

--

term behavior

• T ypical

ly two types of simulation results:

– dyna m ic behavior –

long-term behavior: 1 result per simulati

on (behavior as function of parameter) • D ynami c beha

vior: parse trace file (e.g. with “throughput.pl“)

–

roughly:

oldtime = trace_time; while (read != eof)

if (trace_time

-o

ldtime < 1)

sum_bytes += trace_bytes;

else {

print “result: sum_byte /

(trace_time

-o

ldtime);

oldtime = trace_time; }

–

actually slightly more difficult

-e.g.,

“empty“ intervals should be included

•

long-term behavior –

script calls simulations with varying pa

rameter

–

each simulation trace file parsed (simpl

y summarize

data or

calculate stat

ist

(27)

Long

--

term behavior

• Simulation script:

– (..) set parameter [lindex $argv 0]

(..) set f [open "| perl stats.pl tcp

w

]

$ns trace-all $f (..) ($parameter used in simulation!)

• loop:

–

for {set i 1} {$i <= 1

0} {set i [expr $i+1]} {

exec echo $i >> results.dat exec ns sim.tcl $i >> results.dat

}

• Plot final file with additional tool (e.g. gnuplot)

external parameter

w

rite 1 result line

(+ line b

reak) to

appe

(28)

Visualizing dynamic behiavor:

CADPC Routing robustness

manual edit

xgraph pl

ot

o

f

throughput.pl result nam output (“pr

int“

+ postscript driver)

(29)

Example result 2: CADPC vs. TCP, dynamic

(30)

Example 3: CADPC startup

enhancement

(31)

Long

--

term CADPC results (gnuplot)

Throughput

Avg. Queue Length

Loss

(32)

General network simulation hints

(33)

Recommendations

• Select parameters carefully

–

consider RTT: what is

realistic? what is

a reasonable simulation

–

ideally,

duration should dep

end on statistics

•

e.g., until variance < threshold

•

not supported by ns

•

thus, just simulate long (realistic

duration for, e.g., ftp download)

• Frequently ignored (but important) parame

ters:

–

T

CP ma

ximum send window size

(should not limit TCP behavior)

–

T

CP “flavor“ (should be a state-of-the-art variant l

ike SACK)

–

buffer l

ength (should be bandwidth*delay)

–

A

(34)

Recommendations /2

_•

Start simple, then gradually approach reality

–

1 source, 1 de stination – m ultipl e homogeneous flow

s across single bottleneck

– m ultipl e homogeneous flow s with heterogeneous RTTs – m ultipl e heterogeneous fl ows with

homogeneous and heterogeneous RTTs

–

impact of routing changes, various type

s of traffic sources (web, “greedy“, ..)

• eventually implement and test in controlled environment

•

(35)

Common

topologies

• D

umbbell:

_{evaluate basic}

_end2end

behaviour,

TCP-friendliness, ..

–o ft en : n vs . m fl ow s

• Parking Lot:

evaluate behaviour

with

different

RTT's,

fairness, ..

– often: S0/D0 -n flows, all other S/D pairs -m flow s

S1

Sn

S0

D1

S1

S2

D2

(36)

Recommended papers (simulation

method

)

• Krzysztof Pawlikowski, Hae-Duck

Jeong, and

Jong-Suk Ruth Lee,

“On

Credibility of Simulation Studies of

Telecommunication Networks“,

IEEE Communications Magazine, Januar

y 2002,

pp. 132-139.

• M

ark Allman, Aaron Falk, “On the Effective Evaluation of TCP“,

A

CM

Computer Communication Review,

29(5), October 1999.

http://www.icir.org/mallman/papers/tcp-evaluation.pdf

• Sally Floyd and Ver

n Paxson, “Diffi

culties in Simulating the

Internet“,

IEEE/ACM Transactions on Networking, Vol.9, No.4, pp. 392-403.

• Sally Floyd and Eddie Kohler, “Inter

net Research Needs Better

Models“, ACM Hotnets-I,

October 2002.

• and this website: http://www.ic

(37)

Teaching with ns

--

2

(38)

Teaching experience: ns for lab exercises

•

Reason to use ns – lack of other t ools t o “fool arou nd“ wit h network dynamics

(mainly congestion control)

–

some sort of “hands-on experien

ce“ without enda

ngering real net

•

Personal experience

: (3 times; lab courses accompanying

networks lecture)

-Students did not

like

i

t!

–

poor documentation (problem elimin

ated for 3rd try, didn‘t help)

–

O

Tcl learning effort large, but

ex

ercises small

-too much overhead

–

some things do not work

as

expected; bugs etc.

•

Recommendations –

avoid long-term simulation

(various languages and files for single exercise)

–

avoid C++ chang

es; exercises in

OTcl only, with precompiled ns-2

• C urrently w orking on a GUI ! (monitor my ns website) No te : teaching repository at ns site

lecture + nam animatio

ns

could b

(39)

Example exercise 1: congestion collapse

_•

C

ongestion

control necessary

• adding

fast links

does

not

help!

S1

S2

100 kb/s 1000 kb/s 100 kb/s 10 kb/s 110 kb/s Queue S 1 S 2 Switching Fabric

total throughput w/o cc.:

20kb/s

total throughput w/ cc.:

(40)

Example exercise 1: congestion collapse /2

“knee“

“cliff“

(41)

Internet congestion control: History

• 1968/69:

dawn

of

the

Internet

• 1986:

first congestion

collapse

• 1988:

"

Congestion Avoidance and Control

"

(Jacobson)

Combined congestion/flow control for

T

CP

• G

oal:

stability

-in

equilibrum, no packet

is sent into the network

until

an old packet

leaves

–

ack clocking, “conservation

of packets“ princip le – m

ade possible through window bas

ed stop +go -be haviour

• Superposition of

stable

systems =

stable

Æ

network based

on TCP

w

ith congestion control

=

(42)

TCP Congestion

Control

/1:

Tahoe

, 1988

• D

istinguish:

_–flow control: pr otect receiver against overl oad (receiver "grants" a certain amount of data ( "receiver window" ) ) – conges tion control: protect network against overl oad ( "congestion window" (cwnd) limits the rate: min(cwnd,rwnd) use d! )

• Flow/Congestion

Control combined

in TCP.

Several algorithms:

• (window unit: SMS S

= Sender Maximum Segment

Size, usually adjusted to Path M T U; init cwnd<=2 (*SMSS), sst hresh = usually 64k) – Slow Start:

for each ack received,

increase cwnd b y 1 (exponential growth) until cwnd >= ssthresh – C ongestion A voidance: each RTT, increase cwnd by SM SS *SMSS /cwnd (linear growth -"additive increase " )

(43)

TCP Congestion

Control

/2

• If

a packet

or ack is

(timeout,

roughly

4*rtt),

cwnd

= 1,

ssthr

esh

=

bandwidth

/ 2

(

“multiplicative decrease"

_exponential

backoff

• Several timers,

based

RTT;

good

estimation is

crucial!

• Later additions:

(TCP Reno, 1990)

Fast

retransmit

/ fast

recovery

(notify sender

loss via duplicate acks)

0 1 2 3 4 5 6 7 8 9 123456789 10 11 12 13 14 15 16 ti m e bandw id th

Timeout

ssthresh

Slow Start Congestion Avoidance

(44)

Example exercise 2: TCP vs. UDP

(45)

Example exercise 2: TCP vs. UDP /2

1 tc p - 1 cb r - d ro p ta il -50000 0 50000 100000 150000 200000 1 0 tc p - 1 c -200000 0 200000 400000 600000 800000 1000000 1200000 1400000 10 0 t cp - 1 cbr - dr op ta il -200000 0 200000 400000 600000 800000 1000000 1200000 1400000 1 00 tc p --200000 0 200000 400000 600000 800000 1000000 1200000 1400000

•R

es

ul

ts

b

y a

(46)

Conclusion

(47)

Conclusion

• R

esear

ch

+ freely available + de facto stand

ard for (Internet-) simulations

+

open source s

pirit: compare your mechanism with the state-of-the-art

+

lots

of features

–

rather complex architecture; new protocol

= typically a hack

–

m

ust use lots

of tool s (and typical ly languages) at once

•T

ea

ch

in

g

– O

Tcl learning effort for exercises

+

nam animations may be good

fo

(48)

Key links

• O

fficial website:

http://www.isi.edu/nsnam/ns

–d oc s: “ns ma nual“, “

Marc Greis‘ tutorial

“, “ns by exa

m

ple“

•

note: HTML version of “ns manual“ not alw

ays up-to-date

–

large number of “Contributed Modules“

• Personal ns website:

http://www.welzl.at/tools/ns

–

“throughput“ and “stats“ scripts

–

w

orking versions of ns and nam Windows binaries

– G erman ns documentation (s tudent work) –t he se s lid es

• LLoyd Wood‘s site:

http://www.ee.surrey.ac.uk/Personal/L.Wood/ns/

–

(49)