TCP Protocol Overview

Computer Networking: A Top-Down Approach

• This is a computer networking textbook, 6th edition.
• The authors are Jim Kurose and Keith Ross.
• Published by Addison-Wesley in March 2012.

Chapter 3: Transport Layer

• The Transport Layer uses PowerPoint slides freely available to students, faculty, and readers.
• Modifications, additions, and deletions to the slides are encouraged.
• The slides are copyrighted by J. F Kurose and K.W. Ross.
• Users are asked to acknowledge the source and copyright of the material if using the slides.

Principles of Reliable Data Transfer

• Reliable Data Transfer (RDT) is important in all layers (application, transport, and link).
• Unreliable channel characteristics determine reliable data transfer protocol (RDT) complexity.
• RDT protocols are a top 10 list of important networking topics.

RDT 1.0: Reliable Transfer over a Reliable Channel

• Underlying channel is perfectly reliable (no bit errors, no packet loss)
• Separate Finite State Machines (FSM) for sender and receiver.
• Sender sends data into underlying channel; receiver reads from channel.

RDT 2.0: Channel with Bit Errors

• Underlying channel may flip bits in packets.
• Checksums used to detect bit errors.
• Question: How to recover from errors?
• Humans recover from errors during conversation by checking for errors.
• Acknowledgements (ACKs) and negative acknowledgements (NAKs) used for error recovery.
• Sender retransmits packet upon receipt of NAK
• Error detection and feedback(ACK/NAK) mechanisms are built in rdt2.0.

RDT 2.0: FSM Specification

• RDT_send(data): Creates a packet with data and checksum.
• UDT_send(sndpkt): Sends packet over an unreliable channel.
• RDT_rcv(rcvpkt): Receives packet from the unreliable channel.
• isNAK(rcvpkt): Checks if received packet is a NAK.
• corrupt(rcvpkt): Checks if received packet is corrupted.
• isACK(rcvpkt): Checks if received packet is an ACK.
• Extract(rcvpkt, data): Extracts data from received packet.

RDT 2.0: Operation with No Errors

• RDT_send(data): Sends data packets.
• udt_send(sndpkt): Sends packets over an unreliable channel.
• RDT_rcv(rcv pkt): Receives packets.
• isNAK(rcvpkt): Checks if the received packet is a NAK

RDT 2.0: Error Scenarios

• RDT_send(data): Sends data packets.
• UDT_send(sndpkt): Sends packets over an unreliable channel.
• RDT_rcv(rcv pkt): Receives packets

RDT 2.0 has a Fatal Flaw!

• If ACK/NAK is corrupted, the sender doesn't know what happened to the receiver.
• The sender cannot just retransmit, since there may be possible duplicate data.
• Handling duplicates becomes necessary
• Sender sends one packet, then waits for the receiver response.

RDT 2.1: Sender, Handles Garbled ACK/NAKs

• Handles garbled ACK or NAKs by using two sequence numbers 0 or 1
• Allows sender to retransmit data

RDT 2.1: Receiver, Handles Garbled ACK/NAKs

• Handles garbled ACK/NAKs by checking if the data has sequence number 0 or 1

RDT 2.1: Discussion

• Sender: Sequence numbers are added to packets (0, 1) to handle duplicates.
• Receiver: Checks if the received packets are duplicates, if they have sequence numbers 0 or 1.

RDT 2.2: A NAK-Free Protocol

• Alternative to RDT 2.1, ACK only
• Receiver sends ACK for last received packet.
• Receiver explicitly includes the packet sequence number in its ACK.

RDT 2.2: Sender, Receiver Fragments

• Sender: Sends data packets according to sequence numbers, starting with sequence number 0.
• Receiver: Acknowledges received packets in order.

RDT 3.0: Channels with Errors and Loss

• Underlying channel can also lose packets / (data, ACKs).
• TCP sender waits a "reasonable" time for ACKs
• If no ACK is received within that time period, retransmit the packet.
• Duplicate segment retransmission is handled by sequence numbers.
• Uses countdown timer for lost packets

RDT 3.0 Sender

• Waits for call from above to send data
• Sends data using a sequence number

RDT 3.0 In Action

• Demonstrates scenario with no packet loss
• Shows situations where packets are lost and where ACKs are lost
• Shows timeout is caused by a lost packet

RDT 3.0 Performance

• TCP is correct but performance is poor
• For higher rates (Gbps), the network protocol limits the use of physical resources.

RDT 3.0 Stop-and-Wait Operation

• Sender sends packets sequentially and waits for acknowledgment before sending the next packet.
• The diagram shows the time taken for sender to send packet and receiver to acknowledge.

Pipelined Protocols

• Sender can transmit multiple packets before receiving ACKs.
• Buffers are used at the receiver.
• Go-Back-N, and Selective Repeat are generic forms of pipelined protocols.

Pipelining: Increased Utilization

• The use of pipelining increases the rate of transmission by sender, compared to stop-and-wait protocols.

Pipelined Protocols Overview

• In Go-Back-N protocols, the sender retransmits all packets lost from the last cumulative acks.
• Selective Repeat protocols allow the sender to retransmit only lost or corrupted packets.

Go-Back-N: Sender

• Uses k-bit sequence numbers in packet headers to identify segments uniquely.
• A "window" of up to N consecutive unacknowledged packets can be sent.

GBN: Sender Extended FSM

• Includes detailed state transitions, and actions based on events.

GBN: Receiver Extended FSM

• Acknowledges packets in order
• Only acknowledges correctly received packets

GBN in Action

• Example that shows when packets that are lost and the effect on sender and receiver

Selective Repeat

• Receiver acknowledges each received packet individually.
• Sender retransmits only unacknowledged packets.

Selective Repeat: Sender, Receiver Windows

• Sender: Window shows the segment sequence numbers, ready for transmission.
• Receiver: Window shows the segment sequence numbers that have been received

Selective Repeat

• Sender: Handles data from above
• Receiver: Handles packets in [receivbase, rcvbase+N-1]
• Both use ACK and timeout.
• Sender send packets and waits for response, if not received it times out
• If received, it increments and sends

Selective Repeat in Action

• Shows an example of sender and receiver interaction when packets are lost.

Selective Repeat : Dilemma Example

• Illustrates a scenario where duplicate data is being transmitted, but is accepted as a new packet by the recipient
• The problem arises from a conflict between sequence number and window size

TCP: Overview

• Point-to-point communication between a single sender and receiver.
• Reliable and in-order byte stream data transfer.
• Congestion and flow control via window size.

TCP Segment Structure

• The diagram shows the various fields in a TCP segment.

TCP Seq. Numbers, ACKs

• Sequence numbers represent byte stream numbers in the data segment.
• Acknowledgements (ACKs) acknowledge receipt of data by indicating expected next byte.

TCP Seq. Numbers, ACKs

• Illustrates the scenario of a TCP sequence numbers.

TCP Round Trip Time, Timeout

• Time-out value needs to be longer than the RTT.
• RTT varies and may be short so unnecessary transmissions may occur.
• Method to estimate RTT using recent measurements.

TCP Round Trip Time, Timeout

• Time-out interval is calculated by adding a safety margin to the estimated.

TCP Flow Control

• TCP flow control prevents the sender from overwhelming the receiver by transmitting too much data.
• Prevents buffer overflow at the receiver

TCP Flow Control

• Receiver advertises free buffer space (rwnd) in TCP header.
• Sender limits the amount of unacknowledged data ("in-flight") to the receiver's rwnd.

TCP Connection Management

• Handshaking, to establish a connection involves exchange of control messages(e.g, SYN, SYNACK, ACK)
• The sender and receiver agree on connection parameters

Agreeing to Establish a Connection

• Two-way handshake: Client requests a connection and server acknowledges.
• May not always work over the network due to delays or losses in network messages.

Agreeing to Establish a Connection: 2-way Handshake Failure Scenarios

• Different scenarios are listed to illustrate why a two-way handshake may fail.

TCP 3-way Handshake

• Three-way handshake involving SYN, SYNACK, and ACK ensures reliable connection establishment.

TCP 3-way Handshake: FSM

• State transition diagram for TCP 3-way handshake, showing states like LISTEN, SYN_SENT, SYN_RCVD, and ESTABLISHED.

TCP: Closing a Connection

• Client and server each close their side of the connection by sending FIN (Finish) segments
• ACK acknowledges receipt of FIN bit.
• Simultaneous FIN exchanges handled correctly.

TCP: Closing a Connection

• A state diagram illustrating the closing connection process (ESTAB, FIN-WAIT_1, FIN_WAIT_2, TIMED_WAIT)

Chapter 3 Outline

• Transport Layer Services
• Multiplexing and Demultiplexing
• Connectionless Transport (UDP)
• Principles of Reliable Data Transfer
• Connection-Oriented Transport (TCP)
• Principles of Congestion Control
• TCP Congestion Control

Principles of Congestion Control

• Congestion occurs when too many sources are sending data too quickly for a network to handle, a common problem; Different from flow control.
• Congestion manifests as lost packets (e.g., buffer overflow) and long delays (queueing).

Causes/Costs of Congestion: Scenarios

• Scenarios of two or multiple senders, and one or multiple receivers all sending data to the same router are presented.

Causes/Costs of Congestion: Scenarios

• Perfect knowledge is assumed with respect to when senders can send packets as well as the availability of router buffers.

Causes/Costs of Congestion: Scenarios

• Real scenarios are discussed where packets might be lost if the routers buffer is full; Sender time outs prematurely, and duplicates packets
• Additional cost of congestion is excess work

Causes/Costs of Congestion: Scenario 3

• Describes the effects of having multiple senders to the same single receiver, and implications of this scenario

Causes/Costs of Congestion: Scenario 3

• Further explanations of the cost of congestion and effect having more senders causes congestion is presented

Approaches Towards Congestion Control

• Both end-to-end and network-assisted approaches to congestion control are discussed.

Case Study: ATM ABR Congestion Control

• Congestion control methods in the ATM network are explained.

Case Study: ATM ABR Congestion Control

• Description of additional control method such as RM cells to indicate when the system is congested and ways that switches use to manage

TCP Congestion Control

• Additive increase, multiplicative decrease mechanisms for controlling transmission.
• Slow start, and congestion avoidance are components.

TCP Slow Start

• When a connection begins, the rate of transmission increases exponentially until a loss event occurs.
• The initial cwnd is set to 1 MSS (Maximum Segment Size).
• The cwnd is doubled every round trip time if no loss events exist

TCP: Detecting, Reacting to Loss

• TCP detects loss events.
• Loss can be detected via timeouts or by having 3 duplicated ACKs.
• TCP RENO used to handle duplicated ACKs.
• TCP Tahoe sets cwnd to 1 upon timeout or receipt of three duplicate acks.

TCP: Switching from Slow Start to CA

• TCP switches from the slow start to congestion avoidance when cwnd reaches half the previous value of cwnd before a timeout occurs
• This mechanism prevents cwnd reaching too large a value
• This approach can help prevent more packets being lost/dropped

Summary: TCP Congestion Control

• Summary of the TCP congestion control.
• The diagram depicts TCP states, events, and actions.

TCP Throughput

• TCP throughput is related to window size.
• Avg. throughput when there is loss is 3/4W per RTT

TCP Futures

• The example shows how TCP works over longer distance with high speed pipes
• Describes how efficient TCP is

TCP Fairness

• Fairness is ensured to various TCP sessions that use the same bottleneck link.
• The average rate of each connection will be equal to R / K .

Why is TCP Fair?

• TCP's design components contribute to fairness.
• Additive increase and multiplicative decrease contribute to fairness

Fairness (more)

• UDP often used for multimedia applications
• UDP does not need rate control, and tolerates packet loss
• Web browsers send multiple concurrent connections because it is more efficient

Chapter 3 Summary

• Summary of several techniques, principles, and components to the transport layer, including Multiplexing, Demultiplexing, Reliable Data Transfer, Flow Control, and Congestion Control.

This quiz explores key concepts of the TCP protocol, including fast retransmit, acknowledgment mechanisms, and the 3-way handshake process. Test your understanding of how TCP manages data transmission and error correction to ensure reliable communication.