This lab has only been tested on NS2 version 2.29.3 using the Miracle framework installed. You can find the Miracle framework here. This lab is a work in progress. The code and scripts are not available yet.
Speaking generally, to simplify any problem, we try first to break it into smaller parts. By doing this, we may be able to solve each part independently. Then, we can put them back together and we have solved the complex problem. You could call this "modularizing" the problem. This is the same approach that networking takes. Networking is very complex in implementation, and thus a modular approach is taken. Two of the main "models" are shown below in Figure 1. We will concentrate on the TCP/IP model, which treats the Application, Session, and Presentation modules (or layers) of the OSI model as one layer, which they denote as the Application layer.
In this lab, we are going to insert a traffic controller into the Transport layer. The Transport layer is mostly used to provide a end-to-end connection for traffic flows. The Transport layer includes such things as quality of service, congestion and flow control. Our transport layer is going to be very simple. In order to avoid application layer packets from being discarded (dropped), we are going to make a transport layer which tells the application layer to slow down when our queue is about to be full and speed up when it is about empty. In this lab, the queue mentioned is the queue at the Data Link level. Packets being sent down from the application layer AND packets being forwarded for other nodes get queued at the Data Link Layer. They are queued here until the channel becomes idol.
Specifically, we will be updating the application rate according to the equation: R[t+1] = R[t] + alpha*(q_th - q[t]), where R[t] is the application rate at time t, alpha is a user-defined constant which controls the rate of change, q_th is a user-defined queue threshold that the user wants the queue to settle around, and q[t] is the queue size at the link layer at time t.
The scenario will be as follows: A-->B-->C, where A, B, and C are nodes and B is the node which we will be controlling. So, B will be both sending its own packets to C and also be forwarding packets for A. From 0-5 seconds, A will be sending at R1, then from 5-10 sec., A will stop sending, then from 10-15, A will start sending again at rate R2.
appcontrol.tcl -alpha- -q_thresh- -q_max-
The restrictions on the inputs above are: alpha, q_thresh, q_max > 0; q_max > q_thresh.
1. Explain any trend that you see in the two sets of plots, queue and throughput?
2. How does the alpha paramter effect the queue?
3. How does the q_threshold parameter effect the queue?
4. In what type of application might this controller be a good thing? bad thing?
1. Know ns2
2. Schiller, Joschen. "Mobile Communications"