5. Advanced Transport Protocols and Congestion Control

Introduction and Context

The transport layer provides communication between processes running on different hosts. Unlike the network layer, which attempts to deliver packets between endpoints, the transport layer must often deliver application data with appropriate guarantees concerning reliability, ordering, flow control, multiplexing, and performance. These responsibilities become increasingly difficult when networks are fast, wireless, lossy, mobile, or shared by many competing flows.

The familiar User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) represent two important design choices. UDP offers a minimal datagram service, while TCP provides a reliable, ordered byte stream with feedback-driven congestion control. Stream Control Transmission Protocol (SCTP) adds message orientation, multistreaming, and multihoming. QUIC, developed over UDP, combines reliable transport functions with encrypted sessions, independently delivered streams, and rapid connection establishment.

Transport protocols cannot simply maximize sending rate. A sender must distinguish between receiver limitations and network limitations. Flow control protects the receiver; congestion control protects the network. The distinction is fundamental: a receiver may have insufficient buffer space even when the network is uncongested, while a network may be overloaded even though the receiver can accept more data.

This chapter examines the architecture and behavior of UDP, TCP, SCTP, and QUIC; the principles of reliability, flow control, and congestion control; fairness and performance in high-speed and lossy environments; and the practical choices involved in selecting and tuning a transport protocol.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Compare UDP, TCP, SCTP, and QUIC in terms of service model, reliability, ordering, security, and deployment.

2. Explain acknowledgements, retransmission, sequencing, receive windows, and selective loss recovery.

3. Distinguish flow control from congestion control and interpret their interaction.

4. Analyze major TCP congestion-control mechanisms, including slow start, congestion avoidance, fast retransmit, and fast recovery.

5. Explain fairness, active queue management, explicit congestion notification, and modern congestion-control approaches.

6. Evaluate transport performance over high-bandwidth, long-delay, wireless, and lossy networks.

7. Describe multistreaming and multipath transport and identify their practical trade-offs.

8. Select an appropriate transport design for real-world applications and recognize operational, security, and governance concerns.

Transport Service Models: Four Different Design Commitments

A transport protocol is best understood not merely by its packet format but by the service it exposes to applications.

UDP: Minimal datagram delivery

UDP is connectionless and message-oriented. Each application write is normally represented as one datagram, subject to the path maximum transmission unit and implementation limits. UDP does not guarantee delivery, ordering, duplicate suppression, or retransmission. It includes source and destination ports and a checksum, but leaves most reliability and rate adaptation to the application.

This minimalism is valuable when the application can tolerate loss, requires low latency, or implements its own control logic. Domain Name System queries, real-time media, online games, telemetry, and protocols such as QUIC use UDP as a foundation. However, UDP itself does not make an application congestion-friendly. An application that continuously transmits without feedback can contribute to queue growth and unfairness.

TCP: A reliable ordered byte stream

TCP establishes a logical connection and presents an ordered byte stream. It numbers bytes rather than application messages, acknowledges received data, retransmits segments believed to be lost, and uses a receive window to limit outstanding data. The sender’s usable sending window is approximately the smaller of the congestion window and the advertised receive window:

`Sending window = min(cwnd, rwnd)`

where `cwnd` reflects the sender’s estimate of network capacity and `rwnd` reflects receiver capacity.

TCP’s byte-stream abstraction is convenient for files, web objects, remote login, and database connections. It can, however, create head-of-line blocking: if one segment is missing, later bytes cannot be delivered to the application in order even if they have already arrived.

SCTP: Reliable messages with multiple streams

SCTP is connection-oriented but message-oriented. It preserves message boundaries, supports multistreaming, and can associate multiple network addresses with one association through multihoming. Separate streams reduce application-level head-of-line blocking because loss in one stream need not stop delivery in another.

SCTP uses a four-way association setup involving a cookie mechanism, which helps resist certain resource-exhaustion attacks. It is useful in signaling systems and specialized resilient services, although middlebox support and deployment familiarity have historically been less universal than TCP and UDP.

QUIC: Encrypted, multiplexed transport over UDP

QUIC implements reliable transport functions in user space over UDP. It integrates TLS 1.3 security into connection establishment, supports multiple independent streams, uses connection identifiers, and can recover from changes in network addresses more gracefully than conventional TCP connections. QUIC’s streams avoid one lost packet from blocking unrelated streams at the transport-delivery level.

QUIC is particularly important for modern web traffic through HTTP/3. Its advantages include reduced handshake latency, encrypted transport metadata in many fields, rapid version evolution, and deployability without operating-system TCP changes. Its user-space implementation also permits faster experimentation, though it increases implementation responsibility and can create CPU and observability costs.

Reliability as a Feedback Process

Reliable transport is not equivalent to sending every packet again whenever an acknowledgement is absent. It is a feedback process based on sequence numbers, acknowledgements, timers, and receiver reports.

A sender assigns sequence information to transmitted data. The receiver acknowledges data received successfully. Cumulative acknowledgements indicate that all data up to a particular point has arrived. Selective acknowledgements identify additional non-contiguous blocks, allowing the sender to retransmit only missing data rather than an entire range.

Retransmission timers must reflect the path’s round-trip time (RTT), which varies with queueing and route conditions. A timer that is too short causes unnecessary retransmissions; one that is too long delays recovery. TCP estimates a smoothed RTT and its variation, using both to calculate a retransmission timeout with a safety margin. QUIC performs similar estimation while exposing acknowledgements and loss detection through its own packet-number spaces.

Not every loss has the same cause. Congestion, wireless corruption, device handoff, routing changes, receiver limitations, and reordering may all produce missing acknowledgements. A transport protocol must recover promptly without interpreting every unusual event as persistent congestion. This is difficult on wireless paths, where a congestion response to non-congestion loss may unnecessarily reduce throughput.

Reliability also involves duplicate detection and connection semantics. A protocol must prevent delayed packets from an earlier connection from being interpreted as current data. Handshakes, sequence spaces, connection identifiers, and cryptographic validation help establish communication context safely.

Flow Control and Congestion Control

Flow control is end-to-end protection for the receiver. If an application reads slowly, the receiver advertises a smaller window. The sender must not exceed that credit. Window scaling is important on high-bandwidth-delay paths because a small fixed window cannot keep enough data in flight to fill the path.

The bandwidth-delay product (BDP) estimates the amount of data required to keep a path busy:

`BDP = bandwidth × RTT`

For example, a 1-Gb/s path with a 100-ms RTT has a BDP of approximately 12.5 MB. A receiver window of only 64 KB would severely limit throughput, even if the network and sender were capable of much more.

Congestion control is network protection. The sender infers congestion from signals such as packet loss, increasing delay, explicit congestion notification, or acknowledgements that indicate reduced progress. It adjusts the congestion window so that queues do not grow without bound and competing flows can share capacity.

The two controls interact. If `rwnd` is smaller than `cwnd`, the receiver limits transmission. If `cwnd` is smaller, the network estimate is the active constraint. Diagnosing performance therefore requires inspecting both windows rather than assuming that low throughput is caused by congestion.

TCP Congestion Control: From Conservative Start to Steady Operation

TCP congestion control is traditionally described through four related mechanisms.

Slow start

At the beginning of a connection, the sender has little knowledge of path capacity. The congestion window begins conservatively and grows rapidly, approximately doubling each RTT when acknowledgements arrive successfully. This exponential phase is called slow start, although its growth can be aggressive on modern networks. It ends when the congestion window reaches a slow-start threshold or when congestion is detected.

Congestion avoidance

After the initial probing phase, TCP generally increases its congestion window more gradually, often approximating additive increase. The objective is to discover additional capacity while limiting sudden queue growth.

Loss response

A retransmission timeout is usually treated as a stronger congestion signal than duplicate acknowledgements. The sender reduces its sending rate substantially and may re-enter slow start. Multiple duplicate acknowledgements, by contrast, can indicate that later data arrived while an earlier segment was missing. Fast retransmit resends the suspected missing segment without waiting for the timer. Fast recovery attempts to maintain useful transmission while reducing the congestion window.

Algorithms and design philosophies

Reno-style algorithms use loss as the principal congestion signal. Newer algorithms differ in how they estimate capacity and respond to delay. CUBIC uses a cubic growth function designed to scale on high-speed paths and to make recovery less dependent on RTT than traditional additive increase. BBR estimates bottleneck bandwidth and minimum RTT, attempting to operate near an efficient delivery rate rather than treating loss as the primary indicator of congestion.

No algorithm is universally best. Loss-based methods can fill buffers and create delay before loss occurs. Delay-sensitive methods may react to queueing earlier but can be disadvantaged when competing with aggressive loss-based flows. BBR versions and implementations have evolved, and their fairness depends on configuration, bottleneck behavior, and the traffic mix.

Fairness, Queues, and Explicit Signals

Fairness concerns how a shared bottleneck divides capacity among flows. A simple ideal is equal sharing among comparable flows, but real fairness depends on RTT, packet size, application behavior, protocol algorithm, and the number of parallel connections. A user opening many flows may obtain more capacity than one using a single flow, even when both use the same algorithm.

A common analytical measure is Jain’s fairness index:

`J = (sum xi)^2 / (n × sum xi^2)`

where `xi` is the throughput of flow `i` and `n` is the number of flows. The index approaches 1 for equal allocation and becomes smaller as allocation becomes uneven. Fairness is an evaluation tool, not a complete definition of network quality; a highly fair system may still have excessive delay or poor utilization.

Large buffers can prevent packet loss but create bufferbloat: interactive traffic experiences high delay because packets wait in long queues. Active Queue Management (AQM) attempts to control queues by marking or dropping packets before buffers become full. Random Early Detection is an earlier approach; modern deployments may use schemes such as CoDel or PIE, which focus more explicitly on managing delay.

Explicit Congestion Notification (ECN) allows a capable router to mark packets rather than discard them when congestion begins. The receiver reports the mark, and the sender reduces its rate. ECN requires support across endpoints and network devices, and it must be correctly configured and secured against misleading signals.

Performance on High-Speed, Long-Delay, and Lossy Paths

High-speed long-distance networks expose limitations that are not obvious in local networks. A large BDP requires large socket buffers, window scaling, efficient acknowledgement processing, and sufficient host memory. CPU interrupts, copy operations, encryption, and operating-system scheduling may become bottlenecks even when the link is underused.

Loss is especially expensive when RTT is large. A single lost segment can interrupt progress for at least one RTT, and timeout-based recovery can be much slower. Selective acknowledgements, accurate loss detection, pacing, and parallel streams reduce this penalty. Packet pacing spreads transmissions over time instead of releasing a large burst whenever an acknowledgement arrives, thereby reducing queue spikes.

Wireless and mobile networks add variable capacity, handoffs, radio contention, and non-congestion losses. A transport that responds to every loss by sharply reducing its window may underuse the path. Link-layer recovery can conceal some wireless errors, while end-to-end transport still needs robust loss detection. QUIC’s connection identifiers can allow a connection to survive changes in the client’s network address, but mobility does not eliminate the need for congestion estimation after a path change.

Satellite and other high-latency systems require careful timer and buffer configuration. Short-lived transfers may spend a large fraction of their time in handshakes. Connection reuse, session resumption, and reduced handshake exchanges are therefore important. At the same time, large initial transmission windows must be used responsibly because many clients sharing a high-delay bottleneck can create bursts.

Multistreaming and Multipath Transport

Multistreaming separates logically independent data sequences. In SCTP, streams within one association have their own ordering contexts. QUIC provides multiple streams over a connection, with retransmission of lost packets but independent stream delivery. This is valuable for web pages, where a delayed object should not necessarily block unrelated objects.

Multipath transport uses more than one network path simultaneously or maintains alternative paths for resilience. Multipath TCP (MPTCP) extends TCP with subflows that can use different interfaces, such as Wi-Fi and cellular. It can improve aggregate throughput, preserve a session during interface changes, or shift traffic according to cost and energy policies. Multipath QUIC is an active area of development and standardization, but deployment and scheduling remain complex.

A multipath scheduler must consider path capacity, RTT, loss, energy, monetary cost, and reordering. Sending traffic across paths with very different delays may increase out-of-order delivery. A scheduler that selects only the fastest path may waste backup capacity; one that always uses every path may consume expensive or unstable links. Security also matters because path validation is needed to prevent an attacker from redirecting traffic toward an unintended address.

Choosing Among UDP, TCP, SCTP, and QUIC

Protocol selection should begin with application requirements rather than popularity.

TCP is appropriate when reliable ordered delivery and broad compatibility matter more than message boundaries or independent streams. UDP is appropriate when the application needs datagrams and can tolerate or explicitly manage loss, ordering, and rate control. SCTP is attractive where message boundaries, multistreaming, multihoming, and association-level reliability are central. QUIC is compelling for encrypted, multiplexed application protocols requiring rapid setup, connection migration, and user-space evolution.

An application using UDP must not interpret low protocol overhead as permission to ignore congestion control. Real-time media may use adaptive bitrate selection, pacing, forward error correction, and selective retransmission. Interactive games may prioritize timely state updates over delivery of obsolete packets. A telemetry system may use sequence numbers and application acknowledgements while limiting its sending rate.

In enterprise environments, protocol choice also depends on firewalls, load balancers, observability tools, operating-system support, compliance requirements, and incident-response capability. QUIC’s encryption improves confidentiality but can make legacy network inspection more difficult. Organizations should use approved logging and endpoint telemetry rather than weakening security merely to recover visibility.

Illustrative Case Study: Migrating a Web Service to HTTP/3

Background

A fictional global retail platform operates a web service accessed by users on fiber, public Wi-Fi, and mobile networks. Its original architecture uses HTTPS over TCP. The service is reliable, but users report slow page completion when networks are congested or when a mobile device changes connectivity.

Situation and problem

The page contains many independent resources. Packet loss on the TCP connection delays delivery of later bytes, even when those bytes belong to resources that could otherwise be processed. TLS and transport setup also impose latency on short sessions. Engineers must determine whether migrating to HTTP/3 over QUIC will improve user experience without creating unacceptable operational risk.

Analysis

Measurements show that the greatest delays occur on paths with variable RTT and occasional loss. The service already has sufficient origin capacity, so adding servers will not address the transport bottleneck. The team identifies three relevant mechanisms: QUIC’s independent streams can reduce cross-resource blocking; connection identifiers can support migration during address changes; and integrated TLS can reduce setup exchanges when resumption is possible.

However, the team also recognizes constraints. QUIC requires UDP reachability, consumes CPU for encryption and packet processing, and may be treated differently by some middleboxes. A fallback to TCP-based HTTPS remains necessary. Congestion-control behavior must be monitored rather than assumed to be universally superior.

Approach

The organization enables HTTP/3 for a controlled percentage of clients. It retains HTTP/2 over TCP as a fallback and uses consistent application-level metrics for both paths: connection establishment time, time to first byte, page completion time, retransmission and loss indicators, CPU cost, error rate, and fairness across access networks.

The QUIC deployment uses conservative pacing and validated connection migration. Operators configure dashboards that distinguish receiver-window limitation, congestion-window limitation, server processing delay, and path loss. Security teams review UDP exposure, denial-of-service protections, certificate handling, and logging requirements.

Outcome

The trial shows the greatest benefit for users experiencing moderate loss and address changes. Users on stable, low-latency networks see smaller gains. During one deployment phase, excessive server CPU usage appears because packet processing scales differently from the previous TCP stack; worker allocation and batching are then tuned. The organization adopts QUIC as an additional protocol rather than treating it as a universal replacement.

Learning points

The case demonstrates that transport migration is a systems decision. Protocol features must be evaluated against workload structure, path conditions, host cost, middlebox behavior, security controls, and fallback design. Performance claims should be based on measurements segmented by network type, not on a single average.

Risks, Limitations, and Common Mistakes

A frequent mistake is confusing reliability with suitability. Retransmitting every lost real-time frame may increase delay and deliver data after it is no longer useful. Another is increasing socket buffers indefinitely: large buffers may improve utilization on high-BDP paths but can also consume memory and contribute to queueing.

Opening many parallel TCP connections can increase aggregate throughput while damaging fairness and increasing server state. Similarly, an application built on UDP may accidentally become an unresponsive, high-rate source if it lacks pacing and congestion feedback. Treating packet loss as the only congestion signal can perform poorly in networks that use ECN or experience delay-based queueing.

QUIC and other encrypted transports reduce the visibility available to middleboxes. This is beneficial for confidentiality but complicates traffic classification, troubleshooting, and policy enforcement. Operators should avoid unauthorized decryption and should establish privacy-preserving telemetry, endpoint instrumentation, and clear data-retention policies.

Transport attacks include SYN resource exhaustion, spoofed packets, acknowledgement manipulation, connection migration abuse, amplification attacks, and denial of service. Cookies, address validation, cryptographic authentication, rate limits, and resource quotas help mitigate these risks. Protocol implementations must also be tested against malformed packets, state exhaustion, integer errors, and adversarial timing.

Current Developments and Professional Practice

Transport innovation increasingly emphasizes latency, encrypted deployment, multipath operation, and explicit signals rather than merely increasing peak throughput. QUIC has accelerated transport experimentation because core logic can be updated in user space. HTTP/3 has made stream-aware encrypted transport a practical mainstream deployment model.

Research and industry work continues on multipath QUIC, improved loss recovery, low-latency congestion control, datacenter transports, programmable network feedback, and better coexistence between competing algorithms. Machine learning may assist traffic prediction or parameter selection, but automated control must be constrained by safety, fairness, explainability, and failure containment. A model that increases throughput for one service by overwhelming a shared bottleneck is not an acceptable optimization.

Best practice is therefore empirical and layered: define application objectives, measure the path, choose a service model, implement congestion responsibility, validate under representative workloads, monitor fairness and delay, and retain a safe fallback. Transport performance should be assessed using throughput together with RTT, tail latency, loss, completion time, CPU consumption, memory, and energy.

Chapter Summary

UDP, TCP, SCTP, and QUIC embody different transport abstractions. UDP supplies minimal datagrams; TCP supplies a reliable ordered byte stream; SCTP supplies reliable messages, multistreaming, and multihoming; QUIC supplies encrypted, multiplexed transport over UDP with connection migration and user-space evolution. Reliability depends on sequencing, acknowledgements, selective recovery, and adaptive timers. Flow control protects the receiver through the receive window, while congestion control protects the shared network through the congestion window.

TCP congestion control combines probing, avoidance, and loss recovery, while modern algorithms differ in their treatment of loss, delay, bandwidth, and pacing. Fairness must be evaluated together with utilization and queueing delay. AQM, ECN, selective acknowledgements, window scaling, and pacing are important for modern networks. High-speed, long-delay, wireless, and multipath environments require careful measurement and cannot be handled well by simplistic assumptions. Protocol selection should follow application semantics, path conditions, security requirements, operational constraints, and measured outcomes.

Key Terms

UDP: A connectionless, message-oriented transport protocol without built-in reliability or congestion control.

TCP: A connection-oriented transport protocol providing a reliable, ordered byte stream.

SCTP: A reliable, message-oriented transport protocol supporting multistreaming and multihoming.

QUIC: An encrypted, multiplexed transport protocol implemented over UDP.

Reliability: The delivery property achieved through sequencing, acknowledgements, loss detection, and retransmission.

Flow control: Regulation of sending to prevent overwhelming the receiving endpoint.

Congestion control: Regulation of sending to prevent overloading the shared network.

Congestion window: A sender-maintained estimate of the amount of data that may be in flight because of network capacity.

Receive window: Receiver-advertised credit limiting data according to available buffer space.

RTT: Round-trip time between transmission and receipt of feedback.

BDP: Bandwidth-delay product, estimating the data volume needed to fill a path.

Slow start: TCP’s initial phase of rapid congestion-window growth.

Congestion avoidance: A phase of more conservative congestion-window increase.

Selective acknowledgement: Feedback identifying received non-contiguous data blocks.

Packet pacing: Spreading transmissions over time to reduce bursts and queue spikes.

ECN: Explicit Congestion Notification, which marks packets instead of dropping them to signal congestion.

AQM: Active Queue Management, which controls queue buildup through early marking or dropping.

Multistreaming: Carrying independent ordered streams within one transport association.

Multihoming: Associating a transport endpoint with multiple network addresses.

Bufferbloat: Excessive queueing that produces high delay despite adequate throughput.

Review Questions

Short Answer Questions

1. Why is the usable TCP sending window constrained by both `cwnd` and `rwnd`?

2. What service does UDP provide that TCP does not provide directly?

3. How does selective acknowledgement improve recovery from multiple losses?

4. Define bufferbloat and identify one mechanism that can reduce it.

5. What is the purpose of multistreaming in SCTP and QUIC?

Long Answer Questions

1. Compare UDP, TCP, SCTP, and QUIC with respect to ordering, reliability, message boundaries, security, and deployment use cases.

2. Explain TCP slow start, congestion avoidance, fast retransmit, fast recovery, and timeout-based recovery.

3. Distinguish flow control from congestion control and illustrate their interaction using a high-bandwidth-delay path.

4. Analyze the benefits and limitations of QUIC for modern web applications.

5. Explain why high-speed, wireless, and satellite networks create different transport-control challenges.

Analytical / Application Questions

1. A receiver has a large available buffer, but throughput is low and the congestion window is much smaller than the receive window. What does this suggest, and what measurements would you collect next?

2. Design a transport strategy for a real-time video application in which late frames are less valuable than current frames. Justify your choices concerning reliability, pacing, congestion control, and retransmission.

3. An organization wants to combine Wi-Fi and cellular links for one long-lived session. Analyze the benefits, scheduling issues, security concerns, and operational metrics relevant to a multipath design.

22. Multiple Choice Questions with Answers

Question 1

A TCP sender has a congestion window of 2 MB and a receive window of 512 KB. Ignoring other limits, how much data may be outstanding?

A. 256 KB

B. 512 KB

C. 2 MB

D. 2.5 MB

Correct Answer: B. 512 KB

Question 2

Which feature most directly reduces transport-level blocking among independent application exchanges?

A. A larger checksum

B. Multistreaming

C. A smaller receive window

D. Cumulative acknowledgement only

Correct Answer: B. Multistreaming

Question 3

Why is the bandwidth-delay product important when configuring a high-speed TCP path?

A. It determines the encryption key length

B. It estimates the data needed to keep the path fully utilized

C. It eliminates the need for acknowledgements

D. It measures application processing time

Correct Answer: B. It estimates the data needed to keep the path fully utilized

Question 4

Which event is generally treated by TCP as a stronger congestion signal than several duplicate acknowledgements?

A. A successful selective acknowledgement

B. A retransmission timeout

C. An increased receive window

D. A completed handshake

Correct Answer: B. A retransmission timeout

Question 5

A UDP-based application continuously increases its sending rate without responding to loss, delay, or ECN marks. What is the primary concern?

A. It cannot use port numbers

B. It may behave unfairly and contribute to congestion

C. It will necessarily provide ordered delivery

D. It will reduce all network traffic

Correct Answer: B. It may behave unfairly and contribute to congestion

Question 6

Which characteristic is most closely associated with SCTP?

A. Only unreliable datagrams

B. A mandatory ordered byte stream with no messages

C. Reliable messages, multistreaming, and multihoming

D. Operation without port identifiers

Correct Answer: C. Reliable messages, multistreaming, and multihoming

Question 7

What is the principal purpose of packet pacing?

A. To spread transmissions and reduce burst-induced queueing

B. To remove the need for congestion control

C. To make every packet larger than the path MTU

D. To prevent all wireless losses

Correct Answer: A. To spread transmissions and reduce burst-induced queueing

Question 8

Which situation is most likely to produce bufferbloat?

A. A queue controlled to maintain a short delay

B. A very large queue that avoids loss but holds packets for a long time

C. A receiver advertising zero available memory permanently

D. A connection with no application data

Correct Answer: B. A very large queue that avoids loss but holds packets for a long time

Question 9

Why can QUIC maintain a connection more readily when a mobile device changes networks?

A. It does not use any security mechanism

B. It uses connection identifiers and supports validated migration

C. It disables congestion control during movement

D. It requires a new TCP three-way handshake for every packet

Correct Answer: B. It uses connection identifiers and supports validated migration

Question 10

Two flows share a bottleneck, but one opens many parallel connections and receives much more capacity. What concept does this illustrate?

A. Perfect protocol neutrality

B. Connection-count-dependent fairness

C. Receiver checksum failure

D. Message boundary preservation

Correct Answer: B. Connection-count-dependent fairness