TCP - Part I Relates to Lab 5. First module on TCP which covers packet format, data transfer, and connection management.

Overview TCP = Transmission Control Protocol Connection-oriented protocol Provides a reliable unicast end-to-end byte stream over an unreliable internetwork.

Connection-Oriented Before any data transfer, TCP establishes a connection: One TCP entity is waiting for a connection (“server”) The other TCP entity (“client”) contacts the server The actual procedure for setting up connections is more complex. Each connection is full duplex

Reliable Byte Stream Service: Detecting errors: The received byte stream from the application is broken up into chunks which are called segments Receiver sends acknowledgements (ACKs) for segments received correctly TCP maintains a timer. If an ACK is not received in time, the segment is retransmitted Detecting errors: TCP uses a checksum to detect errors. Segments with invalid checksums are discarded Each byte that is transmitted has a sequence number

Byte Stream Service To the lower layers, TCP handles data in blocks - segments To the higher layers TCP handles data as a sequence of bytes and does not identify boundaries between bytes So: Higher layers do not know about the beginning and end of segments!

TCP Packet Format TCP segments have a 20-60 byte header with >= 0 bytes of application data

TCP header fields Port Number: A port number identifies the endpoint of a connection. A pair <IP address, port number> identifies one endpoint of a connection. Two pairs <client IP address, client port number> and <server IP address, server port number> identify a TCP connection.

TCP header fields Sequence Number (SeqNo): Sequence number is 32 bits long. So the range of SeqNo is 0 <= SeqNo <= 232 -1  4.3 Gbyte A sequence number identifies a specific byte in the byte stream. Each byte has a sequence number An Initial Sequence Number (ISN) for a connection is picked at random at each end and is set during connection establishment

TCP header fields Acknowledgement Number (AckNo): Acknowledgements can be piggybacked a segment from A -> B can contain an acknowledgement for data sent in the B -> A direction A hosts uses the AckNo field to send acknowledgements if a host sends an AckNo in a segment it sets the “ACK flag” The AckNo contains the next SeqNo that a receiving host is expecting to receive from the sender. Eg: The acknowledgement for a segment with sequence number “0” and data length of 1500 bytes is AckNo = 1500 (0-1499 = 1500 bytes) The next segment sent from sender should have a SeqNo = 1500.

TCP header fields Data Offset, i.e., Header Length (4bits): Length of header in 32-bit words Note that TCP header is variable length minimum 20bytes = 5words maximum of 60bytes (due to the 40byte options field) Reserved (3bits): Bits left open for future use. Set to ZERO

TCP header fields Flag bits cont: URG (1 bit) – indicates that the Urgent pointer field is significant and the following bytes contain an urgent message in the range: SeqNo = 1st byte of urgent message 1st byte of Normal data starts at = SeqNo+urgent pointer ACK (1 bit) – indicates that the Acknowledgment field is significant. All packets after the initial SYN packet sent by the client should have this flag set. PSH (1 bit) – Push function. Sender asks receiver to push the buffered data to the receiving application. Normally set by sender when the sender’s buffer is empty. RST (1 bit) – Sender tells receiver to reset the connection. Receiver of a RST terminates the connection and indicates higher layer application about the reset.

TCP header fields Flag bits cont: SYN (1 bit) – Synchronize sequence numbers. Only the first packet sent from each end should have this flag set (during connection set up). Some other flags and fields change meaning based on this flag -> some are only valid for when it is set, and others when it is clear. FIN (1 bit) – Last package from sender. Sender is done with transmitting Used for closing a connection Both sides of a connection must send a FIN One side can be done before the other

TCP header fields Window Size: flow control from a receiver limiting transmissions from a sender – “controlling flow of data being sent from S -> R by R” Each side of the connection advertises a receive window size in bytes Maximum window size can be 216-1= 65535 bytes The size of the receive window, specifies the number of bytes (beyond the segment identified by the sequence number in the acknowledgment field) that the sender of this segment is currently willing to receive Urgent Pointer: Only valid if URG flag is set

TCP header fields TCP Checksum: TCP checksum covers both TCP Pseudo header and TCP header and data. Pseudo header consists of: IP Source address IP Destination address Protocol Type: TCP in this case TCP length – header and data

TCP header fields Options: The “len” field indicates length in bytes of the option (>1byte): kind+length+data e.g. 1+1+2 = 4

MTU and MSS: The Maximum Transmission Unit (MTU) is the maximum length of data that can be transmitted by a protocol in one instance. If we take the Ethernet interface as an example, the MTU size of an Ethernet interface is 1500 bytes by default, which excludes the Ethernet frame header and trailer. It means that the interface cannot carry any frame larger then 1500 bytes. If we look inside the frame, we have a 20 byte IP header + 20 byte TCP header, leaving a 1460 byte of the payload that can be transmitted in one frame. This is what we refer to as TCP MSS. The diagram below visualizes this concept: IP Header TCP Header Payload FCFS Ethernet Header MTU (on Cisco router referred to as IP MTU) TCP MSS 14 bytes 20-40 bytes 4 bytes

Path Discovery Protocol Used for determining the maximum transmission unit (MTU) size on the network path between two Internet Protocol (IP) hosts, usually with the goal of avoiding IP fragmentation Path MTU Discovery works by setting the Don't Fragment (DF) flag bit in the IP headers of outgoing packets Any device along the path whose MTU is smaller than the size of IP datagram will drop it, and send back an Internet Control Message Protocol (ICMP) Fragmentation Needed (Type 3, Code 4) message containing its MTU This will result in the source host reducing its Path MTU appropriately. The process is repeated until the MTU is small enough to traverse the entire path without fragmentation. Recall traceroute and ICMP error for TTL, similar operation.

Connection Management in TCP Opening a TCP Connection Closing a TCP Connection Special Scenarios State Diagram

TCP Connection Establishment TCP uses a three-way handshake to open a connection: (1) ACTIVE OPEN: Client sends a segment with SYN bit set port number of client initial sequence number (ISN) of client – e.g. x (2) PASSIVE OPEN: Server responds with a segment with initial sequence number of server, e.g. y ACK for ISN of client: x+1 (3) Client acknowledges by sending a segment with: SeqNo = x+1 ACK ISN of server: y+1

Three-Way Handshake

Three-Way Handshake – actual example 1031880194:1031880194(0)

A TCP SYN Packet

A TCP SYN, ACK Packet

A TCP ACK Packet (last in 3 way handshake

A TCP Data Packet

Using Wireshark to Illustrate flow To better understand how sequence and acknowledgement numbers are used throughout the duration of a TCP session, we can utilize Wireshark's built-in flow graphing ability. Navigate to Statistics > Flow Graph..., select TCP flow and click OK. Wireshark automatically builds a graphical summary of the TCP flow. Each row represents a single TCP packet. The left column indicates the direction of the packet, TCP ports, segment length, and the flag(s) set. The column at right lists the relative sequence and acknowledgement numbers in decimal. Selecting a row in this column also highlights the corresponding packet in the main window. We can use this flow graph to better understand how sequence and acknowledgement numbers work.

Figure Illustrating Wireshark output

Packet Flow explanation Packet #1: Each side of a TCP session starts out with a (relative) sequence number of zero. Likewise, the acknowledgement number is also zero, as there is not yet a complementary side of the conversation to acknowledge. (Note: The version of Wireshark used for this demonstration, 1.2.7, shows the acknowledgement number as an apparently random number. This believed to be a software bug; the initial acknowledgement number of a session should always be zero, as you can see from inspecting the hex dump of the packet.) Packet #2: The server responds to the client with a sequence number of zero, as this is its first packet in this TCP session, and a relative acknowledgement number of 1. The acknowledgement number is set to 1 to indicate the receipt of the client's SYN flag in packet #1. Notice that the acknowledgement number has been increased by 1 although no payload data has yet been sent by the client. This is because the presence of the SYN or FIN flag in a received packet triggers an increase of 1 in the sequence. (This does not interfere with the accounting of payload data, because packets with the SYN or FIN flag set do not carry a payload.)

Packet #3: Like in packet #2, the client responds to the server's sequence number of zero with an acknowledgement number of 1. The client includes its own sequence number of 1 (incremented from zero because of the SYN). At this point, the sequence number for both hosts is 1. This initial increment of 1 on both hosts' sequence numbers occurs during the establishment of all TCP sessions. Packet #4: This is the first packet in the stream which carries an actual payload (specifically, the client's HTTP request). The sequence number is left at 1, since no data has been transmitted since the last packet in this stream (NOTE: the last ACK packet in 3Way handshake (packet #3) has no SYN flag set). The acknowledgement number is also left at 1, since no data has been received from the server, either. Note that this packet's payload is 725 bytes in length.

Packet #5: This packet is sent by the server solely to acknowledge the data sent by the client in packet #4 while upper layers process the HTTP request. Notice that the acknowledgement number has increased by 725 (the length of the payload in packet #4) to 726; e.g., "I have received 725 bytes so far and am waiting for byte 726." The server's sequence number remains at 1. Packet #6: This packet marks the beginning of the server's HTTP response. Its sequence number is still 1, since none of its packets prior to this one have carried a payload. This packet carries a payload of 1448 bytes.

Packet #7: The sequence number of the client has been increased to 726 because of the last packet it sent. Having received 1448 bytes of data from the server, the client increases its acknowledgement number from 1 to 1449.For the majority of the capture, we will see this cycle repeat. The client's sequence number will remain steady at 726, because it has no data to transmit beyond the initial 725 byte request. The server's sequence number, in contrast, continues to grow as it sends more segments of the HTTP response.

Why is a Two-Way Handshake not enough? Timeout, aida resends SYN request The red line is a delayedSYN packet Ack 1031880194 New SYN will be discarded as a duplicate SYN as connection at mng is expecting an ACK from aida in response to its SYN not another SYN SYN, ACK response to first delayed SYN received 1031880194:1031880194(0) Ack 172488587

TCP Connection Termination Each end of the data flow must be shut down independently (“half-close”) If one end is done it sends a FIN segment. This means that no more data will be sent Four steps involved: (1) X sends a FIN to Y (active close) (2) Y ACKs the FIN, (at this time: Y can still send data to X) (3) and Y sends a FIN to X (passive close) (4) X ACKs the FIN.

TCP Connection Termination

TCP States in “Normal” Connection Lifetime

TCP States

TIME_WAIT state TIME_WAIT = 2MSL When TCP does an active close, and sends the final ACK, the connection must stay in the TIME_WAIT state for twice the maximum segment lifetime. 2MSL= 2 * Maximum Segment Lifetime (roundtrip delay) Why? TCP is given a chance to resend the final ACK. (Server will timeout after sending the first FIN segment and resend the FIN)

Resetting Connections Resetting connections is done by setting the RST flag When is the RST flag set? Connection request arrives and no server process is waiting on the destination port Abort (Terminate) a connection Causes the receiver to throw away buffered data. Receiver does not acknowledge the RST segment