CSCI 4550/8556 Computer Networks Comer, Chapter 24: TCP: Reliable Transport Service

Introduction The Internet Protocol (IP) provides “unreliable datagram service” between hosts . Transport protocols provide end-to-end delivery between the endpoints of a connection; that is, between processes or programs. The User Datagram Protocol (UDP) provides datagram service. The Transmission Control Protocol (TCP) provides reliable data delivery service.

User Datagram Protocol UDP delivers independent messages, called datagrams between applications or processes on host computers. “Best effort” delivery means datagrams may be lost, delivered out of order, etc. An optional checksum in UDP messages improves the integrity of the data. For generality, the endpoints of a UDP communication are called protocol ports or, more simply, just ports . Each UDP data transmission identifies the internet address and port number of the destination and the source (IP address and port number) of the message. The destination port and the source port may be different.

UDP and TCP/IP Layering Transport protocols are used to provide data delivery services for application protocols. Applications Transmission Control Protocol User Datagram Protocol Internet Protocol Network Interface Hardware

UDP Headers UDP messages have a header that follows the hardware and IP headers: Hardware IP UDP Data The UPD header format is simple: Source and destination port numbers, and message length (in octets) Optional checksum (0 if not used) Source Port Destination Port Message Length Checksum

Selecting UDP Port Numbers Communicating computers must agree on a port number The “server” opens the selected port and waits for incoming messages. The “client” selects a local port and sends a message to the selected “server” port. The services provided by many computers use reserved, well-known port numbers: ECHO (usually port 7) DISCARD (usually port 9) TIME (usually port 37) Other services use dynamically assigned port numbers.

Transmission Control Protocol (TCP) Transmission Control Protocol (TCP) is the most widely used transport protocol. It provides reliable data delivery by using IP unreliable datagram delivery. It compensates for loss, delay, duplication and similar problems in Internet components. Reliable delivery is the high-level, familiar model used in the construction of applications.

TCP Features Connection oriented: An application requests a connection to a destination and then uses that connection to transfer data. Point-to-point: A TCP connection has two endpoints. Reliable: TCP guarantees the data will be delivered without loss, duplication or transmission errors. Full duplex: The endpoints of a TCP connection can exchange data in both directions simultaneously. Stream interface: An application delivers data to TCP as a continuous stream, with no record boundaries; TCP makes no guarantees that the data will be received in the same units in which it was transmitted. Reliable connection startup: A three-way handshake guarantees reliable, synchronized startup between endpoints. Graceful connection shutdown: TCP guarantees delivery of all data after endpoint shutdown by an application.

Using IP for Data Delivery TCP uses IP for data delivery (like UDP). The endpoints are identified by port numbers (like UDP): This allows multiple connections on each host. The ports may be associated with an application or a process. The TCP port numbers are in a different address space than UDP ports; TCP port 23 is not the same as UDP port 23. IP treats TCP messages like data and does not interpret any contents of the TCP message.

Delivering TCP Messages TCP messages travel in IP datagrams. Internet routers only look at the IP header to forward datagrams. The TCP protocol software at the destination interprets TCP messages.

TCP and Reliable Delivery TCP uses many techniques described earlier to provide reliable delivery. It recovers from: lost packets duplicate packets delayed packets corrupted data transmission speed mismatches congestion system reboots

Lost Packets TCP uses positive acknowledgment with retransmission (PAR) to achieve reliable data delivery. The recipient sends acknowledgment control messages (ACKs) to the sender to report successful receipt of data. The sender sets a timer when data is transmitted; if the timer expires before an acknowledgment arrives, the sender retransmits the data (with a new timer).

TCP Segments and Sequence Numbers An application delivers arbitrarily large chunks of data to TCP as a “stream” of bytes. TCP breaks this data into segments, each of which fits into an IP datagram. Each byte in the original stream is given a sequence number. Each TCP segment identifies the range of sequence numbers of the data bytes included in the segment.

Acknowledgements When a receiver sends a segment containing its own data, it includes the range of sequence numbers of data (from the sender) that it acknowledges. The receiver does not acknowledge individual segments. One ACK can acknowledge many segments.

Setting the Timeout Interval Using inappropriate timeout intervals can cause poor performance: If it’s too long, the sender waits longer than necessary before retransmitting a segment. If it’s too short, the sender generates unnecessary traffic. The timeout interval must be different for each connection and must be set dynamically. Hosts on same LAN should have shorter timeout intervals than hosts 20 hops away. Delivery time across an internet may change over time; timeout intervals must accommodate changes.

Different Round-Trip Delays Timeout and retransmission on two connections may have different round-trip delays. TCP optimizes throughput by using estimates of round-trip delays to compute retransmission timer invervals.

Picking a Value for the Timeout Interval The timeout interval should be based on the estimated round-trip time (RTT) for a segment. The sender doesn’t know the RTT of any segment before transmission. The sender picks a retransmission timeout (RTO) based on previous RTT values. The specific method is called the adaptive retransmission algorithm.

Computation of RTT and RTO A weighted average is used to update the round-trip time. The parameter  controls how much a new RTT value can influence the average;  is typically 7/8. The timeout interval (RTO) is just the new RTT average times another parameter, , which always used to be 2.

Jacobson’s Mean Deviation Algorithm Instead of using a fixed  in RTO computations, most TCP implementations now compute D, a weighted average of the difference between the expected RTT value and the actual value, M.  may be different from the value used in computing the weighted RTT value. Now, RTO is computed as follows. The value 4 has been shown to give good performance (but was originally suggested to be 2).

Measuring Round-Trip Delay (RTT) RTT is measured by observing the difference between the time of transmission and the time of arrival of an acknowledgment. However, acknowledgments carry no information about which packet was acknowledged. Thus, the sender cannot determine whether the acknowledgment is from the original transmission or from a retransmission. Choosing the original transmission overestimates RTT. Choosing the retransmission underestimates RTT.

Karn’s Algorithm How is TCP to choose between the original and a retransmission? The answer: choose neither! Karn's algorithm specifies that the sender ignores RTTs for retransmitted segments. How will the RTT get updated if the internet round trip time increases? Karn's algorithm specifies that RTO values be computed separately from RTT when retransmissions occur. RTO doubles with new segment retransmission until an ACK arrives.

The TCP Sliding Window TCP uses a sliding window for flow control. The receiver specifies the window. This is called window advertisement. It specifies which bytes in the data stream can be sent. It is carried in segment along with an ACK. The sender can transmit any bytes, in any size segment, after the last acknowledged byte, but must stay within window.

A Sliding Window with Acknowledgements

The Silly Window Syndrome Under some circumstances, the sliding window protocol can result in the transmission of many small segments. If the receiver window is full, and the receiving application consumes a few data bytes, the receiver will advertise a small window. The sender will immediately send a small segment to fill the window. This is inefficient in terms of processing time and network bandwidth. Solutions: Have the receiver delay advertising a new window until it is of reasonable size (Clark’s solution). Have the sender delay sending data when the window is small (Nagle’s solution).

Silly Window Syndrome Example Receiver’s buffer is full Application reads one byte  Room for one more byte Header New window size advertised Header New byte arrives Receiver’s buffer is full 1 Byte

The TCP Segment Format Each TCP segment has the folowing header: The same header format is used in both directions. Each segment carries an acknowledgement and possibly data.

Urgent Data When a host decides to interrupt a remote application, the appropriate control information is sent as urgent data in the TCP data stream. The presence of urgent data is indicated by setting the URG bit (in the code bits), and pointing to the end of the urgent data in the segment with the urgent pointer. When urgent data is sent by an application, TCP sends everything it has accumulated (including the urgent data) immediately. When the remote application receives the urgent data (usually with a signal, in UNIX terminology), it stops whatever it was doing to handle the urgent data.

Three-Way Handshake TCP uses a three-way handshake for reliable connection establishment. Host 1 sends a segment with the SYN bit set (in the code bits) and a random sequence number. Host 2 responds with a segment with SYN bit set, acknowledgment of Host 1’s sequence number, and a random sequence number of its own. Host 1 responds with an acknowledgment of Host 2’s sequence number. TCP will retransmit lost segments. Random sequence numbers ensure synchronization between endpoints. The same type of three-way handshake is used for termination, but the FIN bit is used.

Closing a Connection

Congestion Control Excessive traffic can cause packet loss. Transport protocols respond to lost packets with retransmission. Excessive retransmission can cause congestion collapse . TCP interprets packet loss as an indicator of congestion. The sender uses TCP congestion control and slows the transmission of packets. It first sends a single packet. If the acknowledgment returns without loss, it sends two packets. When TCP sends one-half of the window size, the rate of increase slows.

Summary UDP provides best-effort end-to-end message delivery. IP is used for delivery to destination host. Protocol ports demultiplex to the right destination application TCP provides reliable end-to-end byte stream delivery. IP is used for delivery to the destination host. Protocol ports demultiplex data to the right destination application. Additional techniques develop reliable delivery from IP messages: Positive acknowledgment with retransmission (PAR) Use round-trip time to adjust timeout intervals (Jacobsen, Karn) Sequence numbers to detect missing, duplicate and out-of-order data Sliding window flow control Clark’s and Nagle’s algorithms for silly window syndrome Three-way handshake for reliable connection and termination Congestion control algorithms