Section 1 Short Answer Questions

Transcription

1 CPSC 3600 section 002 HW #1 Fall 2017 Last revision: 9/7/2017 You must work on this homework individually!! Submission: You are to submit your written answers to turnitin. Also, you are to submit your updated UDPEcho.tar.gz using handin. Section 1 Short Answer Questions Question 1.1 List the layers from the OSI seven layer network model that apply in a TCP/IP network. Provide a one sentence summary of each layer in a TCP/IP context. Question 1.2 Assume two nodes communicate directly over a physical layer. Explain the difference between the channel bandwidth and the baud rate in a context where the two nodes communicate directly over a physical layer. Question 1.3 New automobiles sold in the United States will soon be required to support wireless communications using a form of WiFi. There are seven channels available to support vehicle-to-vehicle communications. The bandwidth of each channel is 10Mhz. In the best conditions, it uses a modulation/demodulation based on QAM-64 which uses 64 signal levels per symbol. What is the maximum data rate in these best conditions? Please state any assumptions you might make for your answer. Hint: look up the Nyquist theorem. 1

2 Question 1.4 In a connected vehicle scenario as described in the previous question, applications running on vehicles can chose to use higher order modulation (64QAM) or lower order modulation (BPSK or QPSK). Why might a connected vehicle application transmit application messages using a lower order modulation such as QPSK rather than a higher order modulation (which offers higher data rates than lower modulations) such as 64 QAM? Question 1.5 When transmitting a 32-bit 2 s complement integer in big-endian order, when is the sign bit transmitted (relative to other bits in the 32bit Integer). Please state any assumptions you make. 2

3 Question 1.6 From the kurose text, Review question R12. In the 7 th edition, this question is on page 68 and begins What advantage does a circuit-switched network have Question 1.7 From the Kurose text, review question R13. In the 7 th edition, this question is on page 68 and begins Suppose users share a 2 Mbps link. 3

4 Section 2 Analyzing ping results Use the ping program on your VM with one of the following hosts: or You can use any other host as long as it is located outside of the US (or.to the best of your ability, you think it is located outside the US). Use traceroute or other tools to help estimate the physical location. I ll refer to the destination node as the server. Please do these two parts of this question. Question 2.1 Run ping between your VM and the server for at least 1 hour. Redirect standard output to a file. Do this twice. Once in the evening (normally the Internet s busy time) and once earlier in the day (or late at night). So you will collect two data files: ping1dat and ping2.dat. Ping invocation example (NOTE: this involves a very short path- you are to find/use a path that goes outside the US): ping -D > ping1.dat o Specify the destination address as an IPV4 address in dotted decimal notation. o Specify the D parameter so that a timestamp is appended to each sample Results: o Copy and paste the ping summary statistics to your homework submission. o Copy and paste the results from traceroute to your homework submission. Run traceroute server, if that does not appear to work, try sudo traceroute I server. Cut and paste your results to your homework submission. The purpose is simply to verify that the path between the ping program endpoints appears to be outside the US. Example result traceroute I (Running traceroute does not work- just see wildcards for 64 iterations before giving up). Noteyou can also ask traceroute to show the domain name of each router- this might give further clues as to if the path travels outside the US. traceroute to www1.csc.ncsu.edu ( ), 64 hops max o ms 0.003ms 0.002ms o ms ms ms o ms ms ms o ms ms ms o ms ms ms o ms ms ms o ms ms ms o ms ms ms o ms ms ms o ms ms ms o 11 * * * 4

5 o 12 * * * o ms ms ms We can interpret the traceroute result as follows o There are at least 13 hops between my VM and the server. o Each traceroute line shows the response from the next hop router. By default, traceroute contacts each router (hop by hop) three times. The three times in each line represent the RTT from the three contact attempts with the router. o We do see an increase in the avg RTT as we move further away from the client. Not that sometimes we might see a hop reflect a larger RTT than the next hop router. This usually is due to the fact that some routers handle packets that require special processing (such as when the traceroute client contacts the router) on a low priority basis. Routers typically give priority to forwarding traffic and then respond to IP control/signaling messages such as ICMP or IP options at a lower priority. o The asterisks at hops 11 and 12 are probably due to a firewall rule. Question 2.2. Plot the probability distribution of each data set. There are different ways to do this. You do not need to submit the scripts or tools you used- just document in your HW submission how you did this. Your submission should show each distribution separately (cut and paste the plot or figure of the distribution). One method is: Step 1: Using a script/program, process each ping output data file (ping1.dat and ping2.dat) and create two files that contain two fields: the timestamp and the RTT. Let s refer to these files as RTT1.dat and RTT2.dat. Step 2: We want to plot the distribution of the RTT from each of the reduced data files. You can do this with excel, matlab, R,. o The plotdatapdf.m matlab program will work (link is on our web page). Just make sure the line load RTT1.dat corresponds to the data file. Also make sure the data file is in the same directory as the matlab script. The version of plotdatapdf.m on our web site should be all set to plot the measurement-based distribution in the file RTT1.dat. In a matlab command window plotdatapdf(1,500000,.5) The parameters are: plotmode: value 1 is to plot PDF, maxxvalue sets the max RTT sample to microseconds, maxy sets scale of Y axis to [0,0.50] Results: Include the two plots in your HW submission. Very briefly, interpret the results. In your opinion, what conclusions can you draw from each figure? As best you can, explain any significant differences between the two data sets (based on the visualizations) 5

6 Section 3 Sockets Programming You should get familiar with the UDPEcho program (V1-2 in the code examples). You will be making two functional enhancements to this program. Also, you will be validating these changes. I refer to these two tasks as part 1 (the two functional enhancements) and part 2 (the validation) of this question. Summary of UDPEcho Download the code run the client and server with no parameters to get the usage information. Look over the source code to get familiar with the details. The program is a very is a simple UDP client/server program. It is similar to the ping program, except instead of ICMP it uses the UDP transport protocol. Example usage in the following diagram is the client runs on Host1 and the server runs on Host2. Let s assume the IPv4 address of Host2 is and the server is to use port The client is instructed to use a message size of 1000 bytes and to perform 10 iterations. Host network----- Host2 At Host2, issue:./server At Host1, issue:./client The server parameters: Server side port number Debug Flag - controls the amount of provided by the server. The parameter conveys two logging settings: The 8 th bit of the lowest octet specifies if the server is to log iteration samples to the file EchoServer.dat (a 1 is yes). The lower 7 bits encodes the debuglevel which controls how much tracing information is displayed to standard out. A value of 0 displays errors, a value of 1 displays start and stop information, a value of 2 displays iteration results, and a value of 3 displays debugging information. A setting of 1 or 129 would be typical. The client parameters: Server IPv4 address as a domain name or in dotted quad format Server port : specifies the server port Iteration delay: Number of microseconds between samples Message size: specifies the number of application bytes to place in each message. In order to ensure a message fits in one IP packet, you should assume a message size can not exceed 1472 bytes. Number iterations: specifies the number of iterations (i.e., data samples) to perform (or obtain). Debug Flag - Same as the server parameter except the sample log file is RTT.dat. 6

7 The client sends a message of the given size and then waits for a timeout amount of time for the echo ed message. The client places a sequence number (32 bit unsigned int) in each message, beginning with 0 and incrementing by 1 with each new iteration. The remaining data values are set to zero. If the iteration is successful, the echo ed packet is received by the client host and unblocks the client application with the received message placed in the applications receive buffer (that was passed on the recvfrom call). If the iteration is NOT successful, the client alarm (or timeout) pops which causes the next iteration. The client does not retransmit the data. The client terminates after it completes the desired number of iterations or when a CNT-C is issued. Summary statistics are displayed that include the mean, max, min of the data set. To avoid IP fragmentation, the client message size must be less than a network maximum transmission size (MTU). On an Ethernet or WiFi link, the MTU about 1500 bytes. Therefore, a message size of 1472 will ensure all of the message fits in a single frame. As an example of IP fragmentation, consider a message size of bytes. This produces an IP datagram of bytes (10000 application data but 28 bytes of overhead from IP and UDP). This datagram is broken up into 7 IP packets (which are also called IP fragments). The IP layer at the server Host is responsible for reassembling the IP datagram. If all IP packets arrive, the server side IP layer passes the byte IP datagram to the UDP layer, which then transfers the bytes of data from the datagram into the server application buffer and unblocks the application process (which was blocked on the recevfrom call). The server is very simple. It simply loops forever, receiving a packet and then transmitting the packet back to the sender (i.e., it echoes the received message back to the server). The server can support any number of clients concurrently. However the server currently does not correctly handle statistics when multiple clients are active. As an example, the server assumes packet loss occurs when the next packet that arrives contains a sequence number that is one larger than the sequence number of the previous message. If there is more than one client active at the same time, this method for detecting packet loss will not work. This homework question involves two separate functional changes to the current UDPEcho program. First, you are to modify the server so that it maintains a set of statistics for each client session that it handles. Second, you are to add a new mode of operation to the client and server. Part 1. Functional Enhancements Part 1.1 You are to extend the server so that it tracks maintaining statistics on a per session basis. Let s define a session as a unique combination of client IP address and client port number. Note that one client session might change its port if errors occur. We are 7

8 simplifying the function requirements by having the server not detect a session that involves a client port change. The client code does not change. The server code will maintain a data structure that contains a list of session status. Each session status should contain the following elements: Client IP Client port Creation time Session mode (value 0 is echo mode, value of 1 is CBR mode) Time last message received Total number of messages received Total bytes received Most recent sequence number Count of packets out of order Count of packets dropped When the server terminates, it should print a summary of each session in a file called serverresults.dat. Please use one line per session. Each summary line should include Client IP Client port Duration of session Total number of messages received Count of packets out of order Count of packets dropped Estimate of packet loss rate Throughput (bits per second) The value of the debugflag parameter determines if the client and server are to log samples in a log file (RTT.dat and EchoServer.dat respectively). This change does NOT affect the creation of RTT.dat. For the server, if the 8 th bit of the debugflag is set, it should continue to create entries in the EchoServer.dat file. However, modify the code so it adds the client s IP and port as the first and second fields of each sample logged to file. Part 1.2 You are to add a new operating mode to the tool which we call Constant Bit Rate (CBR) mode In this mode, the client sends fixed size messages at a constant packet rate, approximating a constant bit rate (CBR) traffic generator. The server does NOT send anything back. 8

9 The client program adds a parameter called mode. A value of 0 tells the client to operate in the original echo mode. A value of 1 tells the client to operate in this new mode. If in mode 1 (called CBR mode), there is another additional parameter, the target sending rate. For a message size parameter of M, and a target sending rate parameter or R, the client will send a new packet every R / (M*8) seconds. The client adds the following fields to each message: Sequence number (32 bit unsigned int) Mode : 16 bit unsigned int) In mode 0, when the client terminates, it should display the statistics as described above. In CBR mode, the client should display the duration of the session, the number of packets sent and the actual sending rate (bits per second). The server learns the client session mode through the mode field in the messages. The server maintains the session statistics as described in the previous section. At program termination, the server prints the session summary information in the output file serverresults.dat as previously described. For CBR mode sessions, the client and server should ignore the setting of the 8 th bit of the debugflag and NOT log samples to RTT.dat or EchoServer.dat. Note that the server must support multiple clients that might be in either mode. The client and server should log samples for mode 0 sessions (as described in the previous section). Part 2. Validation You are to conduct an analysis to prove that both added functions to the program works correctly. You should identify a set of test cases that thoroughly tests your design and implementation. Your analysis should include the use of tcpdump or wireshark. I am leaving the details of this up to you. Your writeup should fully document the design, implementation of your code. It should also document the test cases and results. 9