ECT

Explicit Congestion Notification-Capable Transport

Protocol
Introduced in Rel-5
A transport layer capability, primarily for TCP, that allows network nodes to signal impending congestion to endpoints before packet loss occurs. It enables more efficient congestion control, reducing latency and improving overall network throughput.

Description

Explicit Congestion Notification-Capable Transport (ECT) refers to the implementation of the Explicit Congestion Notification (ECN) mechanism as defined in IETF RFC 3168, which has been adopted and referenced within 3GPP specifications for transport protocols. ECN is an extension to the Internet Protocol (IP) and Transmission Control Protocol (TCP) that allows routers to mark packets with a Congestion Experienced (CE) codepoint instead of dropping them when congestion is imminent. An ECT-capable transport layer, such as TCP, must negotiate the use of ECN at connection setup and then properly interpret and react to these CE markings from the network.

The operation of ECT involves two main phases: capability negotiation and congestion signaling. During TCP connection establishment, endpoints set the ECN-Echo (ECE) and Congestion Window Reduced (CWR) flags in the TCP header to indicate they are ECN-capable (ECT). Once the connection is established, IP routers monitor their queue lengths. When a queue exceeds a configured threshold, indicating incipient congestion, the router marks the IP header's ECN field in passing packets to CE (Congestion Experienced), provided the packet was sent as ECT(0) or ECT(1) by the sender. The receiver detects this CE mark and echoes it back to the sender by setting the ECE flag in subsequent TCP ACK packets. Upon receiving this echo, the sender reduces its congestion window as if a packet loss had occurred, thereby alleviating the congestion without requiring packet drops and retransmissions.

Within the 3GPP architecture, ECT is relevant for transport connections used by network functions and user equipment. Specifications like TS 29.165 (GTP) and TS 36.750 (F1 interface) reference ECN for managing congestion on critical interfaces. The use of ECT improves the performance of transport protocols over wireless links, where packet loss can be due to radio errors rather than congestion. By distinguishing between congestion signals (ECN marks) and loss signals, TCP can respond more appropriately, avoiding unnecessary rate reductions. This leads to higher link utilization, lower latency, and a better quality of experience for applications, especially in congested core network or backhaul links.

Purpose & Motivation

ECT was developed to address the limitations of traditional loss-based congestion control, where TCP interprets packet loss as a sign of network congestion and drastically reduces its sending rate. In modern networks, especially with large buffers (bufferbloat), this reaction can cause high latency and underutilization. ECN provides an early, explicit signal of congestion before buffers overflow and packets are dropped, allowing endpoints to throttle back smoothly.

The motivation for incorporating ECT into 3GPP systems stems from the need for efficient transport in mobile networks. 3GPP interfaces, such as the N3/N9 interfaces in 5G or the S1-U interface in LTE, carry massive amounts of user plane data. Congestion on these links can degrade service quality. Using ECT-capable transport allows the network to manage congestion more intelligently, reducing packet loss and retransmission delays. This is particularly important for real-time and latency-sensitive services enabled by 5G. ECT represents a shift from a purely loss-based to a signal-based congestion control paradigm, aligning with broader Internet engineering efforts to improve network responsiveness and fairness.

Key Features

  • Enables IP routers to mark packets with a Congestion Experienced (CE) codepoint
  • Requires negotiation between endpoints at transport layer setup (e.g., TCP SYN)
  • Allows senders to react to congestion before packet loss occurs
  • Reduces packet loss and retransmissions, lowering latency
  • Improves throughput and fairness in shared bottleneck links
  • Integrated into 3GPP specifications for GTP-based and other internal interfaces

Evolution Across Releases

Defining Specifications

SpecificationTitle
TS 21.905 3GPP TS 21.905
TS 22.173 3GPP TS 22.173
TS 22.273 3GPP TS 22.273
TS 22.401 3GPP TS 22.401
TS 23.806 3GPP TS 23.806
TS 24.173 3GPP TS 24.173
TS 24.186 3GPP TS 24.186
TS 24.196 3GPP TS 24.196
TS 24.292 3GPP TS 24.292
TS 24.315 3GPP TS 24.315
TS 24.404 3GPP TS 24.404
TS 24.405 3GPP TS 24.405
TS 24.406 3GPP TS 24.406
TS 24.410 3GPP TS 24.410
TS 24.411 3GPP TS 24.411
TS 24.416 3GPP TS 24.416
TS 24.429 3GPP TS 24.429
TS 24.447 3GPP TS 24.447
TS 24.454 3GPP TS 24.454
TS 24.504 3GPP TS 24.504
TS 24.505 3GPP TS 24.505
TS 24.516 3GPP TS 24.516
TS 24.529 3GPP TS 24.529
TS 24.604 3GPP TS 24.604
TS 24.605 3GPP TS 24.605
TS 24.606 3GPP TS 24.606
TS 24.610 3GPP TS 24.610
TS 24.611 3GPP TS 24.611
TS 24.616 3GPP TS 24.616
TS 24.629 3GPP TS 24.629
TS 24.642 3GPP TS 24.642
TS 24.647 3GPP TS 24.647
TS 24.654 3GPP TS 24.654
TS 26.114 3GPP TS 26.114
TS 26.804 3GPP TS 26.804
TS 29.165 3GPP TS 29.165
TS 29.292 3GPP TS 29.292
TS 29.364 3GPP TS 29.364
TS 29.864 3GPP TS 29.864
TS 32.275 3GPP TR 32.275
TS 32.850 3GPP TR 32.850
TS 33.107 3GPP TR 33.107
TS 36.750 3GPP TR 36.750