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)
Stochastic
Models for Generating Synthetic HTTP Source Traffic
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.
Reference
The PackMime HTTP traffic model is described in detail in the following paper:
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.
patch -p0 < packmime-delaybox-2.2x.patch
Sample TCL Scripts
- test-packmime-delaybox - tcsh script for running test-packmime-delaybox.tcl
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.
Connection Variables
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.
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.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
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)
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.
Michele C. Weigle
Home | | | Reference | Installation | Sample TCL Scripts | Implementation Details | Change Log | Copyright Statement |