Lab 2: Transport Layer · 2019-10-17 · LAB 2: TRANSPORT LAYER 2. Verify that the Netgear switches inside the rack display the numbers 1 and 2. 3. Turn on (Restart if it is already

LAB 2: TRANSPORT LAYER

Lab 2: Transport Layer ObjectiveIn this lab, you will continue to use Wireshark, but now you will explore the transport layer. You will examine various UDP and TCP transmissions and analyze them under various conditions. Once again, you will use the hardware network testbed, which will create the traffic that you will observe. Write a report, to show you have executed the lab procedures. In this report, also answer any questions that are interleaved among the procedures. Feel free to also include questions, ponderings, and any interesting stuff you observed.

Procedures1. Verify that the power switch 9 (on the power rail behind the rack) is turned on. If not, turn it

on and wait about 5 minutes before proceeding with the next step.

PAGE OF VERSION 1.0.31 7


2. Verify that the Netgear switches inside the rack display the numbers 1 and 2.

3. Turn on (Restart if it is already on) the PC by powering on switch 8. 4. Make sure the keyboard is on (switch is located on the right side of the keyboard). 5. Login to the PC with the credentials you submitted on the Google Form. 6. If power switch 2 is ON, turn it OFF and wait for 3 seconds (Static charge can keep the

device on for a second or 2). 7. Turn on the power switch 2 and wait up to 3 minutes for the hosts to boot up. Sorry, but

one of the servers takes a while. 8. Open Lab 2 on the desktop and make sure that status line in the bottom reads “Status: All

hosts are up,'' If not wait for a few more seconds and reopen Lab 2. 9. Repeat steps 6-8 if any hosts are still down. 10. Connect the blue Ethernet cable to your laptop and start Wireshark. 11. When you are done with the lab, shut down the computer and turn off all the power

switches EXCEPT 9!



The User InterfaceFor this Lab, the custom-built application is different from Lab 1. See the screenshot below. The Lab 2 application mostly has a bunch of buttons that you will press during each part of the Lab. Each button will cause some traffic to be generated, which you will observe using Wireshark. There is also a slider on the second row, that will control packet loss in the network. Be careful that you only apply loss when specified in this handout. The last button, labeled "Start Censor" is for Part 4.

Part 1: A Basic TCP StreamLet’s begin our exploration of the transport layer by creating similar traffic to our Lab 1 HTTP connections, but we will examine what is happening with TCP this time. We will use HTTP to request a web object (a file containing an RFC), so a single HTTP request and reply. Do the following:

• Start up the Wireshark packet sniffer, as as you've done so many times before, on an Ethernet connection. I'm not going to tell you what capture filters or display filters to use -- you are now experienced Wiresharkers. Do whatever you need in order to examine this traffic. But, keep in mind that we are interested in the Transport layer, not the Application layer.

• Using the Lab2 interface, click the "Open RFC" button. • Wait for the resulting pop-up window to load completely. • Stop Wireshark packet capture and save the PCAP file.

Answer the following questions: 1. What is the IP address and TCP port number used by the client (i.e. the Lab 2 Application)

to transfer the file? What is the IP address of the server? On what port number is the server sending and receiving TCP segments for this transfer of the file? Does the server port number match your expectations? What about the client port number?

2. What are the sequence and acknowledgment numbers of segments used to initiate the TCP connection (the "3-way Handshake")? What are different flag set to indicate each part of the



handshake? Do these initial segments match your expectations? Make sure to describe how you got your data. Wireshark uses relative sequence numbers by default. Can you obtain absolute sequence numbers instead to answer this question? How? You may use relative sequence numbers to answer the remaining questions.

3. Consider the TCP segment containing the HTTP GET as the first segment in the non-overhead part of the TCP connection. For the segments which follow, put together a table with one row per segment (and columns for whatever data you think is useful) until you have enough segments to calculate four SampleRTT values according to the RTT estimation techniques discussed in class. Calculate what those SampleRTT values are, as well as the EstimatedRTT after each Sample is collected. Discuss this calculation, including what your initial EstimatedRTT was, your choice of parameters, and any segments that weren’t used in the calculation.Note: Wireshark has a nice feature that allows you to plot the RTT for each of the TCP segments sent. Select a TCP segment in the “listing of captured packets” window that is being sent from the client to the server. Then select: Statistics ➙ TCP Stream Graph ➙ Round Trip Time Graph.

4. What is the minimum amount of available buffer space advertised at the receiver for the entire trace? Does the lack of receiver buffer space ever throttle the sender?

5. How much data does the receiver typically acknowledge in an ACK? Can you identify cases where the receiver is delayed ACKing segments? Explain how or why not.

Part 2: TCP vs UDPIn this section, you will transfer an image twice, once using TCP and once using UDP. You will then compare and explain the differences. The capture for this part can only be done on the NUC (i.e. the Windows computer in the rack) due to MTU and other complications. Use Wireshark on the NUC to examine traffic and capture PCAP files. You may then use the extension USB port (next to the camera) to transfer your files from the NUC to a USB flash drive (you need to supply this). Make sure to fully delete your PCAP files, as you wouldn't want to get involved in an AIV case if someone else picks them up and uses them. Note: You should only use Wireshark on the NUC for questions 7-11. The NUC's promiscuous mode isn't as reliable as the switch tap (i.e. the Ethernet wire) and you might/will miss some critical packets. All other questions MUST be answered from your laptop. Do the following:

• Start up Wireshark packet capture on the NUC. Remember that you want to be able to see UDP and TCP segments.

• On the Lab 2 Application, click the "Download Image" button. • An image will be displayed twice, once via a UDP transfer and once via a TCP.



• Stop Wireshark packet capture and save the PCAP file. Transfer the PCAP file to your laptop and delete it from the NUC.

Answer the following questions: 6. Measure the time and number of bytes needed to transfer the image using TCP and

(separately) using UDP. Note that it will probably take more bytes than just the size of the image file.

Let's see what happens when the network loses some packets. Continue by doing the following: • Start up Wireshark packet capture on the NUC. • On the Lab 2 Application, change the packet loss slider to a value greater than zero, ensure

the drop down next to the slider says "Packet loss on stream," and click "Apply" • Click the "Download Image" button again and wait for two images to be displayed. • Repeat the download with some other packet loss value. Note that at very high packet loss

rates, the UDP image might not load at all. In such a case, reduce the packet loss rate. You want to see the images transfer.

• Stop Wireshark packet capture and save/transfer/delete the PCAP file. 7. What did you see? Indicate the time and number of bytes needed to transfer the image using

TCP and using UDP for the two different packet loss values. 8. Are there any retransmitted segments? What did you check for (in the trace) in order to

answer this question? 9. How many segments were sent in each case? Explain your data, as best as you can, for these

three questions? What if the scenario was a live stream, rather than an image download? Let's find out. Continue by doing the following:

• Start up Wireshark packet capture on the NUC. • Open the camera blind on the webcam. • Start with a zero percent packet loss (make sure to click the "Apply" button). • Click the "Start Video Stream" button in the Lab 2 Application. You should see two small

windows displaying the camera feed. • Pop a dance move or wave your arms around. • Gradually increase packet loss and observe how the video streams behave. Note that you

have to hit the "Apply" button to activate any changes. • Stop Wireshark packet capture and save/transfer/delete the PCAP file.

Note: The UDP stream behaves erratically due to some programming issues. More than the quality of the image, you’re looking for which one gets stuck more often. You could assume we had cool software that would make the stream coming through stable, or even better, feel free to try and improve the program for some extra credit.



10. How does the TCP and UDP video stream change as you vary the packet loss slider for both TCP and UDP connections? At high packet loss, did either of the streams stop? Why do you think that happened?

11. Now you have analyzed both Image download and Video stream services, comment on the overall performance of TCP and UDP for both the scenarios. Which of the two protocols would you pick for your favorite online activities and why? Make sure to comment on any other observations you have.

Part 3: Congestion ControlCongestion control is a very important part of the TCP protocol. Let's take this opportunity to explore and compare various algorithms. To generate TCP traffic, we will be using a program called iperf (check out the man page, it does cool stuff). We use iperf to create multiple TCP connections to ports 20000, 30000 and 40000. On each port, two TCP connections are started. The first is mostly ignorable, though if you dig through it, you will find out which algorithm is used for each port (hmm. That sounds useful). The second connection is the one we are interested in, as it probes for bandwidth. Wireshark's TCP stream filters may be very useful for this section. Do the following:

• Start up Wireshark on your laptop, not the NUC. • Click the "Run IPERF test" button. • Wait for a few seconds. • Stop Wireshark packet capture and save the PCAP file.

Answer the following questions: 12. Which congestion control algorithm is used on each port. Do I need to remind you to justify

your answers with annotated screenshots, calculations or detailed descriptions? Of course not, as you're doing that for every question in the lab, right?

13. What average throughput did each connection achieve? 14. Use the Time-Sequence-Graph(Stevens) plotting tool to view the sequence number

versus time plot of segments being sent. If possible for each stream, identify where TCP’s slow start phase (if any) begins and ends, where congestion avoidance takes over, response to losses and any other similar changes.

Now, lets introduce some packet loss at the network layer. Do the following: • Change the dropdown next to the slider to “Packet loss on IPERF”. Pick a value and

hit the "Apply" button. • Use Wireshark to measure the results as you run the IPERF test for at least 5

different packet loss values.



Answer the following questions: 15. Plot the relationship between packet loss and the percentage of maximum

throughput achieved by each congestion control algorithm (Use the sum of the throughputs from 0% packet loss as maximum)? Who is the fairest of them all?

Part 4: On Path CensorsLet's examine the behavior of another network bad actor and see if you can determine how an attack is carried out.

• Start up Wireshark. • In the Lab2 Application, click the "Start Censor" button • Wait for several seconds for it to start the script. • Try to open the RFC you opened in Part 1. • Stop Wireshark packet capture and save the PCAP file.

Answer the following question: 16. The attacker is similar to the attacker from Lab 1, but doing so by manipulating the TCP

state. To effectively block the connection to the RFC website, what flags and fields in TCP did the attacker have to set? Hint: The attacker spoofs IP addresses, but all the reset segments are from the attacker. Take a close look at the TCP trace and report on anything else you found interesting. Just think, if someone on your network doesn’t want you to read the “RFC”, it is pretty easy for them to stop you.

Turn-inWrite a report of your interactions and answering the questions. Make sure to include enough details to ensure we understand that you understand what is going on. For instance, screenshots should probably be annotated to show where a number came from -- don't assume that because you know how to read a Wireshark screen that we know that you know it. Our graders will not make that assumption. So, prove it to us by describing/annotating every value you find from Wireshark.Turn in your answers in a single PDF file and submit it to the Lab2 “Assignment” on Gradescope.Mark the pages according to the question. Students who fail to mark a question correctly will lose all the points for that question.Save your PCAP files.


Documents

Lab 2: Transport Layer · 2019-10-17 · LAB 2: TRANSPORT LAYER 2. Verify that the Netgear switches inside the rack display the numbers 1 and 2. 3. Turn on (Restart if it is already