Summary

  • RFC 9599 explains how an explicit congestion indication can survive lower-layer framing, tunnel encapsulation and decapsulation instead of disappearing with a stripped outer header.
  • A final CE codepoint proves the observed header carried CE at that point. By itself it does not name the marking queue, prove the signal's custody, establish its semantics, or show that the sender reduced load.

A packet leaves a tunnel with CE in its IP header. The collector records it. The graph turns amber. There is congestion somewhere in the evidence chain.

The shortest story says the tunnel was congested.

That story may be right. The mark alone cannot make it so. It may have arrived on the inner header before encapsulation. A lower-layer queue may have added it to an outer frame. A decapsulator may have merged two indications and retained the more severe one. Reframing may have moved a lower-layer event onto a later IP packet. A DSCP change may have altered the semantics that gave the two ECN bits their meaning. The receiver may report the mark, or fail to do so. The sender may react, or continue at the same rate.

RFC 9599 matters because it treats this chain as engineering rather than magic. Published in August 2024 as part of Best Current Practice 89, it updates RFC 3819's advice to subnetwork designers. Its objective is to let congestion indications cross the boundary between protocols that encapsulate IP and the IP layer that can carry the indication onward to the transport endpoint.

The problem begins with an asymmetry. When a lower-layer queue drops a frame, the contained packet disappears from every higher layer. No special translation is needed. When the same queue marks a lower-layer header, that header may be removed at the edge of the subnet or tunnel. Unless the egress deliberately transfers the indication, the signal vanishes while the packet survives.

That makes the decapsulator part of the feedback loop. ECN-capable endpoints are not sufficient. Every function needed to return the signal to the load regulator must participate. RFC 9599 therefore defines an ECN-PDU by the capability of the loop around it, not merely by the pattern of bits visible in one protocol data unit. Capability can live in the header, a label, flow state, configuration or a bound control-plane context. The receipt must say which.

Four modes make the differences visible. Feed-forward-and-up carries a congestion indication toward the subnet egress, moves it into the higher-layer header, lets the destination report it backward and finally gives the source a chance to regulate load. Feed-up-and-forward lets a lower-layer device reach into an IP payload and mark the IP header directly. Feed-backward regulates toward the subnet ingress through a lower-layer control path. Null mode assumes the lower-layer fabric does not itself introduce a congestible interior point.

These are not interchangeable implementation details. Feed-backward can work well inside one closed subnet, yet fit poorly beneath IP. An intermediate ingress may slow its own output while the original source continues to send. The queue merely migrates to the boundary until an IP-visible event eventually reaches the end-to-end transport. The control loop works in a narrow functional sense, but it is indirect and can be sluggish. RFC 9599 accordingly warns against designing an Internet-facing technology around feed-backward alone.

Feed-up-and-forward has a different limit: visibility. A Layer 3 switch can mark an IP header while forwarding on Ethernet addresses, but only if it can find and read that header. Encryption, an unfamiliar shim or excessive nesting can make the payload unavailable. The standard tells designers to limit the search depth and fall back to drop or another valid lower-layer signal when the IP header cannot be reached. A device that found no header did not prove there was no congestion; it proved that its chosen inspection path ended.

The most common mode, feed-forward-and-up, places a hard duty on ingress and egress. Before enabling lower-layer marking, the ingress needs a reason to believe that the egress will preserve or safely convert the signal. MPLS can meet this through coordinated domain configuration: once any interior device marks, every relevant egress must be ready to propagate or convert. That is a professional-operator invariant, not a property of the packet.

TRILL illustrates another design. Its congestion indication is critical from ingress to egress. An old egress that does not understand the extension drops the frame rather than silently forwarding it after discarding the mark. The fallback is severe but safe: a congestion signal becomes the packet loss that a non-ECN transport can understand.

This is why an outer mark cannot simply be copied into the inner header. The egress must calculate the outgoing state from both. If the inner packet is Not-ECT and the outer header carries the most severe congestion indication, the packet must be dropped. Writing CE into a Not-ECT packet would create a signal its transport has not promised to read. If both layers carry valid congestion severity, the more severe indication should survive. If the combination should be impossible, the system may log or alarm, but a permanently hard-coded drop can foreclose a future standard where a safe outgoing codepoint exists.

The encapsulator has its own evidentiary duty. It should not reset the outer congestion level to zero merely because it is creating a new header. Carrying the arriving level forward gives monitoring systems a common baseline. Aggregate rates at ingress and egress can then help estimate the congestion introduced inside one tunnel.

“Estimate” is the controlling word. The calculation requires aligned populations, known handling rules and stable observation boundaries. It does not make each final CE packet a notarised statement from a named queue. RFC 9599 explicitly allows reframing logic to preserve either the timing and presence of marks or their approximate proportion. A new signal should move onward promptly, but pipeline design may attach it to a slightly later IP packet. The marked packet and the lower-layer unit that encountered the queue need not be the same object.

The two-bit field may not even have one universal meaning. Default ECN, Pre-Congestion Notification and L4S can use the codepoints within different traffic-class contexts. Some interpretations depend on DSCP. If an outer DSCP is stripped under a pipe model, or rewritten at a domain boundary, an ECN value can arrive without the context that defined its semantics. Copying a bit pattern is not the same as preserving meaning.

Security makes the custody problem sharper. A field that interior nodes legitimately alter must be declared mutable; otherwise marking can invalidate authentication over a header assumed to be immutable. The standard also points toward end-to-end auditing for signal suppression and sender response. Hop-by-hop integrity cannot prove what happened after the mark reached the receiver, and a receiver report cannot prove the sender changed its behavior.

A credible operational claim therefore needs multiple receipts: the inner ECN and DSCP state at ingress; the encapsulation rule; the tunnel or subnet identity; evidence that every relevant egress could propagate a signal; the marking configuration and observation boundary; the inner and outer states at decapsulation; the outgoing state or deliberate drop; receiver feedback; sender receipt; congestion-control response; and an observed change in rate, queue or delivery outcome.

The standard narrows rather than weakens ECN's value. Consistent propagation makes a signal portable across layers. Portability is not provenance. The clean conclusion is that one observed header can attest to its own state at one point. A broader claim must earn the queue, custody, semantics, feedback and response that the codepoint does not contain.

Sources