Transport Layer Notes

Transport Layer Overview

• Goal: Understand the principles behind transport layer services and Internet transport layer protocols.
  • Services: Multiplexing, demultiplexing, reliable data transfer, flow control, and congestion control.
  • Protocols: UDP (connectionless) and TCP (connection-oriented reliable transport with congestion control).

Transport Layer Roadmap

• Topics include transport-layer services, multiplexing/demultiplexing, UDP, reliable data transfer principles, TCP, congestion control principles, TCP congestion control, and the evolution of transport-layer functionality.

Transport Services and Protocols

• Logical Communication: Transport layer provides logical communication between application processes on different hosts.
• End System Actions:
  • Sender: Breaks application messages into segments and passes them to the network layer.
  • Receiver: Reassembles segments into messages and passes them to the application layer.
• Protocols: TCP and UDP are the two main transport protocols available to Internet applications.

Transport vs. Network Layer

• Network Layer: Focuses on communication between hosts.
• Transport Layer: Focuses on communication between processes, enhancing network layer services.
• Analogy:
  • Hosts are like houses.
  • Processes are like kids.
  • App messages are like letters in envelopes.
  • The transport protocol is like Ann and Bill demultiplexing to in-house siblings.
  • The network-layer protocol is like the postal service.

Transport Layer Actions

• Sender: Receives application-layer message, determines segment header fields, creates segment, and passes segment to IP.
• Receiver: Receives segment from IP, checks header values, extracts application-layer message, and demultiplexes message up to application via socket.

Internet Transport Protocols

• TCP (Transmission Control Protocol):
  • Reliable, in-order delivery.
  • Congestion control.
  • Flow control.
  • Connection setup.
• UDP (User Datagram Protocol):
  • Unreliable, unordered delivery.
  • No-frills extension of best-effort IP.
• Unavailable Services: Delay and bandwidth guarantees.

Multiplexing/Demultiplexing

• Multiplexing at the sender involves handling data from multiple sockets and adding transport headers.
• Demultiplexing at the receiver uses header information to deliver received segments to the correct socket.

Demultiplexing Details

• The host uses IP addresses and port numbers to direct each segment to the appropriate socket.
• Segment Format: Includes source port number, destination port number, and application data.

Connectionless Demultiplexing (UDP)

• When creating a socket, a host-local port number must be specified.
• When a receiving host receives a UDP segment, it checks the destination port number and directs the segment to the socket with that port number.
• To send a datagram into a UDP socket, the destination IP address and port number must be specified.

Connection-Oriented Demultiplexing (TCP)

• TCP socket is identified by a 4-tuple: source IP address, source port number, destination IP address, and destination port number.
• A server may support many simultaneous TCP sockets, each identified by its own 4-tuple.
• Demultiplexing uses all four values to direct the segment to the appropriate socket.

Summary of Multiplexing and Demultiplexing

• Based on segment/datagram header field values.
• UDP uses only the destination port number.
• TCP uses the 4-tuple.
• Multiplexing/demultiplexing occur at all layers.

UDP: User Datagram Protocol

• Characteristics: No frills, bare bones, connectionless.
• Service: Best effort; segments may be lost or delivered out-of-order.
• Simplicity: No connection establishment or state at sender/receiver, small header size, no congestion control.
• Usage: Streaming multimedia apps, DNS, SNMP, HTTP/3.
• Reliability: If required, it must be added at the application layer.

UDP Segment Header

• Includes source port #, destination port #, length, checksum, and application data.

UDP Checksum

• Used for error detection (flipped bits) in the transmitted segment.
• Involves addition (one’s complement sum) of segment contents.
• Weak protection: bit flips can occur without the checksum changing.

Reliable Data Transfer Principles

• Concept: Achieving reliable data transfer over an unreliable channel.
• Complexity: Depends on the characteristics of the unreliable channel.
• Interfaces: rdt_send(), udt_send(), rdt_rcv(), deliver_data().
• Finite State Machines (FSM): Used to specify sender and receiver.

RDT 1.0: Reliable Channel

• Underlying channel is perfectly reliable with no bit errors or packet loss.
• Simple FSMs for sender and receiver.

RDT 2.0: Channel with Bit Errors

• Uses checksums to detect bit errors.
• Acknowledgments (ACKs) and Negative Acknowledgements (NAKs) are used to recover from errors.
• Stop-and-wait approach: sender sends one packet and waits for a response.

RDT 2.0 Issues and Solutions

• Problem: What if ACK/NAK is corrupted?
• Solution: Add sequence number to each packet and discard duplicates.

RDT 2.1: Handling Garbled ACKs/NAKs

• Sender adds a sequence number to each packet (0 or 1).
• Receiver checks if the received packet is a duplicate, using the sequence number.

RDT 2.2: NAK-Free Protocol

• Receiver sends ACK for the last packet received OK, including the sequence number.
• Duplicate ACK at sender results in retransmission.

RDT 3.0: Channels with Errors and Loss

• Underlying channel can lose packets (data, ACKs).
• Approach: Sender waits a reasonable amount of time for ACK and retransmits if no ACK is received (Timeout).

RDT 3.0: Stop-and-Wait Operation

• Sender sends a packet and waits for ACK before sending the next one.
• If a packet or ACK is lost, the sender retransmits after a timeout.
• Performance can be poor due to underutilization of the channel.
• $U_{sender} = \frac{L/R}{RTT + L/R}$
  • Where $U_{sender}$ is sender utilization,
  • $L$ is the packet size in bits,
  • $R$ is the transmission rate in bits per second, and
  • $RTT$ is the round trip time.

Pipelined Protocols

• Sender allows multiple in-flight, yet-to-be-acknowledged packets.
• Requires increased range of sequence numbers and buffering at sender/receiver.
• Increases utilization.
• $U_{sender} = \frac{n \cdot L/R}{RTT + L/R}$
  • Where $U_{sender}$ is sender utilization,
  • $L$ is the packet size in bits,
  • $R$ is the transmission rate in bits per second, and
  • $RTT$ is the round trip time.
  • $n$ is the number of packets.

Go-Back-N

• Sender maintains a "window" of up to N consecutive unacknowledged packets.
• Cumulative ACK: ACK(n) acknowledges all packets up to and including sequence number n.
• Timeout(n): retransmit packet n and all higher sequence number packets in the window.

Selective Repeat

• Receiver individually ACKs all correctly received packets and buffers packets for in-order delivery.
• Sender maintains a timer for each unacknowledged packet and retransmits single un-ACKed packets after timeout.

TCP: Transmission Control Protocol Overview

• Reliable, in-order byte stream.
• Point-to-point: one sender, one receiver.
• Full-duplex data: bi-directional data flow in the same connection.
• Multiplexing/demultiplexing data from/to multiple applications.
• Cumulative ACKs.
• Pipelining with congestion and flow control。
• Connection-oriented with handshaking.

TCP Segment Structure

• Includes source port #, destination port numbers, sequence number, acknowledgment number, header length, checksum, and data.

TCP Sequence Numbers and ACKs

• Sequence numbers: Byte stream number of the first byte in the segment's data.
• Acknowledgements: Sequence number of the next byte expected from the other side (cumulative ACK).

TCP Round Trip Time (RTT) and Timeout

• Estimates RTT using SampleRTT and EWMA: $EstimatedRTT = (1 - \alpha) \cdot EstimatedRTT + \alpha \cdot SampleRTT$ where $\alpha$ is typically 0.125.
• Calculates TimeoutInterval using EstimatedRTT and DevRTT: $TimeoutInterval = EstimatedRTT + 4 \cdot DevRTT$.
• Where $DevRTT = (1 - \beta) \cdot DevRTT + \beta \cdot |SampleRTT - EstimatedRTT|$ and $\beta$ is typically 0.25

TCP Sender Actions

• Data received from the application: Create segment with sequence number and start timer if not already running.
• Timeout: Retransmit segment that caused the timeout and restart timer.
• ACK received: Update what is known to be ACKed and start timer if there are still un-ACKed segments.

TCP Receiver: ACK Generation

• Generates delayed ACKs, single cumulative ACKs, and duplicate ACKs based on the arrival of segments.

TCP Retransmission Scenarios

• Handles lost ACKs, premature timeouts, and cumulative ACKs to ensure reliability.
• The TCP fast retransmit approach resends the unACKed segment with smallest sequence number upon receiving three duplicate ACKs.

TCP Flow Control

• The receiver controls the sender, so the sender does not overwhelm the receiver's buffer by transmitting too much, too fast.
• TCP Receiver "advertises" free buffer space in the rwnd field in the TCP header.
• Sender limits the amount of un-ACKed ("in-flight") data to the received rwnd to prevent overflow.

TCP Connection Management

• Before data exchange, sender and receiver "handshake" to agree to establish a connection and agree on connection parameters.
• clientSocket = newSocket("hostname","port number")
• connectionSocket = welcomeSocket.accept()
• Three-way handshake is used for connection establishment.

Congestion Control Principles

• Congestion occurs when too many sources send too much data too fast for the network to handle.
• Causes include long delays and packet loss.

Causes and Costs of Congestion

• Scenarios demonstrate maximum throughput, retransmissions, and wasted capacity due to congestion.

Approaches to Congestion Control

• End-end congestion control: no explicit feedback; congestion inferred from observed loss or delay (e.g., TCP).
• Network-assisted congestion control: routers provide direct feedback to hosts.

TCP Congestion Control: AIMD (Additive Increase Multiplicative Decrease)

• Senders increase sending rate until packet loss occurs, then decrease sending rate upon loss.
• On loss detected by triple duplicate ACK (TCP Reno) the sending rate is cut in half
• on loss detected by timeout (TCP Tahoe) the sending rate is set to 1 MSS
• Shown to optimize congested flow rates and have desirable stability properties.

TCP Congestion Control: Slow Start

• When the connection begins, the sending rate is increased exponentially until the first loss event occurs.
• $cwnd$ = 1MSS
• $cwnd$ is doubled every $RTT$.

TCP: Slow Start to Congestion Avoidance

• The exponential increase switches to linear when $cwnd$ gets to 1/2 of its value before timeout.
• Variable ssthresh: on a loss event, ssthresh is set to 1/2 of cwnd before the loss event.

Summary: TCP Congestion Control

• Involves slow start, congestion avoidance, and fast recovery mechanisms to adjust the sending rate.

TCP Cubic

• Cubic increases throughput in the following way:
  • Wmax: sending rate at which congestion loss was detected
  • congestion state of bottleneck link probably (?) hasn’t changed much
  • after cutting rate/window in half on loss, initially ramp to to Wmax faster, but then approach Wmax more slowly

Explicit congestion notification (ECN)

• Involves bits in the IP header (ToS field) marked by a network router to indicate congestion
• congestion indication carried to destination
• destination sets ECE bit on ACK segment to notify sender of congestion

TCP fairness

• If K TCP sessions share the same bottleneck link of bandwidth R, each should have an average rate of R/K

Evolving Transport-Layer Functionality

• HTTP/3 with QUIC

QUIC (Quick UDP Internet Connections) Summary

• Multiplexes multiple application-level "streams" over a single QUIC connection with separate reliable data transfer and security. QUIC also has common congestion control.
• Has connection establishment, error control, congestion control.
• Improves upon connection setup, as TCP requires 2 serial handshakes. Quic combines into one.

Chapter 3 Summary

• Discussed the principles behind transport layer services and instantiation, implementation in the Internet with UDP and TCP.