Lab1

pdf

School

Georgia Institute Of Technology *

*We aren’t endorsed by this school

Course

6110

Subject

Computer Science

Date

Feb 20, 2024

Type

pdf

Pages

4

Uploaded by EarlKnowledge13348

Report
ECE 6110 Lab Assignment 1: Topologies, Logging, and PCAP Tracing Due: Friday, Feb. 2, 11:55 PM Before starting the assignment, you should download the latest version of ns-3 (at the time of this lab creation, ns-3.40) from https://www.nsnam.org/ and go through the ns-3 tutorial beginning with “Getting Started” (Section 4) and ending with “Building a Bus Network Topology” (Section 7.1). These sections take you step-by-step through the process of downloading and installing ns-3 and then provide the concepts you will need to complete this assignment. Note: Windows users should first install VirtualBox and Linux prior to installing ns-3. Note on Random Numbers in ns-3: In ns-3, start times for different applications are typically chosen randomly to prevent lots of simulation events with the exact same start time. Using the instruction “RngSeedManager::SetSeed()”, set the seed for the random number generator at the beginning of each of your programs to “123456789”. This avoids the default seed value, which can cause the generator to take some time before it begins generating a good random sequence. In Part 1, you will be required to choose start times from a Uniform random variable distribution. Make sure to use ns-3’s built-in random numbers to do this via the ns3::UniformRandomVariable class. Do not use another library to generate random numbers such as rand() or drand48() from built-in C libraries. A good description of random numbers in ns-3 can be found at: https://www.nsnam.org/docs/manual/html/random-variables.html Turn-in Instructions: Create a separate folder for each part of the assignment inside a main folder named “Lab1_<your_last_name>_<your_first_name>”. Then create a single tarball of the main folder and all of its subfolders and submit it in Canvas. Important programming instructions: All code must be hand typed in your editor of choice. No auto- formatting is allowed to change the text that you type in manually. Also, make sure to use the exact program name and command-line parameter names specified in each part. You will get points deducted if you do not follow these instructions even if your code is functionally correct!! Part 1a: Working with Point-to-Point Links with UdpEchoClient() and UdpEchoServer() In this part, you will modify the first.cc example from the “Conceptual Overview” section of the tutorial. You will create multiple client nodes that connect to the server according to a specific topology. This topology has 1 client connecting directly to the server and 1 client connecting to the server through k relay nodes. An example of the topology with k = 2 is shown below. All links in the topology are point-to- point links. // // c1 // // | // | 10.1.4.0 // | // 10.1.3.0 10.1.2.0 // relay -------------- relay -------------- server // // | // | 10.1.1.0 // | // // c0 //
The number of relays, k , the number of packets sent by each client, the packet interval, the packet size, the link data rate, and the link delay should all be settable through command-line parameters with default values of 1 relay, 1 packet per client, 1 second interval, 1024-byte packet size, 5 Mbps link data rate, and 2 ms link delay. Name your program “lab1-part1a.cc” and name the command line parameters “nRelays”, “nPackets”, “interval”, “packetSize”, “dataRate”, and “delay”. Important notes: 1. The clients’ requests should all be sent to the same IP address, which should be the server’s address on the 10.1.1.x subnet. Since there are different subnets in the topology, this will require the use of a concept introduced later in the ns-3 tutorial (in the second.cc example) to make sure that the requests from client c0 reach the server. 2. How to set up and use command-line parameters are introduced in the second.cc example and also illustrated in first_enhanced.cc available on Canvas. 3. Set the start times for the UdpEchoClient apps on the two clients to be different random times between 2 and 6 seconds. (Don’t forget to initialize the random number generator with a seed of “123456789”.) Set the stop time for the UdpEchoClient apps, the UdpEchoServer app, and the simulation to 20 seconds. 4. Use the SetAttribute() method to change the port number for the UdpEchoServer app to 25. First, test your program thoroughly with different values of command-line parameters. Next, run your program with from 1 to 5 relay nodes, with 256-byte and 1024-byte packets, 5 Mbps and 10 Mbps link data rates, and with default values for all other parameters and do the following: 1. Record the round-trip delays for client c1 for the 20 different parameter combinations. The round-trip delay on a client is the time between the client sending its UdpEchoClient() request and the client receiving the reply back from the UdpEchoServer(). 2. Write an equation for the round-trip delay for client c1 in terms of the relevant parameters. Justify why your equation is correct. 3. Create a table showing c1’s round-trip delay vs. the number of relays, both measured in ns-3 and from your equation. The 5 rows of the table should correspond to the different number of relays and you should have columns for each of the 4 combinations of other parameters showing measured and theoretical values out to 5 decimal places. Part 1b: Working with Point-to-Point Links with Ping Application and ICMP ping is a standard Internet application that contacts an Internet host based on its host name or IP address using the ICMP protocol. When receiving a ping request, any Internet host will respond to the requesting client similarly to how the UdpEchoServer application behaves. In this part, you will replace the UdpEchoClient application with a ping application. Note that the server in this part does not need to run any application – as long as it has an Internet stack installed on it, it will respond to ICMP queries from the clients. Keep your program from Part 1a as it is except for replacing the UdpEchoClient application with ns3’s Ping application and removing the UdpEchoServer application from the server. Also, there is no need to have nPackets and packetSize parameters in this part. However, keep the interval attribute – it is named and set similarly for ping applications as it was for UdpEchoClient applications. Have the Ping applications on the two clients start at random times and stop at 20 seconds, just as in Part 1a. For information on how to use the Ping application, look at the program: src/csma/examples/csma-ping.cc Where this program creates a log entry with the string “Create pinger”, you will see an example of creating a Ping application to ping a certain remote host and installing the application on several nodes. Since logging is not enabled in the code for the ping application, you will not see output messages as you
did with the first.cc code with the UdpEchoClient and UdpEchoServer applications. Enable pcap tracing for the nodes in your simulation (see second.cc for how to do this) to help you observe the results. Name your program “lab1-part1b.cc” and name the command line parameters “nRelays”, “interval”, “dataRate”, and “delay”. Question to answer for this part: 1. How do the round-trip delays for client c1’s ping requests compare to those you saw in Part 1 with UdpEchoClient and UdpEcho Server? What is the reason for this difference? Note: To observe the round-trip delays, view the pcap file associated with client c1. Part 1 Turn-in instructions: In your Part 1a subfolder, include the following items: source code of your program for Part 1a, a screen shot showing the command line and output for your Part 1a program with nRelays=3, nPackets=2, interval=2.0, and default values for all other parameters, your equation for c1’s round-trip delay with justification, and the table discussed at the end of the Part 1a instructions with discussion of discrepancies between measured and theoretical values, if any In your Part1b subfolder, include the following items: source code of your program for Part 1b, pcap files for your program with nRelays=2, interval=5.0, and default values for all other parameters, and answer to why c1’s delay is different in Part 1b compared to Part 1a with the same parameter values Part 2: Working with an Ethernet Network In this part, you will modify the example (second.cc) described in the “Building a Bus Network Topology” section of the tutorial. You will use the Ping application with the same parameters as in Part 1b instead of the UdpEchoClient and UdpEchoServer applications. Also, you will replace the single point-to-point link connecting n0 and n1 with the relay set-up from Part 1a. An example of the network topology with 4 CSMA nodes (nCsma= 3 “extra” nodes) and 2 relay nodes is shown below, where n0 is the Ping client and n4 is the remote host that is “pinged” by n0. // // n0 // // | // | 10.1.4.0 // | // 10.1.3.0 10.1.2.0 // relay -------------- relay -------------- n1 // | // | // LAN 10.1.1.0 | // ================= // | | | // n4 n3 n2 //
Your preview ends here
Eager to read complete document? Join bartleby learn and gain access to the full version
  • Access to all documents
  • Unlimited textbook solutions
  • 24/7 expert homework help
Name your program “lab1-part2.cc” and name the command-line parameters “nRelays”, “nCsma”, and “interval”. Default values for these parameters should be 1 relay, 3 extra CSMA nodes, and an interval of 5.0 seconds. For this part, you can just hard code the default values from Part 1 for point-to-point link data rate and delay and from second.cc for csma data rate and delay. Set the Ping application stop time to 20 seconds as in Part 1. Important note: Since there is only one client here, there is no need to randomize its start time. It can be fixed at 2.0 seconds, as in second.cc. For a run with 3 relays, 5 CSMA nodes (4 “extra” nodes), and an interval of 4 seconds, plot the round-trip delay of a request-response pair vs. the request number for your modified topology (with the given parameters, this should give you 5 data points). Answer the following questions related to the delays. You will need to do some analysis of the PCAP files to answer these questions. Collect the same PCAP files as in the original second.cc program and any additional ones you need to help you answer these questions: 1. If your program is running correctly, you should notice that the round-trip delay for the first request-response is significantly longer than the subsequent ones. Looking carefully through the relevant PCAP files, state where the extra delay is coming from and what network protocol seems to be causing it. 2. When you have identified the network protocol responsible for the extra delay, figure out how to log the behavior of that protocol and highlight where the extra delay occurs in the logged output. Indicate the reason for the delay - be as specific as you can about the reason. Turn-in instructions: In your Part 2 subfolder, include the source code of your program with the modified topology and the following: a screen shot showing the command line and output for your program with the parameter values used to generate the delay analysis (turn on logging for Ping and set the prefix_time bit to see some output with simulation times), all PCAP files that you captured for the same case (at a minimum, the 3 PCAPs captured by the original second.cc program), the end-to-end delay vs. packet number plot detailed above, the answer to Question 1 above, and a text file showing the command line and output for your program with the network protocol causing extra delay logged (output may be too long for a screen shot); highlight the extra delay in the logged output and annotate the file with the reason for the delay being as specific as you can.