RFC3168 only allows regular data segments to be sent as
ECN-capable transport (ECT). Control (RST, FIN), pure ACK
and retransmissions are explicitly not to be sent with ECT.
However, it has been shown over the years, that this
approach stifles the usefulness of ECN, in particular when
deploying DCTCP in controlled environments.
Current work in the IETF (draft-generalized-ecn, also known
as ECN++) aims to allow all control and retransmission
packets to be marked ECT. In the case of retransmissions,
the only standardized recourse when one of those is dropped,
is to wait for the RTO timer to expire - including the
penalty imposed by having to suffer an RTO.
Furthermore, allowing control and pure ACKs to convey
additional congestion signals on the return path enables
features like AckCC (RFC5690).
Also, adding code to make non-session related control packets
(eg. RST to non-listening ports) appear idential with those in
response to recently used sessions, to prevent sidechannel
information leakage.