Tutorial 7

Introduction

In PA4 you will be building your own reliable transport protocol, a simplified version of TCP. This tutorial is focused on reviewing TCP.

TCP Connection Establishment and Termination

Recall the TCP 3-way handshake, used to establish a connection between sender/receiver:

Q1. What additional information is sent with the SYN/ACK flags set? Why are the three steps necessary?

Recall the TCP 4-way handshake, used to terminate the connection between sender/receiver:

Q2. Why are the four steps necessary?

TCP Sequence and Acknowledgement numbers

Recall sequence and acknowledgement numbers for TCP:

• The sequence number of a segment is the sequence number of its first byte
• ACKs correspond to the first sequence number not yet received
• The receiver stores out-of-order packets in its own window
• ACKs are cumulative

TCP Retransmission

Recall:

• A timer is set for the first unacknowledged segment
• When the timer expires we retransmit
• Retransmit just one segment (like Selective-Repeat)
• Four or more ACKs with the same number trigger retransmission without a timeout (fast retransmission)

Flow Control

Recall the receiver may be slower at receiving data than the sender is at sending data. The receiver has a flow control window measured in bytes that will be advertised by the receiver.

TCP Segment

Q3. Which fields are important for the following aspects of a reliable, connection-based transport protocol?

• Connection establishment
• Connection termination
• In-order delivery and complete delivery
• Flow control

Using Wireshark to Following a TCP Conversation

Now that we've refreshed the TCP basics, let's use Wireshark to follow a TCP conversation.

1. Find the ipv4 and ipv6 addresses for google.com using ping and ping6 on your terminal.
2. Open up Wireshark and start capturing.
3. In your browser, load http://google.com/generate_204. This will load for a second but not generate any content. We are using this as an example as most web data is now encrypted and sent with TLS.
4. Stop the Wireshark capture.
5. Filter your capture using ip.addr == <the ipv4 address you found in 1>
   • If there are no results, then try filtering using ipv6.addr == <the ipv6 address you found in 1>
6. You should now be seeing the entire conversation between your computer and google.com.
   • See if you can identify the connection establishment and termination handshakes.
   • Observe the sequence and ack numbers and make sense of them, check out Wireshark's SEQ/ACK analysis.

Sequence and ACK Number Practice

Q4. Fill in the missing information for the following TCP packets. Assume the connection is already established, there are no outstanding packets, and the next packet to be sent by the client with have sequence number 100, and the next packet to be sent by the server will have sequence number 200. Assume packets are listed in the order seen by the client, and that all packets arrive in both directions.

Some Solutions

1. Lots of information is included in these packets (port numbers, window sizes, flags, etc). Crucially, we get the initial sequence numbers of the client and the server during this stage. To understand why we have 3 steps in the setup, suppose we had 1 less. To start, our client would still send the syn packet with their sequence number to the server. The server attempts to respond with a SYN/ACK packet containing its sequence number. If our handshake stopped here, we could run into some problems.

   • Suppose the SYN/ACK packet is lost. Now, the server believes that the connection has been established (after all, it has sent the SYN/ACK as required) but the client is unable to send messages to the server as it does not know the ack number
   • Suppose that a SYN/ACK packet from long, long ago has been delayed and finally reaches the client before the most recent/correct one can reach the client. How would we correct for this?

2. Similarly to (1), suppose we only 3 steps in the closing protocol. Without loss of generality, assume that the sender is initiaing the fin. In this case, the server would respond with an ACK and a FIN without waiting to ensure that the client has recieved the FIN message.

   • In this case, how can the server be sure that the client has closed? But what are the consequences of the client not closing its connection?
   • To answer these questions, suppose that the FIN is actually lost. The client is now left hanging, unsure if there is more data to recieve. The client could hang for a long time and waste a lot of resources.
   • This doesn't seem so bad (who cares about clients anyway??), but what if the server is initiating the close? Further, suppose we have critical information being exchanged (financial information, nuclear launch codes, the Princess of Wales' location, etc) where we want to ensure that we have all the data. Would we want to risk closing the connection before seeing the FIN?

3. A lot of information is important for all stages of the protocol (port number, checksum, etc). Some notable ones at each stage:

• Connection establishment: SYN/ACK flags, sequence number, ack number
• Connection termination: FIN/ACK flags, sequence number, ack number
• In-order delivery and complete delivery: sequence number, ack number, checksum
• Flow control: sequence number, ack number, window size,