Home | Reference Installation Sample TCL Scripts Implementation Details Change Log Copyright Statement
Web Traffic Generation in NS-2 with PackMime-HTTP

Note: Most of this work was done while I was a PhD student at UNC-Chapel Hill. This is an archive of those webpages.


NEW! March 2006 - PackMime and DelayBox are now both part of the main ns-2 source. For now, you can get the daily snapshot. Later, PackMime and DelayBox will be included in the next release version (ns-2.30).

Note: There are slight differences between the committed version and previous versions as described on this page. Please see the documentation (or ns-2 Manual).


The PackMime traffic model was developed by researchers in the Internet Traffic Research group at Bell Labs, based on recent Internet traffic traces.

The PackMime includes a model of HTTP traffic, called PackMime-HTTP. The traffic intensity generated by PackMime-HTTP is controlled by the rate parameter, which is the average number of new connections started each second. The PackMime-HTTP implementation in ns-2, developed at UNC-Chapel Hill, is capable of generating HTTP 1.0 and HTTP 1.1 connections.

PackMime-HTTP in ns-2 uses DelayBox, a module developed at UNC-Chapel Hill for delaying and/or dropping packets in a flow according to a distribution. DelayBox can be used with PackMime-HTTP to simulate a "cloud" of clients and servers that have different round-trip times, bottleneck link speeds, and amounts of packet loss.

- added instructions on changing the default TCP type for connections (Sep 8, 2005)

Reference

The PackMime HTTP traffic model is described in detail in the following paper:

Stochastic Models for Generating Synthetic HTTP Source Traffic
J. Cao, W.S. Cleveland, Y. Gao, K. Jeffay, F.D. Smith, and M.C. Weigle
Proceedings of IEEE INFOCOM
Hong Kong, March 2004

Installation (Last modified June 11, 2005)

Note: PackMime-HTTP requires the use of Full-TCP. You may want to look at the bug fixes I've made for Full-TCP based on ns-2.27 and ns-2.28. These fixes are not included in the PackMime-HTTP or DelayBox patches.
  1. Download, unzip, and untar PackMime-DelayBox.tar.gz (contents) into your ns-src directory.
  2. Download the appropriate patch (packmime-delaybox-2.28.patch or packmime-delaybox-2.27.patch) to your ns-src directory.
  3. Apply the PackMime-HTTP and DelayBox patch:
    patch -p0 < packmime-delaybox-2.2x.patch
  4. Re-configure and re-make ns: ./configure && make
  5. Run the PackMime-HTTP and DelayBox validation scripts:

Sample TCL Scripts

Important Note: If you are planning to run large simulations, make sure that you use the Heap scheduler ($ns use-scheduler Heap) instead of the default Calendar scheduler. It can save hours of simulation time for very large experiments.

Implementation Details

The ns network simulator has objects called "Applications" that control data transfer in a simulation. These Applications communicate via "Agents" which represent the transport layer of the network. PackMimeHTTP is the ns object that drives the generation of HTTP traffic. Each PackMimeHTTP object controls the operation of two types of Applications, a PackMimeHTTP server Application and a PackMimeHTTP client Application. Each of these Applications is conncted to a TCP Agent (Full-TCP).

Figure 1: PackMimeHTTP Architecture. Each PackMimeHTTP object controls between 1-10 server and client clouds. Each cloud can represent multiple client or server Applications. Each Application represents either a single web server or a single web client.

Each web server or web client cloud is represented by a single ns node that can produce and consume multiple HTTP connections at a time (Figure 1). For each HTTP connection, PackMimeHTTP creates (or allocates from the inactive pool, as described below) server and client Applications and their associated TCP Agents. After setting up and starting each connection, PackMimeHTTP sets a timer to expire when the next new connection should begin. The time between new connections is governed by the connection rate parameter supplied by the user. New connections are started according to the connection arrival times without regard to the completion of previous requests, but a new request between the same client and server pair (as with HTTP 1.1) begins only after the previous request-response pair has been completed.

PackMimeHTTP handles the re-use of Applications and Agents that have completed their data transfer. There are 5 pools used to maintain Applications and Agents -- one pool for inactive TCP Agents and one pool each for active and inactive client and server Applications. The pools for active Applications ensure that all active Applications are destroyed when the simulation is finished. Active TCP Agents do not need to be placed in a pool beacuse each active Application contains a pointer to its associated TCP Agent. New objects are only created when there are no Agents or Applications available in the inactive pools.

PackMimeHTTP Client Application

Each PackMimeHTTP client controls the HTTP request sizes that are transferred. The client is started when a new TCP connection is started. Each PackMimeHTTP client takes the following steps:

PackMimeHTTP Server Application

Each web server controls the response sizes that are transferred. The server is started by when a new TCP connection is started. Each PackMimeHTTP client takes the following steps:

PackMimeHTTP Random Variables

This implementation of PackMimeHTTP provides several ns RandomVariable objects for specifying distributions of PackMimeHTTP connection variables. The implementations were taked from source code provided by Bell Labs and modified to fit into the ns RandomVariable framework. This allows PackMimeHTTP connection variables to be specified by any type of ns RandomVariable, which now include PackMimeHTTP-specific random variables. The PackMimeHTTP-specific random variable syntax for TCL scripts is as follows:

PackMimeHTTP TCL Commands

PackMimeHTTP takes several commands that can be specified in the TCL simulation script:

Choosing the TCP Type

The default TCP type for PackMimeHTTP is TCP Reno, but can be changed (though, it's not as straight-forward as it should be). Before you create the PackMimeHTTP instance in your TCL script, create a global hash variable named opts:

global opts

Then, set the tcp key of opts to be the desired TCP variant (Newreno for TCP NewReno and Sack for TCP SACK):

# sets TCP type for all PackMimeHTTP connections to TCP NewReno
set opts(tcp) "Newreno"
The code that creates the TCP agents used in PackMimeHTTP can be found in the alloc-tcp function in tcl/packmime/packmime.tcl.

Use of DelayBox

Figure 2: Example Topology Using PackMimeHTTP and DelayBox. The cloud of web clients is a single ns node, and the cloud of web servers is a single ns node. Each of the DelayBox nodes is a single ns node.

PackMimeHTTP uses ns to model the TCP-level interaction between web clients and servers on the simulated link. To simulate network-level effects of HTTP transfer through the clouds, we implemented a new ns module called DelayBox. DelayBox is an ns analog to dummynet, often used in network testbeds to delay and drop packets. The transit times model cloud propagation and queuing delay. Since all HTTP connections in PackMimeHTTP take place between only two ns nodes, there had to be an ns object to delay packets in each flow, rather than just having a static delay on the link between the two nodes. DelayBox also models bottleneck links and packet loss on an individual connection basis. Two DelayBox nodes are used as shown in Figure 2. One node is placed in front of the web client cloud ns node to handle client-side delays, loss, and bottleneck links. The other DelayBox node is placed in front of the web server cloud ns node to handle the server-side delays, loss, and bottleneck links.

Change Log

Sep 8, 2005 June 11, 2005 June 6, 2005 May 26, 2005 July 26, 2004 May 20, 2004 May 7, 2004 Apr 13, 2004 Feb 17, 2004

Copyright Statement

Copyright 2002, Statistics Research, Bell Labs, Lucent Technologies and the University of North Carolina at Chapel Hill.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
  2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
  3. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Contacts: Michele Weigle (mcweigle@cs.unc.edu), Kevin Jeffay (jeffay@cs.unc.edu)


Michele C. Weigle

Home | Reference Installation Sample TCL Scripts Implementation Details Change Log Copyright Statement