Wireless Networking Lab 111: Application Control and Queue Management.

NOTES

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.

Introduction

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.

Figure 1: The OSI and TCP/IP stack models. (source)

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.

NS2 Instructions

1. Get the tcl file appcontrol.tcl XXhereXX.
2. The tcl file accepts inputs as follows:
```
	appcontrol.tcl -alpha- -q_thresh- -q_max-
```
The restrictions on the inputs above are: alpha, q_thresh, q_max > 0; q_max > q_thresh.
3. We want to see what is going to happen with different alpha and q_thresh values. So, let's try alpha values (XXX) and q_thresh values (XXX). You will probably want to write a shell script to run these.
4. Get the results. We are interested in the queue and throughput vs time. The following grep commands will obtain the needed stats from the output trace file.
```
	XXX
```
5. Plot the results.

Turn In

Turn in a writeup with the plots and answers to the analysis questions. Expected plots are the (i) Queue size at B versus Time for different alphas (1 plot for each q_thresh) (ii) Throughput for flow A and B versus time for different alphas (1 plot for each q_thresh). Once again, completeness and neatness are stressed.

Analysis

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?

References

1. Know ns2
2. Schiller, Joschen. "Mobile Communications"