Thursday, 23 January 2014

Linux TCP implementation for NS2



This is a patch that can run Linux TCP congestion control algorithms on NS2, with similar simulation speed and memory usages as other NS2 TCPs (e.g. Sack1). The implementation loosely follows the Linux TCP implementation, and can produce results comparable to Linux experimental results. The patch is for NS-2.31 and compatible with 2.29 and 2.30. You may need some modification if you want to install it for other versions.


Patch for NS-2.31:

The patch can be downloaded from here. It is for NS-2.31 and compatible with 2.29 and 2.30. To install the patch, you need to take the following steps, assuming you have successfully installed and run NS-2.31 in your computer:
  1. Copy the patch to ns-allinone-2.31/ns-2.31
  2. In the directory of ns-allinone-2.31/ns-2.31 , run: make clean
  3. In the directory of ns-allinone-2.31/ns-2.31 , run: patch -p1 < ns-linux-v2.patch
  4. (Optional) delete the patch file by rm ns-linux-v2.patch
  5. recompile the ns2 by make and make install
The patch changes the following files:
  • tcp/tcp-linux.h, tcp/tcp-linux.cc: (new files) the NS-2 TCP Linux module
  • tcp/tcp.cc: (modifiying old file) fixed a bug in sending timestamp array (for delay-based algorithms)
  • tcp/scoreboard1.h and tcp/scoreboard1.cc: (new files) the Linux-like scoreboard implementation
  • tcp/linux/: (new files) this directory is added to hold the linkages between C++ codes in NS2 and C codes in Linux
  • tcp/linux/src/: (new files) this directory is added to hold source codes of Linux TCP congestion control modules
  • Makefile: (modifying old file) to include a list of new files to be compiled
  • tcl/lib/ns-default.tcl: (modifying old file) to add default values to control variables in TCP-Linux
  • tcl/test/test-all-tcpLinux and tcl/test/test-suite-tcpLinux.tcl: (new files) added for NS-2 compatible validation tests
  • tcl/ex/tcp-linux/ (new files): two example files on running TCP-Linux
  • doc/ns.bib and doc/tcp.tex (modifying old files): documentation files
  • This patch also includes a scheduler improvement patch to speed up the simulation.

Legacy patch for NS-2.29 with interface in Linux-2.6.16 kernels

The old patch for NS-2.29 with congestion control interface for Linux 2.6.13-2.6.20 kernels can be found here. (Linux changes its congestion control interface in 2.6.22.) This old version is no longer supported. However, bug fixes and patches from other contributors to this project will still be published.

Usage:

This section serves as a quick reference for users who want to run different Linux TCP algorithms in the TCP Linux patch.
There is a mini-tutorial for TCP Linux . Please read the mini-tutorial for details if you want to design your own algorithms or port new algorithms from Linux to NS-2.
If you find some performance problem of some Linux algorithms, please check the known Linux bugs page to make sure it is really the problem of the algorithm, not a bug in Linux implementation.

1. Normal Usage:

The TCP-Linux module is call "Agent/TCP/Linux".  If you have an existing script that runs TCP and want to change to TCP-Linux, what you need to do is:
  1. Change the TCP Agent's name (e.g. Agent/TCP/Sack1) to Agent/TCP/Linux.
  2. Make sure the TCP Sink has Sack1 support. That is, either you are using Agent/TCPSink/Sack1 or Agent/TCPSink/Sack1/DelAck . Currently, TCP-Linux does not support receivers without SACK.
  3. Optional but recommended: change the window_ option in tcp agent to be large enough. This option is the upper bound of congestion window. It is 20 by default in NS-2. Most congestion control algorithms work the same if the congestion window is bounded by 20. The recommended value is at least bandwidth-delay-product.
  4. Before starting the simulation, add one command:
$ns at 0 "$tcp select_ca $TCP_Name"
where $ns is the NS-2 scheduler you are using in the script, and $TCP_Name is the congestion control algorithm you want to select. 

2. Basic behavior:

The patch comes with 14 different congestion control algorithms from Linux-2.6.22.6, as listed in the following table.
Please see the tcl script for the simulation details; see the control shell script for the configuration of the simulations; and the gnuplot script for how the figures are generated.
$TCP_NameCongestion Control Algorithmcwnd dynamic of a single flow (RTT=128ms, BW=100Mbps, buffer=220pkt)
bicBinary Increase Congestion control for TCP 
cubicTCP CUBIC: Binary Increase Congestion control for TCP v2.0 , an extension of BIC-TCP
highspeedSally Floyd's High Speed TCP (HS-TCP RFC 3649) congestion control
htcpHamilton TCP (H-TCP) congestion control
hyblaTCP-HYBLA Congestion control algorithm
renoTCP NewReno
Note that this "NewReno" also includes implementation of SACK and Fack.
scalableTom Kelly's Scalable TCP
vegasTCP Vegas congestion control
westwoodTCP Westwood+
venoTCP Veno
lpTCP Low-Priority (TCP-LP)
yeahYeAH-TCP 
illinoisTCP Illinois 
compoundTCP Compound (C-TCP)(Last updated for 2.6.22.9 kernel.) Please be very careful about compound module as this module has been discontinued in the kernel code base since 2.6.17. It is here for research purpose only and the interface of this module might be out-dated for the latest kernel. We do try our best to keep the module's interface up-to-date. Extra care is still recommended for validating the results with this module. And please let us know if there is any problem.

3. Advanced Usage 

Changing parameters in a congestion control module in the simulation
You can change the parameters of a congestion control module during the simulation.
Add a command to change the global value of a parameter for all flows running a congestion control module:
$ns at $ChangeTime "$tcp set_ca_default_param $TCP_Name $Parameter_Name $Parameter_Value"
where $ns is the NS-2 scheduler you are using in the script, $TCP_Name is the congestion control algorithm in concern, $Parameter_Name is the variable name of the parameter, and $Parameter_Value is the new value of the parameter.
Effect is taken on all the flows which run the $TCP_Name and without defining their own local value for this parameter. (Flows which has used set_ca_param to define a local value for this parameter will not be affected.)

Add a command to change the local value of a parameter for a particular flow running a congestion control module:
$ns at $ChangeTime "$tcp set_ca_param $TCP_Name $Parameter_Name $Parameter_Value"
where $ns is the NS-2 scheduler you are using in the script, $TCP_Name is the congestion control algorithm in concern, $Parameter_Name is the variable name of the parameter, and $Parameter_Value is the new value of the parameter. Effect is taken on this particular flow ($tcp). Other flows are not affected. And the value of this parameter for this particular flow ($tcp) will not be affected by any future command ofset_ca_default_param.
For details, please refer to the tutorial.
Adding your own congestion control module
You can add your own congestion control module once you develop the module in Linux.
If you decide to do so, take the following steps:
  1. Make sure your implementation is compliant to the congestion control structure in Linux (struct tcp_congestion_ops);
  2. Make sure this patch has been applied to your NS2 code base
  3. Follow the migration step in tutorial to migrate your whole Linux congestion control modules (including your own) to NS-2 code base.
  4. add a record in Makefile by adding an item to let compiler know your code:
    tcp/linux/YourCode.o
  5. compile, run and compare the simulation results with Linux experiments results
You might encounter one of the following problems in the last step:
  1. If your algorithm requires access to many new fields in Linux TCP structure, you might need to add more fields to struct tcp_sock in tcp/linux/ns-linux-util.h .

WARNING: After adding a new congestion control algorithm, please verify the simulation results extensively and carefully to make sure the simulation is running as expected.


Here is a list of known problems:
  1. The implementation does not change receiver part. The delayed ack implementation in Linux might be different from the one in NS-2. This may results in some performance difference
  2. D-SACK: This may leads to performance difference in scenarios with packet reordering.
  3. F-RTO: Not yet implemented. Will be included very soon.
  4. ECN: The implementation is not extensively verified.
  5. TCP Segmentation: Not implemented. Will NOT be covered in the near future.
  6. Buffer tuning: Not implemented. Will NOT be covered in the near future.
For more details,

http://netlab.caltech.edu/projects/ns2tcplinux/ns2linux/

No comments:

Post a Comment