We want to build a multimedia application that runs over a UDP connection, which simulates the behavior of an imaginary multimedia application that implements "five rate media scaling" that can respond to network congestion to some extent by changing encoding and transmission policy pairs associated with scale parameter values.
In this implementation, it is assumed that when a connection is established, the sender and the receiver agree on 5 different sets of encoding and transmission policy pairs, and associate them with 5 scale values (0-4). For simplicity reasons, it is also assumed that a constant transmission rate is determined for each of the encoding and transmission policy pairs, and every pair uses packets of the same size regardless of the encoding scheme.
Basically, "five rate media scaling" works as follow. The sender starts with transmission rate associated with scale 0, and changes transmission rates according to the scale value that the receiver notifies. The receiver is responsible for monitoring network congestion and determining the scale factor. For congestion monitoring, a simple periodical (for every RTT second) packet loss monitoring is used, and even a single packet loss for each period is regarded as network congestion. If congestion is detected, the receiver reduces the scale parameter value to half and notifies the sender of this value. If no packet loss is detected, the receiver increases the value by one and notifies the sender.
Before implementing this application, the UDP agent implementation is examined and one major problem is found. Since a UDP agent allocates and sends network packets, all the information needed for application level communication should be handed to the UDP agent as a data stream. However, the UDP implementation allocates packets that only have a header stack. Therefore, we need to modify the UDP implementation to add a mechanism to send the data received from the application. It is also noted that we might want to use this application for further research on IP router queue management mechanisms. Therefore, we need a way to distinguish this type of multimedia stream from other types of streams. That is, we also need to modify UDP agent to record data type in one of IP header fields that is currently not used.
The locations of C++ source files in NS version 2.1b9a are slightly changed from 2.1b8a. In ns-2.1b9a, C++ source files are categorized and placed in sub-directories under the main ns-2 directory. For example, "packet.h" to "common/packet.h", "agent.h" to "common/agent.h" and "app.h" is moved to "apps/app.h". However, the locations of OTcl files are same as before ("tcl/lib/ns-packet.tcl", "tcl/lib/ns-default.tcl" and etc.)
For the application, we decided to take the CBR implementation and modify it to have the "five level media scaling" feature. We examined the C++ class hierarchy, and decided to name the class of this application as "MmApp" and implement as a child class of "Application". The matching OTcl hierarchy name is "Application/MmApp". The sender and receiver behavior of the application is implemented together in "MmApp". For the modified UDP agent that supports "MmApp", we decided to name it "UdpMmAgent" and implement it as a child class of "UdpAgent". The matching OTcl hierarchy name is "Agent/UDP/UDPmm"
Figure 23. MM Header Structure & Class (in "udp-mm.h" & "udp-mm.cc")
Figure 24 (a). Add to the "packet.h" file (C++)
We also add lines to packet.h and ns-packet.tcl as shown in Figure 24
(a) and (b) to add our "Mulltimedia" header to the header stack. At
this point, the header creation process is finished, and
"UdpMmAgent" will access the new header via hdr_mm::access() member
function. Please refer to
for detailed information on header creation and access methods.
For the rest of the application and the modified UDP agent description,
refer directly to "mm-app.h",
"udp-mm.cc" files as
Figure 24 (b). Add to the "ns-packet.tcl" file (Otcl)
Before setting this timer, "MmApp" re-calculates the next transmission
time using the transmission rate associated with the current scale
value and the size of application data packet that is given in the
input simulation script (or use the default size). The "MmApp" sender,
when an ACK application packet arrives from the receiver side, updates
the scale parameter.
Figure 25. SendTimer Implementation.
Figure 26 (a). Add two member functions to "Agent" class.
Figure 26 (b). Add a member function to "Application" class.
Figure 27. Default parameter value settings
Here is a checklist that should be done before recompiling your NS.
Be SURE to complete the last (5th) step. Otherwise, all five-scale rates are initialized to zero unless specifically given in the input simulation script (i.e., the test simulation script given below will not transmit any frames).
After you've done all things in the checklist, modify your "Makefile" as needed (include "mm-app.o" and "udp-mm.o" in the object file list) and re-compile your NS. Be SURE to run "make clean" and "make depend" before you re-compile your modified NS, otherwise the new application may not transmit any packets. It is generally a good practice to do "make depend" after you make changes in "Makefile" before a re-compile.
Figure 28 shows a simulation topology and scenario that is used to test "MmApp", and Figure 29 shows the test simulation script. Download this script and test the newly added components.
Figure 28. Test Simulation Topology and Scenario
Figure 29. "MmApp" Test Simulation Script