rfc9768v10.txt		rfc9768.txt
	Internet Engineering Task Force (IETF) B. Briscoe		Internet Engineering Task Force (IETF) B. Briscoe
	Request for Comments: 9768 Independent		Request for Comments: 9768 Independent
	Updates: 3168 M. Kühlewind		Updates: 3168 M. Kühlewind
	Category: Standards Track Ericsson		Category: Standards Track Ericsson
	ISSN: 2070-1721 R. Scheffenegger		ISSN: 2070-1721 R. Scheffenegger
	NetApp		NetApp
	March 2026		April 2026
	More Accurate Explicit Congestion Notification (AccECN) Feedback in TCP		More Accurate Explicit Congestion Notification (AccECN) Feedback in TCP
	Abstract		Abstract
	Explicit Congestion Notification (ECN) is a mechanism by which		Explicit Congestion Notification (ECN) is a mechanism by which
	network nodes can mark IP packets instead of dropping them to		network nodes can mark IP packets instead of dropping them to
	indicate incipient congestion to the endpoints. Receivers with an		indicate incipient congestion to the endpoints. Receivers with an
	ECN-capable transport protocol feed back this information to the		ECN-capable transport protocol feed back this information to the
	sender. ECN was originally specified for TCP in such a way that only		sender. ECN was originally specified for TCP in such a way that only
	skipping to change at line 256 ¶		skipping to change at line 256 ¶
	AccECN uses, and Appendix B explains why AccECN uses flags in the		AccECN uses, and Appendix B explains why AccECN uses flags in the
	main TCP header and quantifies the space left for future use.		main TCP header and quantifies the space left for future use.
	1.2. Goals		1.2. Goals
	[RFC7560] enumerates requirements that a candidate feedback scheme		[RFC7560] enumerates requirements that a candidate feedback scheme
	needs to satisfy, under the headings: resilience, timeliness,		needs to satisfy, under the headings: resilience, timeliness,
	integrity, accuracy (including ordering and lack of bias),		integrity, accuracy (including ordering and lack of bias),
	complexity, overhead, and compatibility (both backward and forward).		complexity, overhead, and compatibility (both backward and forward).
	It recognizes that a perfect scheme that fully satisfies all the		It recognizes that a perfect scheme that fully satisfies all the
	requirements is unlikely and trade-offs between requirements are		requirements is unlikely and tradeoffs between requirements are
	likely. Section 6 assesses the properties of AccECN against these		likely. Section 6 assesses the properties of AccECN against these
	requirements and discusses the trade-offs.		requirements and discusses the tradeoffs.
	The requirements document recognizes that a protocol as ubiquitous as		The requirements document recognizes that a protocol as ubiquitous as
	TCP needs to be able to serve as-yet-unspecified requirements.		TCP needs to be able to serve as-yet-unspecified requirements.
	Therefore, an AccECN receiver acts as a generic (mechanistic)		Therefore, an AccECN receiver acts as a generic (mechanistic)
	reflector of congestion information with the aim that new sender		reflector of congestion information with the aim that new sender
	behaviours can be deployed unilaterally in the future (see		behaviours can be deployed unilaterally in the future (see
	Section 2.5).		Section 2.5).
	1.3. Terminology		1.3. Terminology
	skipping to change at line 647 ¶		skipping to change at line 647 ¶
	above.		above.
	Once a TCP Client (A) has sent the above SYN to declare that it		Once a TCP Client (A) has sent the above SYN to declare that it
	supports AccECN, and once it has received the above SYN/ACK segment		supports AccECN, and once it has received the above SYN/ACK segment
	that confirms that the TCP Server supports AccECN, the TCP Client		that confirms that the TCP Server supports AccECN, the TCP Client
	MUST set both its half-connections into AccECN mode. The TCP Client		MUST set both its half-connections into AccECN mode. The TCP Client
	MUST NOT enter AccECN mode (or any feedback mode) before it has		MUST NOT enter AccECN mode (or any feedback mode) before it has
	received the first SYN/ACK.		received the first SYN/ACK.
	Once in AccECN mode, a TCP Client or Server has the rights and		Once in AccECN mode, a TCP Client or Server has the rights and
	obligations to participate in the ECN protocol defined in		obligations defined in Section 3.1.5 concerning use of ECN.
	Section 3.1.5.
	The procedures for retransmission of SYNs or SYN/ACKs are given in		The procedures for retransmission of SYNs or SYN/ACKs are given in
	Section 3.1.4.		Section 3.1.4.
	It is RECOMMENDED that the AccECN protocol be implemented alongside		It is RECOMMENDED that the AccECN protocol be implemented alongside
	Selective Acknowledgement (SACK) [RFC2018]. If SACK is implemented		Selective Acknowledgement (SACK) [RFC2018]. If SACK is implemented
	with AccECN, Duplicate Selective Acknowledgement (D-SACK) [RFC2883]		with AccECN, Duplicate Selective Acknowledgement (D-SACK) [RFC2883]
	MUST also be implemented.		MUST also be implemented.
	3.1.2. Backward Compatibility		3.1.2. Backward Compatibility
	skipping to change at line 2931 ¶		skipping to change at line 2930 ¶
	if ((newlyAckedB > 0) || (newlyAckedT > 0))		if ((newlyAckedB > 0) || (newlyAckedT > 0))
	d.cep = (ACE + DIVACE - (s.cep % DIVACE)) % DIVACE		d.cep = (ACE + DIVACE - (s.cep % DIVACE)) % DIVACE
	Section 3.2.2.5 expects the Data Sender to assume that the ACE field		Section 3.2.2.5 expects the Data Sender to assume that the ACE field
	cycled if it is the safest likely case under prevailing conditions.		cycled if it is the safest likely case under prevailing conditions.
	The 3-bit ACE field in an arriving ACK could have cycled and become		The 3-bit ACE field in an arriving ACK could have cycled and become
	ambiguous to the Data Sender if a sequence of ACKs goes missing that		ambiguous to the Data Sender if a sequence of ACKs goes missing that
	covers a stream of data long enough to contain 8 or more CE marks.		covers a stream of data long enough to contain 8 or more CE marks.
	We use the word 'missing' rather than 'lost', because some or all the		We use the word 'missing' rather than 'lost', because some or all the
	missing ACKs might arrive eventually, but out of order. Even if some		missing ACKs might arrive eventually, but out of order. Even if some
	of the missing ACKs were piggy-backed on data (i.e., not pure ACKs)		of the missing ACKs were piggybacked on data (i.e., not pure ACKs)
	retransmissions will not repair the lost AccECN information, because		retransmissions will not repair the lost AccECN information, because
	AccECN requires retransmissions to carry the latest AccECN counters,		AccECN requires retransmissions to carry the latest AccECN counters,
	not the original ones.		not the original ones.
	The phrase 'under prevailing conditions' allows for implementation-		The phrase 'under prevailing conditions' allows for implementation-
	dependent interpretation. A Data Sender might take account of the		dependent interpretation. A Data Sender might take account of the
	prevailing size of data segments and the prevailing CE marking rate		prevailing size of data segments and the prevailing CE marking rate
	just before the sequence of missing ACKs. However, we shall start		just before the sequence of missing ACKs. However, we shall start
	with the simplest algorithm, which assumes segments are all full-		with the simplest algorithm, which assumes segments are all full-
	sized, and ultra-conservatively it assumes that ECN marking was 100%		sized, and ultra-conservatively it assumes that ECN marking was 100%
	skipping to change at line 3119 ¶		skipping to change at line 3118 ¶
	For this approach to be precise, it has to be assumed that spurious		For this approach to be precise, it has to be assumed that spurious
	(unnecessary) retransmissions do not lead to double counting. This		(unnecessary) retransmissions do not lead to double counting. This
	assumption is currently correct, given that RFC 3168 requires that		assumption is currently correct, given that RFC 3168 requires that
	the Data Sender mark retransmitted segments as Not-ECT. However, the		the Data Sender mark retransmitted segments as Not-ECT. However, the
	converse is not true; necessary retransmissions will result in		converse is not true; necessary retransmissions will result in
	undercounting.		undercounting.
	However, such precision is unlikely to be necessary. The only known		However, such precision is unlikely to be necessary. The only known
	use of a count of Not-ECT marked bytes is to test whether equipment		use of a count of Not-ECT marked bytes is to test whether equipment
	on the path is clearing the ECN field (perhaps due to an out-dated		on the path is clearing the ECN field (perhaps due to an outdated
	attempt to clear, or bleach, what used to be the IPv4 ToS byte or the		attempt to clear, or bleach, what used to be the IPv4 ToS byte or the
	IPv6 Traffic Class field). To detect bleaching, it will be		IPv6 Traffic Class field). To detect bleaching, it will be
	sufficient to detect whether nearly all bytes arrive marked as Not-		sufficient to detect whether nearly all bytes arrive marked as Not-
	ECT. Therefore, there ought to be no need to keep track of the		ECT. Therefore, there ought to be no need to keep track of the
	details of retransmissions.		details of retransmissions.
	Appendix B. Rationale for Usage of TCP Header Flags		Appendix B. Rationale for Usage of TCP Header Flags
	B.1. Three TCP Header Flags in the SYN-SYN/ACK Handshake		B.1. Three TCP Header Flags in the SYN-SYN/ACK Handshake
	skipping to change at line 3148 ¶		skipping to change at line 3147 ¶
	Classic ECN used header flags rather than a TCP Option because it was		Classic ECN used header flags rather than a TCP Option because it was
	considered more efficient to use a header flag for 1 bit of feedback		considered more efficient to use a header flag for 1 bit of feedback
	per ACK, and this bit could be overloaded to indicate support for		per ACK, and this bit could be overloaded to indicate support for
	Classic ECN during the handshake. During the development of ECN, 1		Classic ECN during the handshake. During the development of ECN, 1
	bit crept up to 2, in order to deliver the feedback reliably and to		bit crept up to 2, in order to deliver the feedback reliably and to
	work round some broken hosts that reflected the reserved flags during		work round some broken hosts that reflected the reserved flags during
	the handshake.		the handshake.
	In order to be backward compatible with RFC 3168, AccECN continues		In order to be backward compatible with RFC 3168, AccECN continues
	this approach, using the 3rd least significant TCP header flag that		this approach, using the 3rd least significant TCP header flag that
	had previously been allocated for the ECN-nonce (now historic).		had previously been allocated for the ECN-nonce (now Historic).
	Then, whatever form of Server an AccECN Client encounters, the		Then, whatever form of Server an AccECN Client encounters, the
	connection can fall back to the highest version of feedback protocol		connection can fall back to the highest version of feedback protocol
	that both ends support, as explained in Section 3.1.		that both ends support, as explained in Section 3.1.
	If AccECN capability negotiation had used the more orthodox approach		If AccECN capability negotiation had used the more orthodox approach
	of a TCP Option, it would still have had to set the two ECN flags in		of a TCP Option, it would still have had to set the two ECN flags in
	the main TCP header, in order to be able to fall back to Classic ECN		the main TCP header, in order to be able to fall back to Classic ECN
	[RFC3168], or to disable ECN support, without another round of		[RFC3168], or to disable ECN support, without another round of
	negotiation. Then AccECN would also have had to handle all the		negotiation. Then AccECN would also have had to handle all the
	different ways that Servers currently respond to settings of the ECN		different ways that Servers currently respond to settings of the ECN
	skipping to change at line 3212 ¶		skipping to change at line 3211 ¶
	Despite availability of usable TCP header space being extremely		Despite availability of usable TCP header space being extremely
	scarce, the AccECN protocol has taken all possible steps to ensure		scarce, the AccECN protocol has taken all possible steps to ensure
	that there is space to negotiate possible future variants of the		that there is space to negotiate possible future variants of the
	protocol, either if a variant of AccECN is required, or if a		protocol, either if a variant of AccECN is required, or if a
	completely different ECN feedback approach is needed.		completely different ECN feedback approach is needed.
	Future AccECN variants: When the AccECN capability is negotiated		Future AccECN variants: When the AccECN capability is negotiated
	during TCP's three-way handshake, the rows in Table 2 tagged as		during TCP's three-way handshake, the rows in Table 2 tagged as
	'Nonce' and 'Broken' in the column for the capability of node B		'Nonce' and 'Broken' in the column for the capability of node B
	are unused by any current protocol defined in the RFC series.		are unused by any current protocol defined in the RFC Series.
	These could be used by TCP Servers in the future to indicate a		These could be used by TCP Servers in the future to indicate a
	variant of the AccECN protocol. In recent measurement studies in		variant of the AccECN protocol. In recent measurement studies in
	which the response of large numbers of Servers to an AccECN SYN		which the response of large numbers of Servers to an AccECN SYN
	has been tested, e.g., [Mandalari18], a very small number of SYN/		has been tested, e.g., [Mandalari18], a very small number of SYN/
	ACKs arrive with the pattern tagged as 'Nonce', and a small but		ACKs arrive with the pattern tagged as 'Nonce', and a small but
	more significant number arrive with the pattern tagged as		more significant number arrive with the pattern tagged as
	'Broken'. The 'Nonce' pattern could be a sign that a few Servers		'Broken'. The 'Nonce' pattern could be a sign that a few Servers
	have implemented the ECN-nonce [RFC3540], which has now been		have implemented the ECN-nonce [RFC3540], which has now been
	reclassified as Historic [RFC8311], or it could be the random		reclassified as Historic [RFC8311], or it could be the random
	result of some unknown middlebox behaviour. The greater		result of some unknown middlebox behaviour. The greater
End of changes. 8 change blocks.
	9 lines changed or deleted		8 lines changed or added
This html diff was produced by rfcdiff 1.48.