Transport Layer: Principles, TCP, and Congestion Control Notes

Overview of Transport-Layer Services and Pioneers

• Historical Context: The development of the Transport Layer is credited to Vinton Cerf and Robert Kahn. They were the 2004 Turing Award winners for their pioneering work on internetworking, which included the design and implementation of the TCP/IP communication protocols and their inspired leadership in the field.

• Roadmap of Transport-Layer Topics:   - Transport-layer services.   - Multiplexing and demultiplexing.   - Connectionless transport (UDP).   - Principles of reliable data transfer.   - Connection-oriented transport (TCP).   - Principles of congestion control.

TCP: High-Level Overview and Characteristics

• Relevant Request for Comments (RFCs): TCP is defined across several documents including RFC 793, RFC 1122, RFC 2018, RFC 5681, and RFC 7323.

• Primary Mechanisms:   - Cumulative ACKs: Acknowledgments track the next expected byte.   - Pipelining: TCP uses congestion and flow control to determine the appropriate window size for data in flight.   - Connection-Oriented: Requires handshaking (the exchange of control messages) to initialize sender and receiver state before any actual data exchange occurs.   - Flow Controlled: The sender is restricted so it will not overwhelm the receiver.   - Point-to-Point: The connection exists between exactly one sender and one receiver.   - Reliable, In-order Byte Stream: There are no "message boundaries"; data is treated as a continuous stream of bytes.   - Full Duplex Data: Bi-directional data flow is supported within the same connection.   - MSS (Maximum Segment Size): Defines the largest amount of data that can be placed in a single segment.

TCP Segment Structure

• Header Fields (32 bits wide):   - Source Port # and Destination Port #: Used for multiplexing and demultiplexing.   - Sequence Number: A 32-bit field. Crucially, the segment sequence number counts bytes of data entered into the byte stream, not the number of segments.   - Acknowledgment Number: A 32-bit field representing the sequence number of the next expected byte. The 'A' bit (ACK bit) indicates if this field is valid.   - Head Len (Header Length): Indicates the length of the TCP header.   - C, E (Congestion Notification): Used for explicit congestion notification.   - Control Bits (R, S, F):     - RST (R): Reset the connection.     - SYN (S): Synchronize sequence numbers (used in connection establishment).     - FIN (F): Finish (used in connection teardown).   - Receive Window: Used for flow control; specifies the number of bytes the receiver is willing to accept.   - Checksum: Used for error detection in the header and data.   - Urg Data Pointer: Points to urgent data (rarely used).   - Options: Variable length field for additional TCP features.

• Comparison with UDP: Contrastingly, the UDP segment format is significantly simpler, containing only source/destination ports, length, and checksum, followed by the application data.

TCP Connection Management

• The Three-Way Handshake: Before exchanging data, the sender and receiver must agree to establish a connection and synchronize parameters (like starting sequence numbers).   1. Step 1 (SYN): Client sends a TCP SYN message to the server (SYN bit = 1) with an initial sequence number $x$. State moves to SYN_SENT.   2. Step 2 (SYNACK): Server receives SYN and responds with SYNACK (SYN bit = 1, ACK bit = 1). It acks the client's SYN (ACK num = $x+1$) and chooses its own initial sequence number $y$. State moves to SYN_RCVD.   3. Step 3 (ACK): Client receives SYNACK, confirming the server is live. It sends an ACK (ACK bit = 1, ACK num = $y+1$). This segment may also contain client-to-server data. Both move to ESTABLISHED state.

• Why a 2-way Handshake Fails: A 2-way handshake (Req_conn / Acc_conn) is insufficient due to:   - Variable delays and message reordering.   - Retransmitted messages (e.g., duplicated connection requests) leading the server to establish "half-open" connections with no active client.   - Duplicate data being accepted from old, delayed connections.   - The need for randomized sequence numbers to prevent security attacks.

• Connection State Machine:   - Server States: LISTEN $\rightarrow$ SYN_RCVD $\rightarrow$ ESTABLISHED $\rightarrow$ CLOSE_WAIT $\rightarrow$ LAST_ACK $\rightarrow$ CLOSED.   - Client States: CLOSED $\rightarrow$ SYN_SENT $\rightarrow$ ESTABLISHED $\rightarrow$ FIN_WAIT_1 $\rightarrow$ FIN_WAIT_2 $\rightarrow$ TIME_WAIT $\rightarrow$ CLOSED.

• Tearing Down a Connection: Each side must close its portion of the connection by sending a FIN bit = 1 and responding with an ACK.   - Half Close: The client closes its sending side, but the server continues sending data.   - Full Close: Both sides exchange FINs and ACKs in rapid succession.   - Simultaneous Close: Both sides send FINs at the same time.

Human Protocol Analogy: 3-Way Handshake (Climbing/Belaying)

• Process:   1. Climber: "On belay?" (Requesting status/SYN).   2. Belayer: "Belay on." (Confirmation/SYNACK).   3. Climber: "Climbing." (Action/ACK).

• Additional Commands: The transcript lists extended commands like "Slack!", "Up rope", "Tension" (Gotcha), "Ready to lower" (Lowering), and "Off belay" (Belay off).

Sequence Numbers and Reliability in Depth

• Sequence Number Definition: The byte stream "number" of the first byte in the segment's data.

• Acknowledgment Definition: The sequence number of the next byte expected from the other side. TCP uses cumulative ACKs.

• Handling Out-of-Order Segments: The TCP specification does not explicitly dictate how to handle out-of-order segments; it is left to the implementor. However, almost all modern implementations buffer these packets.

• Telnet Scenario Example:   - User types 'C' at Host A ($Seq=42, ACK=79$).   - Host B receives 'C', echoes it back ($Seq=79, ACK=43$).   - Host A ACKs the echo ($Seq=43, ACK=80$).

• General Rules for Seq/Ack Calculation:   - Rule 1: SYN packets increment sequence numbers by 1.   - Rule 2: Sequence numbers are present in ACKs.   - Rule 3: Sequence numbers increment based on the amount of data sent.   - Rule 4: Empty ACKs are not acknowledged themselves.

Round Trip Time (RTT) and Timeout Calculation

• Setting the Timeout: The timeout must be longer than the RTT, but RTT is variable. If too short, it causes premature timeouts; if too long, response to loss is slow.

• Estimating RTT: Use an Exponential Weighted Moving Average (EWMA) of SampleRTT (time from transmission to ACK, ignoring retransmissions).   - Estimated RTT Formula: $\text{EstimatedRTT} = (1 - \alpha) \times \text{EstimatedRTT} + \alpha \times \text{SampleRTT}$   - Typical value for $\alpha = 0.125$.

• Calculating Deviation (DevRTT):   - DevRTT Formula: $\text{DevRTT} = (1 - \beta) \times \text{DevRTT} + \beta \times |\text{SampleRTT} - \text{EstimatedRTT}|$   - Typical value for $\beta = 0.25$.

• Calculating Timeout Interval: Includes a "safety margin."   - TimeoutInterval Formula: $\text{TimeoutInterval} = \text{EstimatedRTT} + 4 \times \text{DevRTT}$

TCP Sender and Receiver Logic

• Sender Events:   - Data Received from App: Create segment with current $Seq$, start timer for the oldest unACKed segment.   - Timeout: Retransmit the segment that caused the timeout and restart the timer.   - ACK Received: Update status of unACKed segments. If segments remain, restart the timer.

• Receiver ACK Generation (RFC 5681):   - In-order, no ACKs pending: Delayed ACK; wait up to $500\text{\,ms}$ for next segment.   - In-order, one ACK pending: Send a single cumulative ACK immediately.   - Out-of-order (Gap detected): Send a duplicate ACK immediately specifying the next expected byte.   - Arrival filling a gap: Send an ACK immediately if the segment starts at the lower end of the gap.

• Fast Retransmit: If a sender receives three additional ACKs for the same data (triple duplicate ACKs), it likely means a segment was lost. The sender retransmits the missing segment before the timer expires.

TCP Flow Control

• Mechanism: The receiver controls the sender so the sender does not overflow the receiver's buffers. The network layer may deliver data faster than the application removes it.

• Receive Window ($rwnd$): The receiver "advertises" free buffer space using the $rwnd$ field.   - Typical default $RcvBuffer$ size is $4096\text{\,bytes}$.   - The sender limits unACKed ("in-flight") data such that: $\text{LastByteSent} - \text{LastByteAcked} \leq rwnd$.

• The 0-Window Scenario: If $rwnd = 0$, the sender continues to send 1-byte packets to solicit ACKs and check if buffer space has cleared.

Principles of Congestion Control

• Definition: Informally, "too many sources sending too much data too fast for the network to handle."

• Congestion vs. Flow Control: Congestion control involves many senders overwhelming the network; flow control involves one sender overwhelming one receiver.

• Manifestations: Long delays (queueing) and packet loss (buffer overflow).

• Scenarios and Costs:   - Scenario 1: Two flows, infinite buffers. Result: throughput approaches link capacity $R/2$, but delay increases exponentially.   - Scenario 2: Finite buffers, retransmissions. Result: throughput is less than $R/2$ because link capacity is wasted on retransmitting dropped packets and unneeded duplicates.   - Scenario 3: Multi-hop paths. Result: when a packet is dropped downstream, all upstream transmission capacity used to get it to that point is wasted.

• Energy Costs: Retransmissions increase energy usage at the client (especially on wireless links). Most of the energy budget is consumed at the "edge" of the network.

TCP Congestion Control Algorithms

• Variables:   - Congestion Window ($cwnd$): Dynamically adjusted based on network conditions.   - ssthresh: The threshold at which TCP switches from exponential growth to linear growth.

• Three Phases:   1. Slow Start: Start with $cwnd = 1\text{\,MSS}$. Double $cwnd$ every RTT (exponential growth) by incrementing for every ACK received. Ends at the first loss event or when reaching $ssthresh$.   2. Congestion Avoidance: $cwnd$ grows linearly. It increases by $1\text{\,MSS}$ per RTT ($MSS imes (MSS/cwnd)$ per ACK).   3. Fast Recovery: Occurs after triple duplicate ACKs.

• Loss Event Responses:   - Timeout: Set $ssthresh = cwnd / 2$, and reset $cwnd = 1\text{\,MSS}$. (TCP Tahoe behavior).   - Triple Duplicate ACK: Set $ssthresh = cwnd / 2$, and set $cwnd = ssthresh + 3\text{\,MSS}$. (TCP Reno behavior).

• AIMD (Additive Increase Multiplicative Decrease):   - Additive Increase: Increase $cwnd$ by $1\text{\,MSS}$ every RTT probing for bandwidth.   - Multiplicative Decrease: Cut $cwnd$ in half on loss detection. This creates a "sawtooth" behavior.

Advanced Congestion Control and Fairness

• Delay-Based Approach (BBR): Aims to keep the pipe "just full enough, but no fuller" to maximize throughput while minimizing delay. It compares measured throughput against uncongested throughput.

• Explicit Congestion Notification (ECN): Network routers mark two bits in the IP header (ToS field) to indicate congestion. The destination informs the sender by setting the ECE bit in an ACK segment.

• Fairness Goals: If $K$ sessions share a link of bandwidth $R$, each should get $R/K$.   - TCP is generally fair under idealized assumptions (same RTT).   - UDP Fairness: Multimedia apps often use UDP to avoid congestion throttling, which can be unfair to TCP flows.   - Parallel Connections: Browsers may open multiple parallel TCP connections to a single host to claim a larger share of the link bandwidth.

Questions & Discussion

• Q: How does the network layer know whether to hand a packet to TCP or UDP?   - A: This is determined by codes/protocols within the Network layer headers.

• Q: How do TCP/UDP know which application to hand the payload to?   - A: They use the port numbers specified in the transport layer header to route data to the correct socket.

• Q: What next? (Homework)   - A: Exploration of a provided pcapng file and the timing diagram of a visit to example.com was suggested as ungraded homework.