Difference between revisions of "HOWTO use CORE to test ns-3 TCP"

From Nsnam
Jump to: navigation, search
(Prerequisites)
(Setting up CORE)
Line 134: Line 134:
  
 
   # ifconfig eth0 promisc
 
   # ifconfig eth0 promisc
 +
 +
There is one final manual step.  The ns-3 program, when it runs, will assume the IP address 10.0.0.1/24 on its interface.  The underlying CORE container also is configured for 10.0.0.1/24.  This may lead to ARP race conditions; we do not want the container replying to n2's ARP requests.  The solution is to delete the IP address 10.0.0.1 from the n0 container, and add another temporary address (the DCE program will assert if there is no IP address on the underlying interface).
 +
 +
  # ip addr del 10.0.0.1/24 dev eth0
 +
  # ip addr add 10.1.2.3/24 dev eth0

Revision as of 18:57, 10 September 2014

Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects

Installation - Troubleshooting - User FAQ - HOWTOs - Samples - Models - Education - Contributed Code - Papers

This is a use case for the parent page of HOWTO Use CORE to test ns-3 protocols

Use case summary

We want to test the operation of ns-3's TCP with the TCP of other operating systems, for correctness and interoperability. We want the ns-3 TCP to operate as a client and a server (in different test runs).

A key consideration is what will be the application that will drive the TCP. Note that if there are any application-level semantics in the bit stream being exchanged, whatever is sitting on top of ns-3's TCP must be able to interoperate with whatever is sitting on top of the real node's TCP.

Iperf is a popular testing tool, but it has exactly these types of application-level semantics-- iperf will not interoperate with an ns-3 application. Fortunately, the ns-3 Direct Code Execution mode supports iperf, so we will describe that herein.

Another alternative (not written up here) would be to use Stevens's sock program as the real node's application, and either BulkSendApplication or PacketSink as the ns-3 application.

Prerequisites

We are aiming for the following configuration, where CORE can be used to add delay and packet errors.

Core-two-node-tcp.png

First, download bake as described in the bake quick-start guide:

$ hg clone http://code.nsnam.org/bake
destination directory: bake
requesting all changes
adding changesets
adding manifests
adding file changes
added 323 changesets with 779 changes to 63 files
updating to branch default
45 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd bake
$ export BAKE_HOME=`pwd`
$ export PATH=$PATH:$BAKE_HOME
$ export PYTHONPATH=$PYTHONPATH:$BAKE_HOME
$ mkdir dce
$ cd dce
$ bake.py configure -e dce-ns3-1.3
$ bake.py download && bake.py build
>> Searching for system dependency libpcap-dev - OK
>> Searching for system dependency libexpat-dev - OK
>> Downloading iperf - OK
>> Downloading wget - OK
>> Downloading thttpd - OK
>> Searching for system dependency python-dev - OK
>> Searching for system dependency pygraphviz - OK
>> Searching for system dependency pygoocanvas - OK
>> Downloading pybindgen-0.17.0.868 - OK
>> Searching for system dependency g++ - OK
>> Searching for system dependency libc-debug - Problem
> Problem: Optional dependency, module "libc-debug" not available
  This may reduce the  functionality of the final build. 
  However, bake will continue since "libc-debug" is not an essential dependency.
  For more information call bake with -v or -vvv, for full verbose mode.
>> Searching for system dependency qt4 - OK
>> Downloading ccnx - OK
>> Downloading elf-loader - OK
>> Downloading netanim-3.105 - OK
>> Downloading ns-3.20 - OK
>> Downloading dce-meta-1.3 (target directory:ns-3-dce) - OK
>> Downloading dce-ns3-1.3 (target directory:ns-3-dce) - (Nothing to do, source directory already exists) - OK
>> Building iperf - OK
>> Building wget - OK
>> Building thttpd - OK
>> Building pybindgen-0.17.0.868 - OK
>> Building ccnx - OK
>> Building elf-loader - OK
>> Building netanim-3.105 - OK
>> Building ns-3.20 - OK
>> Building dce-ns3-1.3 - OK

Now run the iperf example as shown in the quick start guide.

$ cd source/ns-3-dce/
$ ./waf --run dce-iperf
Waf: Entering directory `/path/to/bake/dce/source/ns-3-dce/build'
...
'build' finished successfully (0.551s)

And look at the resulting stdout files:

$ cat files-1/var/log/*/stdout
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  124 KByte (default)
------------------------------------------------------------
[  4] local 10.1.1.2 port 5001 connected with 10.1.1.1 port 49153
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-11.2 sec  5.75 MBytes  4.31 Mbits/sec
$ cat files-0/var/log/*/stdout
------------------------------------------------------------
Client connecting to 10.1.1.2, TCP port 5001
TCP window size:  124 KByte (default)
------------------------------------------------------------
[  3] local 10.1.1.1 port 49153 connected with 10.1.1.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec   640 KBytes  5.24 Mbits/sec
[  3]  1.0- 2.0 sec   512 KBytes  4.19 Mbits/sec
[  3]  2.0- 3.0 sec   640 KBytes  5.24 Mbits/sec
[  3]  3.0- 4.0 sec   512 KBytes  4.19 Mbits/sec
[  3]  4.0- 5.0 sec   640 KBytes  5.24 Mbits/sec
[  3]  5.0- 6.0 sec   512 KBytes  4.19 Mbits/sec
[  3]  6.0- 7.0 sec   512 KBytes  4.19 Mbits/sec
[  3]  7.0- 8.0 sec   640 KBytes  5.24 Mbits/sec
[  3]  8.0- 9.0 sec   512 KBytes  4.19 Mbits/sec
[  3]  9.0-10.0 sec   640 KBytes  5.24 Mbits/sec
[  3]  0.0-10.2 sec  5.75 MBytes  4.73 Mbits/sec

This validates that DCE can run iperf between two ns-3 nodes. Next, we want to change the program to use ns-3 emulation mode.

Setting up CORE

Create a simple two-node topology using the CORE GUI and the default IP addresses that it provides. It should look like the below (to be inserted).

Start CORE. The ns-3 node is going to be the one on the left (10.0.0.1). The container node is going to be on the right.

The devices in the containers need to be in the proper state: any hardware offloading should be off, and device eth0 needs to have promiscuous turned on.

Obtain a shell on n0 and n1 and type 'ethtool --show-offload' at the prompt. If it displays:

 # ethtool --show-offload eth0
 Features for eth0:
 rx-checksumming: on
 tx-checksumming: on
 ...
 generic-segmentation-offload: on

These features must be disabled as follows:

 # ethtool -K eth0 gso off
 # ethtool --offload eth0 rx off tx off

Additionally, on node n0, if promiscuous bit is not set on eth0, it must be enabled:

 # ifconfig eth0 promisc

There is one final manual step. The ns-3 program, when it runs, will assume the IP address 10.0.0.1/24 on its interface. The underlying CORE container also is configured for 10.0.0.1/24. This may lead to ARP race conditions; we do not want the container replying to n2's ARP requests. The solution is to delete the IP address 10.0.0.1 from the n0 container, and add another temporary address (the DCE program will assert if there is no IP address on the underlying interface).

 # ip addr del 10.0.0.1/24 dev eth0
 # ip addr add 10.1.2.3/24 dev eth0