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.
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:
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.
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)
Home | | | Installation | Sample TCL Scripts | Implementation Details | Change Log | Copyright Statement |