Below are the steps that you are going to take.
NOTE 1: ns-2 is written in C++ and Otcl: C++ is used for implementing the bulk of the simulator, such as traffic sources, routing, scheduling disciplines, while Otcl is in general used for configuring and setting simulations. As a result you have to also download Tcl, Tk, Otcl, and TclCL (this is automatically done when you select all at once option). Since the simulator is quite large (tens of MB), you may want to install it on your local disk. Finally, if you have a choice of the operating system, we recommend you to use Linux or FreeBSD, as these are the main OSes used by ns-2 development teams.
NOTE 2: There are excellent documentations on-line. For a quick start refer to the manual page and Marc Greis' tutorial web pages. For details consult ns Notes and Documentation. All these documents are accessible from the main page.
make depend make
In both simulation scenarios, we consider a TCP flow and an UDP flow (sending at 1 Mbps) sharing a 1.5 Mbps link. Both flows use 1000 bytes packets. In both cases the simulation duration is 10 sec.
NOTE: At this point you are ready to run the simulation by using
../ns rr.tclAs a result you obtain a trace file out.tr that contains all events (e.g., packet arrivals, departures, and drops) on the shared link.
Next are some utility programs that help you to parse out.tr and create plots by using gnuplot.
run-examplesAs a result you should get two postscript files that plots the bandwidth versus time for the two simulation scenarios: rr.ps and DropTail.ps.
With WF2Q+, each flow is associated a weight, such that the sum of the weights of all flows is no larger than a predefined value W, i.e., if there are n flows, then
weight[1] + weight[2] + ... + weight[n] <= WA flow's weight specifies how much share of the capacity of the output link a flow is entitled to receive. For example, if one flow has weight 1, and another flow has weight 2, then the second flow will get twice as much bandwidth as the first flow.
Each flow i is associated two variables S[i] and F[i] that represent the starting time and the finishing time of the packet at the head of the queue of flow i.
Finally, a global variable V, called system virtual time, is associated to the system.
The WF2Q+ can be then described as follows:
Initialization Set all variable: V, S[i], and F[i], for all flows i, to 0.
Enqueue Assume packet p of flow i arrives. Then execute the following pseudocode:
if (queue[i] == empty) { enqueue(p, queue[i]); // compute starting and finishing times for // packet at the head of the queue of flow i S[i] = max(V, F[i]); F[i] = S[i] + length(p) / weight[i]; // update system virtual time V = max(min_{j}(S[j]), V); } else enqueue(p, queue[i]);where min_{j}(S[j]) represents the minimum of starting times among all backlogged flows. A flow is called backlogged if it has at least one packet in the queue.
Dequeue Consider the set S of all backlogged flows, such that their starting times are no larger than the system virtual time V, i.e., S[j] <= V, for any flow j in S. Then select the flow i in S that has the minimum finishing time F[i]. Finally, execute the following pseudocode:
p0 = dequeue(queue[i]); // dequeue and transmit the packet send(p0); p = head(queue[i]); // get packet at the head of the queue, if any if (p) { S[i] = F[i]; F[i] = S[i] + length(p) / weight[i]; } // update system virtual time V = max(min_{j}(S[j]), V + length(p0)/W);NOTE: If W = C, where C represents the link capacity, then the weight of a flow represents the minimum bandwidth that the flow is guaranteed to receive.
your_login.hmwk.txtcontaining the answers to the two questions at point 3, and to the first question at point 5.
your_login.hmwk.plot.ps
your_login.hmwk.wf2q+.cc
your_login.hmwk.wf2q+.tcl