Learning Outcomes
We’ll investigate the behaviour of the TCP protocol in detail by analysing a trace of the TCP segments sent and received in transferring a 150KB file (containing the text of Lewis Carroll’s Alice’s Adventures in Wonderland) from a client (e.g. your computer) to a remote server. We’ll study TCP’s use of sequence and acknowledgement numbers for providing reliable data transfer; we’ll see TCP’s congestion control algorithm – slow start and congestion avoidance – in action; and we’ll look at TCP’s receiver-advertised flow control mechanism. We’ll also briefly consider TCP connection setup and we’ll investigate the performance (throughput and round-trip time) of the TCP connection between your computer and the server.
The Transmission Control Protocol (TCP)
If you are working on your own machine, you can use Wireshark to capture a packet trace of the TCP transfer of a file from your computer to a remote server. You’ll do so by accessing a Web page that will allow you to enter the name of a file stored on your computer (which contains the ASCII text of Alice in Wonderland), and then transfer the file to a Web server using the HTTP POST method. We’re using the POST method rather than the GET method as we’d like to transfer a large amount of data from your computer to the remote server. Do the following (if you are working on your own machine, otherwise skip the steps below):
• Start up your web browser. Go to http://gaia.cs.umass.edu/wiresharklabs/alice.txt and retrieve an ASCII copy of Alice in Wonderland. Store this file somewhere on your computer.
• Next go to http://gaia.cs.umass.edu/wireshark-labs/TCP-wireshark-file1.html
• Use the Browse button in this form to enter the name of the file (full path name) on your computer containing Alice in Wonderland (or do so manually). Don’t yet press the “Upload alice.txt file” button.
• Now start up Wireshark and begin packet capture (Capture->Start) and then press OK on the Wireshark Packet Capture Options screen (we’ll not need to select any options here).
• Returning to your browser, press the “Upload alice.txt file” button to upload the file to the gaia.cs.umass.edu server. Once the file has been uploaded, a short congratulations message will be displayed in your browser window.
• Stop Wireshark packet capture. Your Wireshark window should look similar to the window shown below.
If you are working on a lab machine, you can download tcp-ethereal-trace-1.pcap packet trace (scroll at the end of the document), which was captured while following the steps above.
Before analysing the behaviour of the TCP connection in detail, let’s take a high level view of the trace. First, filter the packets displayed in the Wireshark window by entering “tcp” (lowercase, no quotes, and don’t forget to press return after entering!) into the display filter specification window towards the top of the Wireshark window. What you should see is series of TCP and HTTP messages between the client computer and gaia.cs.umass.edu. You should see the initial three-way handshake containing a SYN message. You should also see an HTTP POST message.
Note: Depending on the version of Wireshark you are using, you might see a series of “HTTP Continuation” messages being sent from your computer to gaia.cs.umass.edu. There is no such thing as an HTTP Continuation message – this is Wireshark’s way of indicating that there are multiple TCP segments being used to carry a single HTTP message. In more recent versions of Wireshark, you’ll see “[TCP segment of a reassembled PDU]” in the Info column of the Wireshark display to indicate that this TCP segment contained data that belonged to an upper layer protocol message (in our case here, HTTP).
You should also see TCP ACK segments being returned from gaia.cs.umass.edu to your computer.
Answer the following questions:
• What is the IP address and TCP port number used by the client computer (source) that is transferring the file to gaia.cs.umass.edu server?
• What is the IP address of the server? On what port number is it sending and receiving TCP segments for this connection?
Since this lab is about TCP rather than HTTP, let’s change Wireshark’s “listing of captured packets” window so that it shows information about the TCP segments containing the HTTP messages, rather than about the HTTP messages. To have Wireshark do this, select Analyze->Enabled Protocols. Then uncheck the HTTP box and select OK. Answer the following questions for the TCP segments:
• What is the sequence number of the TCP SYN segment that is used to initiate the TCP connection between the client computer and gaia.cs.umass.edu? What is it in the segment that identifies the segment as a SYN segment?
• What is the sequence number of the SYNACK segment sent by gaia.cs.umass.edu to the client computer in reply to the SYN? What is the value of the Acknowledgement field in the SYNACK segment? How did gaia.cs.umass.edu determine that value? What is it in the segment that identifies the segment as a SYNACK segment?
Note: Wireshark will show relative sequence and ack numbers in the packets; i.e. numbers that start from 0. To disable this behaviour and see the actual sequence and ack numbers, go to preferences -> protocols -> TCP and disable this feature.
• What is the sequence number of the TCP segment containing the HTTP POST command? Note that in order to find the POST command, you’ll need to dig into the packet content field at the bottom of the Wireshark window, looking for a segment with a “POST” within its DATA field.
• Consider the TCP segment containing the HTTP POST as the first segment in the TCP connection. What are the sequence numbers of the first six segments in the TCP connection (including the segment containing the HTTP POST)? At what time was each segment sent? When was the ACK for each segment received? Given the difference between when each TCP segment was sent, and when its acknowledgement was received, what is the RTT value for each of the six segments?
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 gaia.cs.umass.edu server. Then select: Statistics->TCP Stream Graph->Round Trip Time Graph. If nothing appears on the graph, please change the type to something else and then reselect the Round Trip Time type.
• What is the length of each of the first six TCP segments?
• 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?
• Are there any retransmitted segments in the trace file? Use the ‘Time Sequence (Stevens)’ graph, under Statistics-> TCP Stream Graphs if you don’t want to manually inspect all TCP segments.
• How much data does the receiver typically acknowledge in an ACK? Can you identify cases where the receiver is ACKing every other received segment.
Let’s now examine the amount of data sent per unit time from the client to the server. Rather than (tediously!) calculating this from the raw data in the Wireshark window, we’ll use one of Wireshark’s TCP graphing utilities (‘Time-Sequence-Graph(Stevens) ‘) to plot out data. Select a TCP segment in the Wireshark’s “listing of captured-packets” window. Then select from the menu : Statistics->TCP Stream Graph-> Time-Sequence-Graph(Stevens).
In the plot you see, each dot represents a TCP segment sent, plotting the sequence number of the segment versus the time at which it was sent. Note that a set of dots stacked above each other represents a series of segments that were sent back-to-back by the sender. Answer the following questions:
• Can you identify where TCP’s slow-start phase begins and ends, and where congestion avoidance takes over?
• Comment on ways in which the measured data differs from the idealised behaviour of TCP that we’ve studied in the lectures.
Hints: 1) The value of the congestion window size cannot be obtained directly from the Time-Sequence-Graph (Stevens) graph. Nevertheless, we can estimate the lower bound of the TCP window size by the amount of outstanding data because the outstanding data is the amount of data without acknowledgement. We also know that TCP window is constrained by the receiver window size and the receiver buffer can act as the upper bound of the TCP window size. In this trace, the receiver buffer is not the bottleneck; therefore, this upper bound is not quite useful to infer the TCP window size. Hence, you should focus on the lower bound of the TCP window size. 2) Assume that that sender (the client in this case) does not send data very aggressively, therefore the congestion window cannot be filled.
The User Datagram Protocol (UDP) (Optional Homework)
If you are working on your own machine then start capturing packets in Wireshark and then do something that will cause your host to send and receive several UDP packets. It’s also likely that just by doing nothing (except capturing packets via Wireshark) some UDP packets sent by others will appear in your trace (e.g. from a DNS request or SNMP, a network management protocol). After stopping packet capture, set your packet filter so that Wireshark only displays the UDP packets sent and received at your host. Pick one of these UDP packets and expand the UDP fields in the details window.
If you are unable to find UDP packets or are unable to capture packets with Wireshark (because your are working on a lab machine), you can download the udp-wireshark-trace.pcap packet trace which contains some UDP packets.
Answer the following questions:
• Select one UDP packet from your trace. From this packet, determine how many fields there are in the UDP header. (You shouldn’t look in the textbook! Answer these questions directly from what you observe in the packet trace). Name these fields.
• By consulting the displayed information in Wireshark’s packet content field for this packet, determine the length (in bytes) of each of the UDP header fields.
• The value in the Length field is the length of what? Verify your claim with your captured UDP packet.
• What is the maximum number of bytes that can be included in a UDP payload? (Hint: the answer to this question can be determined by your answer to question 2 above)
• What is the largest possible source port number?
• What is the protocol number for UDP? Give your answer in both hexadecimal and decimal notation. To answer this question, you’ll need to look into the Protocol field of the IP datagram containing this UDP segment.
• Examine a pair of UDP packets in which your host sends the first UDP packet and the second UDP packet is a reply to this first UDP packet. (Hint: for a second packet to be sent in response to a first packet, the sender of the first packet should be the destination of the second packet). Describe the relationship between the port numbers in the two packets (remember demultiplexing at the process level).
Files
tcp-ethereal-trace-1.pcap
udp-wireshark-trace.pcap