Change Details

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. ECN+ allows the SYN/ACK to be sent as ECT in order to get rather marked with Congestion Expirienced (CE) than dropped altogether, delaying the session setup. 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).

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.

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. ECN+ allows the SYN/ACK to be sent as ECT in order to getECN, in particular when rather marked with Congestion Expirienced (CE) than dropped altogether, delaying the session setupdeploying 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.