Representing congestion in a packet
RFC 3168 defines a two-bit IP field distinguishing Not-ECT, ECN-capable markings and Congestion Experienced. Senders indicate capability so a router can mark an eligible packet CE and forward it under the applicable rules.
ECN adds no capacity and does not prevent every queue overflow or packet loss. Endpoints still handle real loss; marking changes one feedback mechanism rather than eliminating congestion control or recovery.
References: [1]
Classic TCP returns the indication to the sender
Classic TCP negotiates ECN support during connection setup. A receiver seeing CE echoes it using TCP ECE; the sender responds to congestion and signals that response with CWR. IP marking and TCP feedback are separate fields.
Endpoint behavior must complete the loop; one marking router alone does not establish full connection support. Avoiding the drop is not permission to keep sending unchanged, since the mark itself calls for congestion action.
References: [1]
The notification mechanism and later algorithms
ECN does not select one window-growth, feedback-resolution or queue algorithm. Classic TCP is one use, while QUIC and other transports define their own reporting. A connection must be interpreted under its actual mechanism and version.
Later documents relax some early restrictions for specified experiments. RFC 8311 updates RFC 3168 and related protocols accordingly, so historical codepoint uses and packet restrictions must not all be treated as permanent. Mechanism, algorithm and deployment support need separate checks.