A Survey on Recent Advances in Transport Layer Protocols

I. INTRODUCTION

• Middleboxes, the widespread TCP/UDP socket API, and kernel-based transport implementations impede deploying alternatives, while TCP has scenario-specific performance problems.The paper identifies wireless links with high variability, web-traffic head-of-line blocking, and bufferbloat as examples.Source: §I · p. 1
• The survey covers alternative transport protocols, congestion-control innovations, and multipath approaches, including QUIC, machine-learning methods, and multipath extensions.It aims to provide a comprehensive view beyond surveys focused separately on ossification, multipath, or particular congestion-control settings.Source: §I · p. 2

II. TRANSPORT LAYER LIMITATIONS IN MODERN NETWORKS

• Transport protocols view a connection end to end, yet latency, loss, buffer state, and capacity volatility on individual links affect performance.The paper reviews limitations and proposed responses to these challenges.Source: §II · p. 2

A. Bufferbloat

• With large buffers before a bottleneck, loss-based TCP probing raises queue occupancy and latency, then can overshoot capacity and trigger congestion and retransmissions.The same large-buffer congestion-control problem affects QUIC, SCTP, and DCCP, not only TCP.Source: A. Bufferbloat · p. 2
• Bufferbloat degrades application QoS, while AQM can be costly and complex to tune; CoDel limits buffering latency by monitoring queue delay and dropping packets above a threshold.CoDel typically monitors 100 ms intervals and drops when the minimum queueing delay exceeds 5 ms; the issue remains relevant in wireless settings.Source: A. Bufferbloat · pp. 2–3

B. The Incast issue

• In a many-to-one data-center scenario, insufficient switch buffering can trigger congestion, TCP timeouts, throughput collapse, and long delays.The figure depicts a typical TCP Incast scenario; proposed responses include parameter changes, improved algorithms, delay-based control, and new schemes such as DCTCP and IATCP.Source: Figure 1 · p. 3, B. The Incast issue · p. 3

C. Latency and Head of Line Blocking

• TCP’s in-order byte stream means one missing packet can delay subsequent independent flows sharing a connection; opening separate connections adds setup overhead and less stable congestion control.The issue arises because the flows share one TCP connection.Source: C. Latency and Head of Line Blocking · p. 3
• HTTP/2 multiplexes requests over one TCP connection, but a lost packet can halt reception on every stream, limiting its performance advantage in lossy cellular networks.Measurements cited in the passage found no significant HTTP/2 performance advantage over HTTP/1.1 in cellular networks.Source: C. Latency and Head of Line Blocking · p. 3
• QUIC’s multiple independent streams avoid the shared line-of-blocking problem described for TCP and HTTP/2.The figure contrasts TCP and HTTP/2 head-of-line blocking with QUIC’s independent streams; SCTP also supports multiple data streams.Source: C. Latency and Head of Line Blocking · pp. 3–4, Figure 2 · p. 4

D. Performance on Wireless Channels

• TCP’s congestion control can mistake wireless losses from degraded channel quality for congestion, reducing sending rates and end-to-end performance.Link-layer retransmission and protection can increase delay variability; performance-enhancing proxies are another cited approach.Source: D. Performance on Wireless Channels · p. 4
• TCP’s control loop is too slow for mmWave channel and data-rate dynamics, and it takes a long time to reach capacity after loss or connection start,.Blockage, directionality, and line-of-sight to non-line-of-sight transitions contribute to these dynamics; large buffers make bufferbloat more disruptive at mmWave frequencies.Source: D. Performance on Wireless Channels · p. 4

III. RECENT TRANSPORT PROTOCOLS

• Figure 3 contrasts the protocol stacks for HTTP/2 over TCP and HTTP/2 over QUIC [58].QUIC is carried over UDP while providing transport-layer functionality.Source: §III · p. 4, Figure 3 · p. 5

A. Quick UDP Internet Connections (QUIC)

• QUIC runs in user space over UDP to avoid many middlebox incompatibilities and enable transport changes without operating-system updates.Its design also targets TCP’s head-of-line issue and handshake delay.Source: A. Quick UDP Internet Connections (QUIC) · p. 5
• QUIC combines transport and TLS 1.3 handshakes, encrypts packet headers, distinguishes lost from out-of-order packets in ACKs, and multiplexes independent streams.A lost packet in one stream does not block the others, and connection identifiers allow a connection to persist through endpoint IP-address changes.Source: A. Quick UDP Internet Connections (QUIC) · p. 5

1) Connection Establishment:

• QUIC’s 0-RTT option sends stored connection information with the first data packet on subsequent connections, while first-time setup takes one RTT.The first connection carries transport setup parameters in the Client Hello; the client stores those parameters and the server’s Diffie-Hellman value for later connections.Source: 1) Connection Establishment · p. 5

2) QUIC Packets:

• QUIC’s cleartext header values include connection IDs, packet type, version, and packet length, while packet numbers are protected against casual observation and must not be reused within a connection.The payload contains type-dependent frames, allowing a packet to multiplex multiple streams.Source: 2) QUIC Packets · pp. 5–6

3) QUIC

• By September 2017, QUIC traffic had a 6.7% share relative to TCP/HTTPS on the MAWI backbone and a 9.1% share at a mobile ISP.The reported traffic was almost exclusively Google and its services, and frequent, potentially incompatible protocol updates were noted as a possible long-term stability problem.Source: 3) QUIC · p. 6
• An 18% reduction in YouTube re-buffering rates was reported, while QUIC’s average CPU load was 3.5 times TCP/TLS in the implementation studied.The study also reports reduced search latency for QUIC clients relative to TCP/TLS, but the supplied passage gives no percentage value.Source: 3) QUIC · p. 6
• QUIC outperformed TCP/TLS on desktop and with varying data rates, but packet reordering can hurt mobile performance, and QUIC consumed more than its fair share of bottleneck bandwidth.The evaluation tested 13 QUIC versions; older hardware also showed performance issues attributed to less-optimized user-space packet processing and cryptographic operations.Source: 3) QUIC · p. 6

B. Stream Control Transmission Protocol (SCTP)

• SCTP multihoming uses a primary address and backup addresses for availability and recovery, while multistreaming delivers substreams independently to avoid head-of-line blocking,,.SCTP also supports unordered delivery; heartbeat packets check backup links, and retransmissions can use them.Source: B. Stream Control Transmission… · p. 7
• SCTP multihoming improved throughput and recovery in wireless LANs, but its head-of-line avoidance only slightly reduced latency under high packet loss and did not help in normal concurrent traffic,.When MTU suddenly decreases, SCTP cannot avoid IP fragmentation, and NATs may fail to route fragmented datagrams.Source: B. Stream Control Transmission… · p. 7

C. Datagram Congestion Control Protocol (DCCP)

• DCCP,, adds connection-oriented congestion control to unreliable, message-oriented UDP for applications that need congestion control but not reliable delivery.Its per-packet sequence numbers support loss detection without retransmissions, and connection features can be negotiated.Source: C. Datagram Congestion Control… · p. 7

D. Open Challenges and Research Directions

• Widespread middleboxes and the near-universal TCP/UDP socket API constrain adoption of alternative transport protocols.QUIC’s user-space implementation and support from major content providers offer a promising direction against ossification.Source: D. Open Challenges and Research… · p. 7
• QUIC and SCTP can maintain end-to-end connections across IP-address changes, a useful capability when mobile users roam between networks.Both protocols also natively support or can be extended to support multiple paths.Source: D. Open Challenges and Research… · p. 7
• QUIC, SCTP, and DCCP share flexibility, including options to disable reliable delivery on selected streams or negotiate features during connection setup.The survey notes that application developers need suitable API evolution to use this reconfigurability.Source: D. Open Challenges and Research… · pp. 7–8

IV. CONGESTION CONTROL ALGORITHMS

• Congestion control is difficult to design because link and connection characteristics unpredictably affect performance, while kernel-bound algorithms often cannot be customized per connection.DCCP separates congestion-control mechanisms from its core protocol and allows applications to select a Congestion Control ID for each half-connection.Source: §IV · pp. 8–9

A. Loss-based mechanisms

• New Reno, like Reno, halves its congestion window after three duplicate ACKs, while Tahoe returns to one packet; QUIC’s default control is also New Reno-based.The figure illustrates New Reno’s congestion-window evolution over time.Source: A. Loss-based mechanisms · p. 9, Figure 8 · p. 9
• At 100 ms minimum RTT, classic loss-based recovery takes slightly less than a minute at 100 Mb/s and about 10 minutes at 1 Gb/s in Long Fat Networks.The paper defines an LFN as a network with a bandwidth-delay product over 100 kb.Source: A. Loss-based mechanisms · p. 9
• BIC [89] and CUBIC use binary search and cubic window growth, respectively, to improve fairness across flows with different RTTs.BIC was considered too aggressive toward legacy flows, while CUBIC is widely deployed and designed for high performance without unfairness to older mechanisms.Source: A. Loss-based mechanisms · p. 9, Figure 9 · p. 10
• DCCP’s CCID 2 is New Reno-like, while CCID 3 (TFRC) targets stable, TCP-friendly throughput and CCID 4 adapts TFRC for small-packet applications.These mechanisms address datagram delivery without retransmissions.Source: A. Loss-based mechanisms · p. 9
• Studies report poor performance for loss-based control in wireless, MANET, and broadband high-latency networks, because the limitation is inherent to the loss-based philosophy,,.The paper notes that loss-based control can still be useful in some scenarios, particularly at very high RTTs.Source: A. Loss-based mechanisms · pp. 9–10
• TCP Wave uses bursts to regain fairness and bandwidth quickly, but queued packets, jitter, and capacity fluctuations can increase delay and slow its response.Its burst-based design commits to a sending rate in advance, leaving fewer opportunities to correct errors.Source: A. Loss-based mechanisms · p. 10

B. Delay-based mechanisms

• Delay-based control can detect congestion before a buffer fills and back off as RTT rises, addressing the queueing delay that loss-based control can allow to accumulate.Vegas adjusts its congestion window toward expected channel throughput and backs off when RTT exceeds a threshold.Source: B. Delay-based mechanisms · p. 10
• Verus achieved throughput similar to TCP CUBIC while reducing delay by an order of magnitude in real-world 3G and LTE tests.Its delay-profile estimation imposes substantial sender computation, potentially making uplink or high-throughput use impossible.Source: B. Delay-based mechanisms · pp. 10–11
• Delay-based mechanisms can be stable and low-latency, but may be outcompeted by loss-based flows sharing a sufficiently large-buffer bottleneck, constraining wide-scale deployment.LEDBAT uses extra delay to estimate unused capacity for background traffic; Copa and Nimbus [95] adapt aggressiveness to compete with loss-based flows.Source: B. Delay-based mechanisms · p. 11

C. Capacity-based mechanisms

• Sprout predicts cellular-link capacity with a Hidden Markov Model and estimates a safe packet volume to balance throughput against queue delay.It relies on a dedicated buffer; with multiple flows sharing one buffer, Sprout leaves almost all capacity to competing flows.Source: C. Capacity-based mechanisms · p. 11

D. Hybrid mechanisms

• Compound TCP combines delay- and loss-based windows, while BBR estimates bandwidth and RTT and targets a congestion window equal to the bandwidth-delay product.BBR periodically drains the buffer to estimate minimum RTT and capacity, then returns to the initial delivery rate.Source: D. Hybrid mechanisms · pp. 11–12, Figure 10 · p. 12
• BBR’s fairness and stability remain open issues: competing algorithms can cause throughput fluctuations, and Farrow’s tests found New Reno and CUBIC fairer than BBR,.BBR’s aggressiveness toward loss-based flows depends on buffer size.Source: D. Hybrid mechanisms · p. 12

E. Machine learning approaches

• TCP Remy uses a channel Markov model and tunable fairness objective to learn congestion-control behavior, while TAO handles heterogeneous competing flows but still needs extensive network knowledge.Remy assumes prior knowledge of the network scenario and that competing flows use it; TAO addresses TCP awareness.Source: E. Machine learning approaches · p. 12
• PCC uses online experiments and SACK-measured utility to adjust sending rate; PCC Vivace adds improved TCP friendliness and linear-regression learning.PCC performs well with short buffers and high RTTs, but wireless and bufferbloat performance had not been tested.Source: E. Machine learning approaches · p. 12
• Supervised-learning and Q-learning congestion controllers are scenario-dependent and optimized for simple topologies; the survey reports no fully implemented, well-tested mechanism using these techniques.TCP-RL adapts both initial window and per-flow congestion control, while QTCP ties its actions to congestion-window sizing.Source: E. Machine learning approaches · pp. 12–13

F. Cross-layer approaches

• Cross-layer mmWave approaches tune TCP’s congestion window to the connection BDP using physical- and MAC-layer information, or use a base-station proxy to adjust the advertised window.The described approaches cover downlink and uplink connections and an unmodified TCP sender, respectively.Source: F. Cross-layer approaches · p. 13
• SDN can let transport reserve resources for low-latency applications through a network controller, while multimedia TCP variants account for rate distortion and content type.The survey also describes QUIC sender and receiver modifications that use lower-layer rate estimates to switch between rate-limited and congestion-window-limited operation.Source: F. Cross-layer approaches · p. 13

G. Datacenter networks and the Incast issue

• DCTCP uses ECN to reduce its congestion window according to experienced congestion, leaving buffer space to avoid Incast.The survey contrasts this with explicit-rate schemes and receiver-driven approaches.Source: G. Datacenter networks and the Incast… · p. 13
• D3 uses explicit rate control but needs full network support and is vulnerable to bursts; D2TCP accounts for application deadlines without those D3 limitations.The survey notes that scalability remains an issue for D3.Source: G. Datacenter networks and the Incast… · p. 13
• pFabric uses priority dropping in short-buffer switches, while pHost assigns sender priorities with receiver tokens and ExpressPass controls sender rates with receiver credits.Homa is connectionless, uses receiver-driven priorities, and can significantly reduce latency without network support; its design also limits Incast by tracking outstanding requests.Source: G. Datacenter networks and the Incast… · p. 13
• PASE combines DCTCP, D3, and pFabric mechanisms at different timescales and can outperform each adaptation used alone.It uses coarse, low-precision explicit-rate control and very-short-timescale prioritization and dropping.Source: G. Datacenter networks and the Incast… · p. 14

H. Open Challenges and Research Directions

• Congestion-control research spans loss-, delay-, and capacity-based approaches, with machine-learning and cross-layer mechanisms also drawing interest; use-case-specific algorithms are presented as an alternative to one-size-fits-all control.User-space protocols such as QUIC ease experimentation, while SDN and slicing can isolate mechanisms in separate buffers.Source: H. Open Challenges and Research… · p. 14

V. MULTIPATH TRANSPORT PROTOCOLS

• Multipath transport seeks to exploit multiple available communication technologies, such as smartphone Wi-Fi and LTE, but designing protocols that successfully use path diversity is not straightforward.Source: §V · p. 14

A. MPTCP

• MPTCP is a backward-compatible TCP extension that can use multiple connections to improve capacity, provide link-failure redundancy, and reduce load on congested paths; it is implemented in the operating-system kernel.Each subflow remains a separate TCP flow, as shown in the protocol-stack figure, to accommodate middleboxes that inspect TCP behavior.Source: A. MPTCP · p. 14, Figure 12 · p. 14
• MPTCP starts with one TCP subflow and uses MP_CAPABLE and MP_JOIN handshakes to identify capable hosts and securely add subflows.Hosts exchange cryptographic keys, and MPTCP also supports adding and removing host addresses.Source: A. MPTCP · p. 14
• Per-subflow sequence numbers preserve TCP ordering, while connection-level DSNs reassemble split streams; retransmission across subflows can mitigate HoL, but each subflow must still retransmit its own lost data.MPTCP also uses regular subflow acknowledgments and cumulative connection-level acknowledgments.Source: A. MPTCP · pp. 14–15
• A loss on a long-RTT MPTCP subflow can block the whole connection until retransmission, and receiver-buffer limits can stall other subflows; in some cases, single-path TCP on the best path performs better.Disabling MPTCP and falling back to single-path transmission has been proposed for lossy scenarios.Source: A. MPTCP · p. 15

1) Congestion control:

• Uncoupled MPTCP congestion control can be unfair to single-path TCP sharing a path and consume extra resources without performance benefit; its goals include best-path throughput, no excess capacity use, and avoiding congested paths.The figure depicts two uncoupled-control unfairness scenarios: a shared bottleneck and a path that shares a bottleneck with TCP.Source: 1) Congestion control · p. 15, Figure 13 · p. 15
• LIA couples window increases to balance single-path fairness and throughput; its theoretical parameter setting can match the throughput of a single-path flow on the best path, while OLIA and BALIA modify the approach.The fully coupled alternative was considered too conservative, and calculating the window or α scales linearly with the number of flows.Source: 1) Congestion control · p. 15
• Multipath congestion-control algorithms can be inefficient on wireless links because volatility worsens HoL blocking and errors and retransmissions destabilize throughput; DRL-CC achieves high fairness in wired scenarios, but wireless performance is untested.Source: 1) Congestion control · p. 16
• FEC-based multipath schemes can mitigate HoL, especially with limited receiver buffers, but often require tailored schedulers and do not resolve other issues such as throughput volatility.Another proposed workaround retransmits lost packets on a faster path rather than sending new packets on the congested path.Source: 1) Congestion control · p. 16

2) Scheduling:

• The Linux Lowest-RTT-First scheduler sends the next packet on the lowest-RTT path, but waiting for a faster path or using delay, rate, and loss heuristics can be more efficient.Source: 2) Scheduling · p. 16
• Weighted round robin with load balancing, loss-aware scheduling, Earliest Completion First, and DEMS pursue load distribution, completion time, or out-of-order transmission to reduce underutilization.ECF avoids long idle periods that can reset the congestion window.Source: 2) Scheduling · p. 16
• STMS and DAPS interleave packets across paths so successive packets arrive together; sending packets out of order can be advantageous when a faster path is available.Source: 2) Scheduling · p. 16
• BLEST estimates which subflows may cause HoL and adapts scheduling to prevent it; cross-layer alternatives schedule application objects or use network buffer occupancy.The survey summarizes the scheduling algorithms’ features, advantages, and drawbacks in Table IV.Source: 2) Scheduling · pp. 16–17, Table IV · p. 17

3) Multipath TCP in data center networks:

• Large-scale simulations show MPTCP can improve data-center load balancing and throughput, but Incast can still collapse throughput when a client requests data from multiple servers.Multiple MPTCP connections are not aware of each other; one proposed remedy accounts for existing flows when updating each subflow’s congestion window.Source: 3) Multipath TCP in data center networks · p. 17
• Quick retransmission on less-congested flows can help short data-center flows that MPTCP cannot steer toward less-congested paths, alleviating Incast for this traffic.The technique is not needed for long-lived flows.Source: 3) Multipath TCP in data center networks · p. 17
• Combining MPTCP with SDN can improve routing and reduce congestion events, with larger benefits when senders dynamically add or remove subflows based on network conditions.The routing benefit is reported in, and the larger benefit with network-aware senders in.Source: 3) Multipath TCP in data center networks · p. 17

B. Multipath in other protocols

• CMT-SCTP increases throughput but has TCP-friendliness issues, and an experimental comparison found MPTCP had a slight performance advantage while both protocols struggled on high-delay paths.Several CMT-SCTP congestion-control algorithms have been proposed; the comparison is reported in.Source: B. Multipath in other protocols · p. 17
• Multipath QUIC proposals leverage user-space extensibility and QUIC features, including 0-RTT setup and middlebox transparency; unlike MPTCP, QUIC does not require in-order delivery on each subflow.Research on MPQUIC remains limited, and a stream-aware scheduler is one QUIC-specific proposal.Source: B. Multipath in other protocols · p. 17
• MP-DCCP permits connection establishment whenever at least one path works, but its standard remains unfinished and multipath reordering can degrade application performance.Signaling and receiver-side reassembly remain undefined; a scheduler that limits reordering is recommended.Source: B. Multipath in other protocols · p. 17
• In Figure 14’s WiFi+LTE scenario, LEAP is the only protocol that violates the latency requirement less than 1% of the time, while MPTCP BALIA outperforms uncoupled CUBIC but offers no latency guarantees.Verus, Vegas, and Sprout do better on latency than BALIA but do not reduce the lateness rate below 10%; LEAP adjusts coding rate to trade throughput against latency strictness.Source: B. Multipath in other protocols · p. 18, Figure 14 · p. 18

• Multipath transport has unresolved fairness and Head-of-Line blocking issues; flexible protocols such as MPQUIC may mitigate issues tied to backward compatibility, while others are more fundamental.Multiple paths are increasingly available on devices such as smartphones with cellular and Wi-Fi connectivity.Source: C. Open Challenges and Research… · p. 18
• Scheduling and congestion control are difficult to integrate because they interact with hard-to-model effects, and multipath adaptation exacerbates existing transport issues.Wireless and data-center deployments need specific adaptations; efficient integrated scheduling and congestion control remain challenging and may require FEC and cross-layer support.Source: C. Open Challenges and Research… · p. 18

VI. CONCLUSIONS

• TCP remains widely used but performs suboptimally in some use cases, while emerging technologies and requirements exceed its capabilities in scenarios such as mmWave communications and ultra-low-latency VR streaming.The survey organizes its review around transport protocols, congestion control, and multipath transport.Source: §VI · p. 18
• QUIC, SCTP, and DCCP offer transport-protocol evolutions or alternatives; QUIC’s user-space implementation avoids operating-system upgrades but brings higher computational load than kernel-based solutions.SCTP and DCCP are standardized but not widely adopted, while QUIC is not yet fully standardized; early results show promising performance.Source: §VI · p. 18
• The survey reviews congestion-control proposals ranging from traditional loss-based mechanisms to delay-based, hybrid, and machine-learning approaches.The reviewed algorithms target TCP and congestion-aware transport protocols more generally.Source: §VI · pp. 18–19
• Multipath transport can provide macro diversity and may increase throughput and reliability, but MPTCP has Head-of-Line and single-path TCP fairness issues, while other protocol extensions remain open research areas.MPTCP dispatches packets over multiple subflows when multiple interfaces are available; it is designed to maintain compatibility with middleboxes.Source: §VI · p. 19
• Ongoing research directions include coupling network slicing with TCP fairness, adaptive congestion control, and efficient, fair multi-link scheduling and congestion control.Standardization efforts for multipath transport are also ongoing.Source: §VI · p. 19