Unit 5: Transport Layer and Congestion Control

I. Orientation — End-to-End Process Communication

The transport layer is Layer 4 of the OSI model and lies between application-layer protocols and the network layer. Its governing principle is logical end-to-end communication between application processes: the network layer delivers packets between hosts, while the transport layer identifies processes, manages data transfer, and may provide reliability, ordering, flow control, and congestion control.

• Protocol data unit: A transport-layer message is generally called a segment in TCP and a datagram in UDP.
• Endpoints: Communication is identified using socket addresses, commonly represented as (IP address, port number).
• Multiplexing: Data from multiple application processes can share the same network-layer service.
• Demultiplexing: At the receiver, destination port numbers direct incoming data to the correct application process.
• Primary Internet protocols:
  • TCP: Connection-oriented, reliable, ordered, byte-stream transport.
  • UDP: Connectionless, best-effort, message-oriented transport.
• End-system implementation: Transport protocols operate mainly in hosts, whereas routers primarily process network-layer packets.
• Control responsibilities: Transport mechanisms can regulate both the receiver’s capacity through flow control and the network’s capacity through congestion control.

II. Layer Relationship — Host Delivery versus Process Delivery

A. Relationship between Transport and Network Layer

The network and transport layers cooperate, but they provide communication at different scopes.

• Network-layer role: IP provides logical communication between hosts across interconnected networks using source and destination IP addresses.
• Transport-layer role: TCP or UDP extends host-to-host delivery into process-to-process delivery using port numbers.
• Service dependency: The transport layer uses the network layer rather than replacing it; each TCP segment or UDP datagram is encapsulated inside an IP packet.
• Encapsulation path:
  
  TEXT

    Application data
        -> TCP segment or UDP datagram
        -> IP packet
        -> Data-link frame

• Router visibility: Ordinary routers forward IP packets without maintaining TCP connection state or delivering data to applications.
• Reliability distinction: IP is best-effort, but TCP can create reliable service above it through sequence numbers, acknowledgements, checksums, timers, and retransmissions.
• Addressing example: In 192.0.2.10:51500 -> 198.51.100.7:443, the IP addresses identify hosts, while ports 51500 and 443 identify the client and HTTPS server processes.
• Design consequence: Transport services can evolve at end hosts without requiring every intermediate router to implement the same reliability mechanism.

III. End-to-End Functions — Services for Applications

A. Transport Layer Services

Transport-layer services determine how application data is identified, transferred, protected, and presented to the receiving process.

• Process addressing: A 16-bit port field provides values from 0 through 65,535; well-known server ports include TCP 80 for HTTP and TCP 443 for HTTPS.
• Segmentation and reassembly: Large application data is divided into transport units and reconstructed at the destination.
• Multiplexing and demultiplexing: Many sockets can communicate concurrently through one host’s network interface.
• Connection management: TCP establishes, maintains, and terminates logical connections; UDP sends without connection establishment.
• Reliable delivery: TCP detects loss or corruption, retransmits missing data, suppresses duplicates, and delivers bytes in order.
• Error detection: TCP and UDP include checksums covering their headers and data; an invalid checksum normally causes the unit to be discarded.
• Flow control: TCP’s receiver-advertised window prevents a fast sender from overwhelming a slow receiver.
• Congestion control: TCP adjusts its sending rate according to inferred network conditions.
• Service choice:
  1. TCP favors reliability and ordered delivery for web transfers, email, and file transfer.
  2. UDP favors low overhead and application-controlled timing for DNS, real-time media, and online games.

IV. Transport Performance — Delay, Capacity, and Reliability Costs

A. Performance issues

Transport performance depends on network capacity, path delay, loss, protocol overhead, endpoint processing, and control algorithms.

• Throughput: The useful-data delivery rate is measured in bit/s and cannot exceed the path’s bottleneck bandwidth.
• Goodput: Goodput excludes headers, retransmissions, and duplicate data, so it is lower than raw throughput.
• Latency components:
  
  TEXT

    Dtotal = Dprocessing + Dqueueing + Dtransmission + Dpropagation

  
  Here, each D is a delay in seconds; transmission delay equals packet size in bits divided by link rate in bit/s.
• Bandwidth-delay product:
  
  TEXT

    BDP = R x RTT

  
  R is the bottleneck rate in byte/s and RTT is round-trip time in seconds. Approximately one BDP of unacknowledged data is needed to fully utilize a path.
• Window limitation: TCP throughput is approximately bounded by W/RTT, where W is the usable window in bytes.
• Loss cost: Packet loss triggers retransmission and may reduce TCP’s congestion window, decreasing throughput beyond the cost of the lost packet itself.
• Head-of-line blocking: TCP withholds later bytes from the application until an earlier missing byte is recovered.
• Trade-off: Larger buffers absorb bursts but can produce excessive queueing delay, often called bufferbloat.

V. TCP Segment Structure — Control over a Byte Stream

A. TCP header format

A TCP header carries endpoint identifiers, byte positions, control flags, windows, and integrity information; its minimum size is 20 bytes.

0                   15 16                  31
+---------------------+---------------------+
| Source Port         | Destination Port    |
+---------------------+---------------------+
| Sequence Number                           |
+-------------------------------------------+
| Acknowledgement Number                    |
+----+------+----------+---------------------+
|HLEN|Flags | Window Size                    |
+---------------------+---------------------+
| Checksum            | Urgent Pointer      |
+---------------------+---------------------+
| Options and Padding, if present            |
+-------------------------------------------+

• Ports: Two 16-bit fields identify the sending and receiving processes.
• Sequence number: A 32-bit value identifies the first data byte carried in the segment; with SYN=1, it represents the initial sequence number.
• Acknowledgement number: With ACK=1, this 32-bit value states the next byte expected, making TCP acknowledgements cumulative.
• Header length: The data offset gives the header size in 32-bit words; value 5 means 5 x 4 = 20 bytes.
• Principal flags: SYN establishes sequence-number synchronization, ACK validates the acknowledgement field, FIN closes normally, and RST aborts a connection.
• Window size: The 16-bit advertised receive window supports flow control; window scaling can extend its effective range.
• Checksum: Detects corruption using the TCP header, payload, and an IP-derived pseudo-header.
• Options: Common options include Maximum Segment Size, window scale, selective acknowledgement, and timestamps.

VI. TCP Connection Establishment — Synchronizing Both Endpoints

A. TCP handshaking operation

TCP uses a three-way handshake to confirm bidirectional reachability, synchronize initial sequence numbers, and establish connection state.

1. SYN: Client sends SYN=1 with initial sequence number x.
2. SYN-ACK: Server sends SYN=1, ACK=1, its sequence number y, and acknowledgement x+1.
3. ACK: Client sends ACK=1, sequence number x+1, and acknowledgement y+1.

Client                                  Server
SYN, Seq=x ---------------------------->
              <---------------- SYN-ACK, Seq=y, Ack=x+1
ACK, Seq=x+1, Ack=y+1 ----------------->

• Sequence consumption: Each SYN consumes one sequence number even if it carries no application data.
• State transitions: A typical client moves from CLOSED to SYN-SENT to ESTABLISHED; the server moves from LISTEN to SYN-RECEIVED to ESTABLISHED.
• Negotiation: TCP options such as MSS, window scaling, timestamps, and selective acknowledgement capability are exchanged in handshake segments.
• Duplicate protection: Fresh initial sequence numbers help distinguish current traffic from delayed segments belonging to an older connection.
• Failure handling: If a handshake segment is lost, TCP retransmits after a timeout; an unavailable port commonly responds with RST.
• Termination distinction: Normal closure generally exchanges FIN and ACK in each direction because TCP is full duplex.

VII. UDP Datagram Structure — Minimal Connectionless Transport

A. UDP header format

UDP provides message-oriented transport with an 8-byte header and no built-in connection establishment, retransmission, ordering, or congestion control.

0                   15 16                  31
+---------------------+---------------------+
| Source Port         | Destination Port    |
+---------------------+---------------------+
| Length              | Checksum            |
+---------------------+---------------------+
| Application Data                          |
+-------------------------------------------+

• Source port: A 16-bit reply port; in IPv4 it may be zero when no reply is expected.
• Destination port: A 16-bit value identifying the destination application.
• Length: Gives the total UDP header-plus-data size in bytes; its minimum valid value is 8.
• Checksum: Covers a pseudo-header, UDP header, and payload; it is mandatory in IPv6 and optional in IPv4.
• Message boundaries: One send operation normally corresponds to one datagram, unlike TCP’s continuous byte stream.
• Low overhead: No handshake and a fixed 8-byte header reduce setup delay and protocol overhead.
• Application responsibility: If reliability, ordering, rate adaptation, or duplicate suppression is required, the application protocol must supply it.
• Practical use: A DNS query often fits in one UDP datagram, allowing a request and response without TCP connection setup.

VIII. Explicit Network Feedback — Router-Supported Regulation

A. Network-assisted Congestion Control Algorithms

Network-assisted congestion control uses information from routers or switches to warn endpoints or directly regulate offered traffic.

• Congestion meaning: Congestion occurs when packet arrival demand exceeds network resources, causing growing queues, delay, drops, and reduced useful throughput.
• Binary feedback: A router marks or signals whether congestion exists; the source then lowers its rate.
• Explicit Congestion Notification: ECN-capable IP packets may be marked Congestion Experienced instead of dropped; the receiver echoes the indication to the TCP sender.
• Explicit-rate feedback: A router can communicate an allowed sending rate, enabling the source to adjust more directly than with binary signals.
• Choke packets: A router-generated control packet asks a source to reduce traffic toward a congested destination.
• Hop-by-hop control: Each upstream router reduces traffic, allowing congestion relief to propagate toward the source.
• Queue management: Active Queue Management schemes such as RED probabilistically mark or drop packets before a queue becomes full.
• Advantages: Earlier and more precise signals can reduce packet loss, queueing delay, and oscillation.
• Limitations: Benefits depend on router support, compatible endpoints, correct parameter tuning, and resistance to misleading or ignored feedback.

IX. End-System Adaptation — TCP’s Congestion Window

A. TCP Congestion Control

TCP infers available capacity from acknowledgements, loss, delay, or ECN and limits outstanding data using a congestion window.

Usable send window = min(cwnd, rwnd)

Here, cwnd is the sender’s congestion window and rwnd is the receiver-advertised flow-control window, both measured in bytes.

• Slow start: TCP begins with a limited cwnd; acknowledgements increase it rapidly, producing approximately exponential growth per RTT until a threshold or congestion signal is reached.
• Congestion avoidance: Above ssthresh, classic TCP uses additive increase, raising cwnd by roughly one MSS per RTT.
• Timeout response: A retransmission timeout indicates serious congestion; classic behavior sets ssthresh near half the flight size and restarts with a small cwnd.
• Fast retransmit: Three duplicate acknowledgements suggest one segment is missing while later segments are arriving, so TCP retransmits without waiting for the timer.
• Fast recovery: TCP reduces its window after duplicate-ACK loss but avoids returning completely to the initial slow-start condition.
• AIMD principle: Additive Increase, Multiplicative Decrease probes gradually for capacity and cuts the sending window sharply after congestion.
• Flow-control distinction: rwnd protects the receiving host, whereas cwnd protects the network; the smaller one governs transmission.
• Modern variants: Reno is predominantly loss-based, CUBIC uses a cubic window-growth function, and BBR estimates bottleneck bandwidth and round-trip propagation time.
• Fairness objective: Competing well-behaved TCP flows should converge toward reasonable shares of a bottleneck, although RTT differences and algorithm choices can affect the result.