Home | Installation Sample TCL Scripts Implementation Details Change Log Copyright Statement
Per-Flow Delay and Loss in NS-2 with DelayBox

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).


DelayBox is an ns node that should be placed in between the source and destination nodes. With Delaybox, packets from a flow can be delayed, dropped, and/or forced through a bottleneck link before being passed on to the next node. A distribution can be used to specify delay, loss, and/or bottleneck link speed for a source - destination pair. Each flow between that source - destination pair draws from the distribution to determine its characteristics. Delays in DelayBox are per-flow, rather than per-packet. Since DelayBox distinguishes between flows, the fid_ variable (flow identifier) should be set for each flow in the simulation.

Installation (Last modified June 11, 2005)

Note: 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 DelayBox patch.
  1. Download, unzip, and untar DelayBox.tar.gz (contents) into your ns-src directory.
  2. Download the appropriate patch (delaybox-2.28.patch or delaybox-2.27.patch) to your ns-src directory.
  3. Apply the DelayBox patch:
    patch -p0 < delaybox-2.2x.patch
  4. Re-configure and re-make ns: ./configure && make
  5. Run the DelayBox validation scripts:
    From the tcl/test directory, run ./test-all-DelayBox quiet

Sample TCL Scripts

Implementation Details

DelayBox maintains two tables: a rule table and a flow table. Entries in the rule table are added by the user in the TCL simulation script ang give an outline of how flows from a source to a destination should be treated. The fields are source, destination, delay Random Variable (in ms), loss rate Random Variable (in fraction of packets dropped), and bottleneck link speed Random Variable (in Mbps). The loss and bottleneck link speed fields are optional. Entries in the flow table are created internally and specify exactly how each flow should be handled. Its values are obtained by sampling from the distributions given in the rule table. The fields are source, destination, flow id, delay, loss, and bottleneck link speed. Full-TCP flows are defined as beginning at the receipt of the first SYN of a new flow ID and ending after the sending of the first FIN. Packets after the first FIN are forwarded immediately (i.e., they are neither delayed nor dropped by DelayBox). For TcpAgent, flows are defined as beginning at the receipt of the first 40 byte packet of a new flow ID. Since there are no FIN packets in TcpAgent, TcpAgent flows are never considered finished nor are they removed from the flow table.

DelayBox also maintains a set of queues to handle delaying packets. There is one queue per entry in the flow table. These queues are implemented as delta queues, in that the time to transfer the packet is kept only for the head packet. All other packets are stored with the difference between the time they should be transferred and the time the previous packet should be transferred. The actual time the previous packet should be transferred is stored in the variable deltasum_, named so because it is the sum of all delta values in the queue (including the head packet's transfer time). If the bottleneck link speed has been specified for the flow, a processing delay is computed for each packet by dividing the size of the packet by the flow's bottleneck link speed.

When a packet is received, its transfer time (current time + delay) is calculated. (This transfer time is the time that the first bit of the packet will begin transfer. Packets that wait in the queue behind this packet must be delayed by the amount of time to transfer all bits of the packet over the bottleneck link.) There are two scenarios to consider in deciding how to set the packet's delta:

  1. If the packet is due to be transferred before the last bit of the last packet in the queue, its delta (the time between transferring the previous packet and transferring this packet) is set to the previous packet's processing delay. This packet has to queue behind the previous packet, but will be ready to be transmitted as soon as the previous packet has completed its transfer.
  2. If the packet is due to be transferred after the last bit of the last packet in the queue, its delta is difference between this packet's transfer time and the previous packet's transfer time.

If the current packet is the only packet in the queue, DelayBox schedules a timer for the receipt of the packet. When this timer expires, DelayBox will pass the packet on to the standard packet forwarder for processing. Once a packet has been passed up, DelayBox will look for the next packet in the queue to be processed and schedule a timer for its transfer. All packets, both data and ACKs, are delayed in this manner.

Packets that should be dropped are neither queued nor passed on. All packets in a queue are from the same connection and are delayed the same amount (except for delays due to packet size) and are dropped with the same probability.

DelayBox TCL Commands

DelayBox takes several commaonds that can be specified in the TCL simulation script:

Change Log

June 11, 2005 June 6, 2005 May 26, 2005 May 4, 2004 Apr 15, 2004 Feb 17, 2004

Copyright Statement

Copyright 2002, 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 | Installation Sample TCL Scripts Implementation Details Change Log Copyright Statement