20.1 The Motivation for an ECT Codepoint
20.1 The Motivation for an ECT Codepoint
This section explains why an ECT (ECN-Capable Transport) codepoint is needed, separate from the CE (Congestion Experienced) codepoint.
The fundamental requirement is to distinguish between three states:
-
Not-ECT (00): The transport protocol does not support ECN. Packets with this codepoint should never be marked with CE by routers; they should only be dropped if congestion control action is needed.
-
ECT (10 or 01): The transport protocol supports ECN. Routers may mark these packets with CE instead of dropping them when signaling incipient congestion.
-
CE (11): The packet has experienced congestion. This is a signal from the network to the endpoints that congestion has been encountered.
Without a separate ECT codepoint, routers would not be able to determine whether a packet's transport protocol is capable of responding to ECN signals. If routers were to mark packets from non-ECN-capable transports with CE, those congestion signals would be ignored, potentially leading to:
- Congestion without appropriate response from the endpoints
- Unfairness between ECN-capable and non-ECN-capable flows
- Potential network instability
The ECT codepoint provides explicit signaling from endpoints to routers, indicating: "This transport understands ECN and will respond appropriately to CE marks." This allows routers to make informed decisions about whether to mark or drop packets based on the transport's capabilities.
In summary, the ECT codepoint is essential for:
- Enabling incremental deployment of ECN
- Ensuring backward compatibility with non-ECN-capable transports
- Allowing routers to optimize their congestion signaling strategy
- Maintaining the integrity of end-to-end congestion control