Hi All, Our website moved to a new URL. Please bookmark the new link: https://ns2bloggers.blogspot.com/

Showing posts with label congestion. Show all posts
Showing posts with label congestion. Show all posts

Friday, 11 September 2015

CONGESTION WINDOW "cwnd" IN NS2

In TCP Networks, the most important factor that determines behavior is its congestion window size. In NS2, we can handle it with using cwnd command. In NS, every TCP type classes have a variable named "cwnd" that contains the congestion window size of the TCP Module. In here we can use 'set' command to return a value. 

We can write it as;
set  tcp1  [new  Agent/TCP/Reno]
set  cwnd1  [ $tcp1  set  cwnd_ ]

To obtain TCP's CWND value frquently;

  • We can easily make the NS simulation system repeatedly read the value (say, after every 0.1 sec of simulation time).
  • Schedule a read operation repeatedly

Proc plotWindow {tcpSource outfile} {
     global ns

     set now [$ns now]
     set cwnd [$tcpSource set cwnd_]

  #  Print TIME CWND   for  gnuplot to plot progressing on CWND   
     puts  $outfile  "$now $cwnd"

     $ns at [expr $now+0.1] "plotWindow  $tcpSource  $outfile"
  }

  • The procedure plotWindow takes a paramter tcpSource which is a TCP agent.So you can use the procedure to plot the CWND from any number of TCP flows.


  • The procedure plotWindow takes an output file ID outfile.You should first open an output file (or use "stdout") in the main program.

Examining progressing of CWND in TCP (Reno)

#Make a NS simulator   
  set ns [new Simulator]

  # Define a 'finish' procedure
  proc finish {} {
     exit 0
  }

  # Create the nodes:
  set n0 [$ns node]
  set n1 [$ns node]
  set n2 [$ns node]
  set n3 [$ns node]
  set n4 [$ns node]
  set n5 [$ns node]

  # Create the links:
  $ns duplex-link $n0 $n2   2Mb  10ms DropTail
  $ns duplex-link $n1 $n2   2Mb  10ms DropTail
  $ns duplex-link $n2 $n3 0.3Mb 200ms DropTail
  $ns duplex-link $n3 $n4 0.5Mb  40ms DropTail
  $ns duplex-link $n3 $n5 0.5Mb  30ms DropTail

  # Add a TCP sending module to node n0
  set tcp1 [new Agent/TCP/Reno]
  $ns attach-agent $n0 $tcp1

  # Add a TCP receiving module to node n4
  set sink1 [new Agent/TCPSink]
  $ns attach-agent $n4 $sink1

  # Direct traffic from "tcp1" to "sink1"
  $ns connect $tcp1 $sink1

  # Setup a FTP traffic generator on "tcp1"
  set ftp1 [new Application/FTP]
  $ftp1 attach-agent $tcp1
  $ftp1 set type_ FTP               (no necessary)

  # Schedule start/stop times
  $ns at 0.1   "$ftp1 start"
  $ns at 100.0 "$ftp1 stop"

  # Set simulation end time
  $ns at 125.0 "finish"    (Will invoke "exit 0")   


  ##################################################
  ## Obtain CWND from TCP agent
  ##################################################

  proc plotWindow {tcpSource outfile} {
     global ns

     set now [$ns now]
     set cwnd [$tcpSource set cwnd_]

  ###Print TIME CWND   for  gnuplot to plot progressing on CWND
     puts  $outfile  "$now $cwnd"

     $ns at [expr $now+0.1] "plotWindow $tcpSource  $outfile"
  }

  $ns  at  0.0  "plotWindow $tcp1  stdout"   // Start the probe !!    


  # Run simulation !!!!
  $ns run


his NS Prog prints the (time, cwnd) to the terminal: click here
This NS Prog prints the (time, cwnd) to the output file "WinFile": click here

To plot the window progressing from "winfile", do:

UNIX>> gnuplot
gnuplot>> plot "WinFile" using 1:2 title "Flow 1" with lines 1

Note:
In case you wonder why the cwnd plot look so different, It's because the setting of some parameters.
Add the following statements to the simulation to get the one I used in class:

  # ########################################################
  # Set Queue Size of link (n2-n3) to 10 (default is 50 ?)
  # ########################################################
  $ns queue-limit $n2 $n3 10


  # ########################################################
  # TCP parameters:
  # ########################################################    
  $tcp1 set window_ 8000
  $tcp1 set packetSize_ 552

This NS Prog will draw the CWND: click here

Postscript: Analyzing multiple TCP flows

The easiest way to analyze the behavior of multiple TCP is to open one file to store the progression of one TCP agent's variable values.

 TCP Agents

  set tcp1 [new Agent/TCP/Reno]
  ...
  set tcp2 [new Agent/TCP/Reno]
  ...


  set outfile1  [open  "WinFile1"  w]
  set outfile2  [open  "WinFile2"  w]


  $ns  at  0.0  "plotWindow $tcp1  $outfile1"

  $ns  at  0.0  "plotWindow $tcp2  $outfile2"     

Plot data of  TCP 1 will be store in file "WinFile1"

Plot data of  TCP 2 will be store in file "WinFile2"

Friday, 23 May 2014

CONGESTION CONTROL ALGORITHM FOR NETWORKS

Rate Control Protocol (RCP) is a congestion control algorithm designed for fast download times (i.e. aka user response times, or flow-completion times). Whereas other modifications to TCP (e.g. STCP, Fast TCP, XCP) are designed to work for specialized applications that use long-lived flows (scientific applications and supercomputer centers), RCP is designed for the typical flows of typical users in the Internet today. For example, a mid-size flow in the Internet today contains 1000 packets and TCP typically makes them last 10x longer than need-be (XCP is even worse). RCP makes flows finish close to the minimum possible, leading to a perceptible improvement for web users, distributed computing, and distributed file-systems. We believe RCP is the only congestion control algorithm to do this.

The main properties of RCP are:
  • Typical Internet flows will see 10 times faster download times than TCP and 30 times faster than XCP. Winners are the greater than 90% of sessions that never leave slow-start today.
  • Efficiently uses high bandwidth-delay product networks such as the long haul optical links.
  • Provably stable network independent of link-capacities, round-trip times and number of flows.
  • Flows are easy to police, to ensure they adhere to congestion control (not generally possible with other schemes).
  • Network operators can give preference (or weighted preference) to some flows/aggregates.

RCP has two components : 

(1) End-host congestion control layer that sits between IP and TCP/UDP. During introduction, the end-host could adapt by testing for RCP at each end and along the path, falling back to TCP if need-be. 

(2) Each router maintains a single fair-share rate per link. Each packet carries the rate of the bottleneck link. For each packet, the router compares the two values. If the router's fair-share rate is smaller, it overwrites the value in the packet. This way, the source learns the fair-share rate of bottleneck link. It is simple, requires a very minor change to switches/routers and requires no per-flow state. 


For scripts, Click here
For ns 2.35 RCP patch, Click here 
For more, Click here