ScholarGate
Asystent

Transport Layer and Congestion Control

The transport layer extends host-to-host delivery into process-to-process communication, offering applications either reliable, ordered, congestion-controlled byte streams (TCP) or lightweight connectionless datagrams (UDP), while congestion control regulates sending rates so the shared network does not collapse.

Znajdź temat z PaperMindWkrótceFind papers & topics
Tools & resources
Pobierz slajdy
Learn & explore
WideoWkrótce

Definition

The transport layer is the protocol layer that provides logical communication between application processes running on different hosts, adding services such as multiplexing, reliable delivery, flow control, and congestion control on top of the network layer's host-to-host delivery.

Scope

This area covers end-to-end transport services: multiplexing and demultiplexing of data to application processes, the principles of reliable data transfer over an unreliable network (acknowledgments, retransmission, sequence numbers, sliding windows), the connection-oriented Transmission Control Protocol and the connectionless User Datagram Protocol, and the theory and practice of congestion control. It excludes the routing of packets across the network (network layer) and the application protocols that use transport services (application layer).

Sub-topics

Core questions

  • How does the transport layer deliver data to the correct application process via multiplexing and demultiplexing?
  • How can reliable, in-order delivery be built over an unreliable, lossy network?
  • How do TCP's connection setup, flow control, and reliability mechanisms work?
  • When should an application use UDP instead of TCP?
  • How does congestion control detect and respond to network overload while remaining fair?

Key concepts

  • multiplexing and demultiplexing
  • ports and sockets
  • reliable data transfer
  • sliding window, go-back-N, selective repeat
  • TCP three-way handshake
  • flow control
  • congestion control
  • additive-increase/multiplicative-decrease (AIMD)
  • slow start and congestion avoidance
  • User Datagram Protocol (UDP)

Key theories

Reliable data transfer over an unreliable channel
Reliability is built from acknowledgments, retransmission timers, sequence numbers, and sliding-window protocols (go-back-N and selective repeat) that detect and recover from loss, duplication, and reordering despite an unreliable underlying network.
TCP congestion control
TCP infers congestion from packet loss and adjusts its sending window with additive-increase/multiplicative-decrease dynamics — slow start, congestion avoidance, and fast recovery — to probe for available bandwidth while backing off sharply on loss.
Connectionless versus connection-oriented transport
UDP offers a thin, connectionless service with no setup, reliability, or congestion control, minimizing delay and overhead, while TCP offers a connection-oriented, reliable, congestion-controlled byte stream; the choice trades latency and control for guarantees.

Clinical relevance

Transport-layer behavior shapes the performance of nearly every networked application: TCP carries web, email, and file transfers reliably, while UDP underpins low-latency uses such as DNS, real-time voice and video, and many games. Congestion control is what has kept the Internet from collapsing under load since the late 1980s, and ongoing work on algorithms such as CUBIC and BBR and protocols such as QUIC continues to tune the latency-throughput-fairness balance.

History

TCP and IP were originally one protocol in the 1974 Cerf-Kahn design and were later split, with UDP (RFC 768, 1980) added for applications needing only basic datagram service. After a series of congestion collapses on the early Internet, Van Jacobson's 1988 work introduced the slow-start and congestion-avoidance algorithms that remain the foundation of TCP congestion control, refined over decades into variants such as Reno, CUBIC, and BBR.

Debates

Loss-based versus delay-based and model-based congestion control
Classic TCP infers congestion from packet loss, which can underutilize high-bandwidth, high-latency links and react late, prompting delay-based and model-based algorithms such as BBR; debate continues over fairness and deployability when such algorithms coexist with loss-based ones.

Key figures

  • Van Jacobson
  • Jon Postel
  • Vinton Cerf
  • Sally Floyd

Related topics

Seminal works

  • kurose2021
  • jacobson1988
  • rfc9293

Frequently asked questions

When should I use UDP instead of TCP?
Use UDP when low latency matters more than guaranteed delivery and you can tolerate or handle loss yourself — for example real-time voice/video, DNS queries, or games. Use TCP when you need reliable, ordered delivery and built-in congestion control, such as for web pages, file transfers, and email.
What does congestion control actually do?
Congestion control adjusts how fast a sender injects data into the network based on signals of congestion, typically packet loss or delay. By backing off when the network is overloaded and probing for spare capacity otherwise, it keeps aggregate traffic near the network's capacity and shares bandwidth roughly fairly among flows.

Methods for this concept

Related concepts