rfc9768v11.txt		rfc9768.txt
	skipping to change at line 659 ¶		skipping to change at line 659 ¶
	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
	The setting of all three flags to 1 in order to indicate AccECN		The TCP flags used to indicate AccECN support on the SYN were
	support on the SYN was carefully chosen to enable natural fall-back		carefully chosen to enable natural fall-back to prior stages in the
	to prior stages in the evolution of ECN. Table 2 tabulates all the		evolution of ECN. Table 2 tabulates all the negotiation
	negotiation possibilities for ECN-related capabilities that involve		possibilities for ECN-related capabilities that involve at least one
	at least one AccECN-capable host. The entries in the first two		AccECN-capable host. The entries in the first two columns have been
	columns have been abbreviated, as follows:		abbreviated, as follows:
	AccECN: Supports more Accurate ECN feedback (the present		AccECN: Supports more Accurate ECN feedback (the present
	specification).		specification).
	Nonce: Supports ECN-nonce feedback [RFC3540].		Nonce: Supports ECN-nonce feedback [RFC3540].
	ECN: Supports 'Classic' ECN feedback [RFC3168].		ECN: Supports 'Classic' ECN feedback [RFC3168].
	No ECN: Not ECN-capable. Implicit congestion notification using		No ECN: Not ECN-capable. Implicit congestion notification using
	packet drop.		packet drop.
	skipping to change at line 1513 ¶		skipping to change at line 1513 ¶
	RFC 3168 says that a router that changes ECT to Not-ECT is invalid		RFC 3168 says that a router that changes ECT to Not-ECT is invalid
	but safe. However, from a host's viewpoint, this transition is		but safe. However, from a host's viewpoint, this transition is
	unsafe because it could be the result of two transitions at different		unsafe because it could be the result of two transitions at different
	routers on the path: ECT to CE (safe) then CE to Not-ECT (unsafe).		routers on the path: ECT to CE (safe) then CE to Not-ECT (unsafe).
	This scenario could well happen where an ECN-enabled home router		This scenario could well happen where an ECN-enabled home router
	congests its upstream mobile broadband bottleneck link, then the		congests its upstream mobile broadband bottleneck link, then the
	ingress to the mobile network clears the ECN field [Mandalari18].		ingress to the mobile network clears the ECN field [Mandalari18].
	3.2.2.4. Testing for Zeroing of the ACE Field		3.2.2.4. Testing for Zeroing of the ACE Field
	NOTE: This section concerns the ACE field after the three way		Note that this section concerns the ACE field after the three way
	handshake. It does not concern the case where the ACE field is zero		handshake. It does not concern the case where the ACE field is zero
	when the handshake encoding has been used on the ACK of the SYN/ACK		when the handshake encoding has been used on the ACK of the SYN/ACK
	under the carefully worded conditions in Section 3.2.2.1		under the carefully worded conditions in Section 3.2.2.1
	Section 3.2.2 required the Data Receiver to initialize the r.cep		Section 3.2.2 required the Data Receiver to initialize the r.cep
	counter to a non-zero value. Therefore, in either direction the ACE		counter to a non-zero value. Therefore, in either direction the ACE
	counter ought to be non-zero in the first feedback packet (with or		counter ought to be non-zero in the first feedback packet (with or
	without data) that arrives at a host in AccECN mode after the three-		without data) that arrives at a host in AccECN mode after the three-
	way handshake. However, if reordering occurs, the first feedback		way handshake. However, if reordering occurs, the first feedback
	packet that arrives will not necessarily be the same as the first		packet that arrives will not necessarily be the same as the first
	skipping to change at line 2277 ¶		skipping to change at line 2277 ¶
	* In Section 6.1.2 (The TCP Sender) of [RFC3168], all mentions of a		* In Section 6.1.2 (The TCP Sender) of [RFC3168], all mentions of a
	congestion response to an ECN-Echo (ECE) ACK packet are updated by		congestion response to an ECN-Echo (ECE) ACK packet are updated by
	Section 3.2 of the present specification to mean an increment to		Section 3.2 of the present specification to mean an increment to
	the sender's count of CE-marked packets, s.cep. And the		the sender's count of CE-marked packets, s.cep. And the
	requirements to set the CWR flag no longer apply, as specified in		requirements to set the CWR flag no longer apply, as specified in
	Section 3.1.5 of the present specification. Otherwise, the		Section 3.1.5 of the present specification. Otherwise, the
	remaining requirements in Section 6.1.2 (The TCP Sender) of		remaining requirements in Section 6.1.2 (The TCP Sender) of
	[RFC3168] still stand.		[RFC3168] still stand.
	It will be noted that [RFC8311] already updates a number of the		Note that [RFC8311] already updates a number of the requirements
	requirements in Section 6.1.2 (The TCP Sender) of [RFC3168].		in Section 6.1.2 (The TCP Sender) of [RFC3168]. Section 6.1.2 of
	Section 6.1.2 of [RFC3168] extended standard TCP congestion		[RFC3168] extended standard TCP congestion control [RFC5681] to
	control [RFC5681] to cover ECN marking as well as packet drop.		cover ECN marking as well as packet drop. Whereas, [RFC8311]
	Whereas, [RFC8311] enables experimentation with alternative		enables experimentation with alternative responses to ECN marking,
	responses to ECN marking, if specified for instance by an		if specified for instance by an Experimental RFC produced by the
	Experimental RFC produced by the IETF Stream. [RFC8311] also		IETF Stream. [RFC8311] also strengthened the statement that
	strengthened the statement that "ECT(0) SHOULD be used" to a		"ECT(0) SHOULD be used" to a "MUST" (see [RFC8311] for the
	"MUST" (see [RFC8311] for the details).		details).
	* The whole of Section 6.1.3 (The TCP Receiver) of [RFC3168] is		* The whole of Section 6.1.3 (The TCP Receiver) of [RFC3168] is
	updated by Section 3.2 of the present specification, with the		updated by Section 3.2 of the present specification, with the
	exception of the last paragraph (about congestion response to drop		exception of the last paragraph (about congestion response to drop
	and ECN in the same round trip), which still stands.		and ECN in the same round trip), which still stands.
	Incidentally, this last paragraph is in the wrong section, because		Incidentally, this last paragraph is in the wrong section, because
	it relates to "TCP Sender" behaviour.		it relates to "TCP Sender" behaviour.
	* The following text within Section 6.1.5 (Retransmitted TCP		* The following text within Section 6.1.5 (Retransmitted TCP
	packets) of [RFC3168]:		packets) of [RFC3168]:
	skipping to change at line 3154 ¶		skipping to change at line 3154 ¶
	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 to be able to fall back to Classic ECN [RFC3168],
	[RFC3168], or to disable ECN support, without another round of		or to disable ECN support, without another round of negotiation.
	negotiation. Then AccECN would also have had to handle all the		Then AccECN would also have had to handle all the different ways that
	different ways that Servers currently respond to settings of the ECN		Servers currently respond to settings of the ECN flags in the main
	flags in the main TCP header, including all of the conflicting cases		TCP header, including all of the conflicting cases where a Server
	where a Server might have said it supported one approach in the flags		might have said it supported one approach in the flags and another
	and another approach in a new TCP Option. And AccECN would have had		approach in a new TCP Option. And AccECN would have had to deal with
	to deal with all of the additional possibilities where a middlebox		all of the additional possibilities where a middlebox might have
	might have mangled the ECN flags, or removed TCP Options. Thus,		mangled the ECN flags, or removed TCP Options. Thus, usage of the
	usage of the 3rd reserved TCP header flag simplified the protocol.		3rd reserved TCP header flag simplified the protocol.
	The third flag was used in a way that could be distinguished from the		The third flag was used in a way that could be distinguished from the
	ECN-nonce, in case any nonce deployment was encountered. Previous		ECN-nonce, in case any nonce deployment was encountered. Previous
	usage of this flag for the ECN-nonce was integrated into the original		usage of this flag for the ECN-nonce was integrated into the original
	ECN negotiation. This further justified the third flag's use for		ECN negotiation. This further justified the third flag's use for
	AccECN, because a non-ECN usage of this flag would have had to use it		AccECN, because a non-ECN usage of this flag would have had to use it
	as a separate single bit, rather than in combination with the other 2		as a separate single bit, rather than in combination with the other 2
	ECN flags.		ECN flags.
	Indeed, having overloaded the original uses of these three flags for		Indeed, having overloaded the original uses of these three flags for
End of changes. 4 change blocks.
	26 lines changed or deleted		26 lines changed or added
This html diff was produced by rfcdiff 1.48.