Diff: rfc9768v9.txt - rfc9768.txt

	rfc9768v9.txt	rfc9768.txt

	skipping to change at line 156 ¶	skipping to change at line 156 ¶

	1. Introduction	1. Introduction

	Explicit Congestion Notification (ECN) [RFC3168] is a mechanism by	Explicit Congestion Notification (ECN) [RFC3168] is a mechanism by
	which network nodes can mark IP packets instead of dropping them to	which 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. In RFC 3168, ECN was specified for TCP in such a way that	sender. In RFC 3168, ECN was specified for TCP in such a way that
	only one feedback signal could be transmitted per Round-Trip Time	only one feedback signal could be transmitted per Round-Trip Time
	(RTT). This is sufficient for congestion control schemes like Reno	(RTT). This is sufficient for congestion control schemes like Reno

	[RFC6582] and CUBIC [RFC9438], as those schemes reduce their	[RFC5681] and CUBIC [RFC9438], as those schemes reduce their
	congestion window by a fixed factor if congestion occurs within an	congestion window by a fixed factor if congestion occurs within an
	RTT independent of the number of received congestion markings. More	RTT independent of the number of received congestion markings. More
	recently defined mechanisms like Congestion Exposure (ConEx	recently defined mechanisms like Congestion Exposure (ConEx
	[RFC7713]), DCTCP [RFC8257], and L4S [RFC9330] need to know when more	[RFC7713]), DCTCP [RFC8257], and L4S [RFC9330] need to know when more
	than one marking is received in one RTT, which is information that	than one marking is received in one RTT, which is information that
	cannot be provided by the feedback scheme as specified in [RFC3168].	cannot be provided by the feedback scheme as specified in [RFC3168].
	This document specifies an update to the ECN feedback scheme of RFC	This document specifies an update to the ECN feedback scheme of RFC
	3168 that provides more accurate information and could be used by	3168 that provides more accurate information and could be used by
	these and potentially other future TCP extensions, while still also	these and potentially other future TCP extensions, while still also
	supporting the pre-existing TCP congestion controllers that use just	supporting the pre-existing TCP congestion controllers that use just

	skipping to change at line 1199 ¶	skipping to change at line 1199 ¶

	Both parts of each of these conditions are equally important. For	Both parts of each of these conditions are equally important. For
	instance, even if AccECN negotiation has been successful, the ACE	instance, even if AccECN negotiation has been successful, the ACE
	field is not defined on any segments with SYN=1 (e.g., a	field is not defined on any segments with SYN=1 (e.g., a
	retransmission of an unacknowledged SYN/ACK, or when both ends send	retransmission of an unacknowledged SYN/ACK, or when both ends send
	SYN/ACKs after AccECN support has been successfully negotiated during	SYN/ACKs after AccECN support has been successfully negotiated during
	a simultaneous open).	a simultaneous open).

	3.2.2.1. ACE Field on the ACK of the SYN/ACK	3.2.2.1. ACE Field on the ACK of the SYN/ACK


	A TCP Client (A) in AccECN mode MUST feed back which of the 4	If the TCP Client (A) in AccECN mode uses a pure ACK with no SACK
	possible values of the IP-ECN field was on the SYN/ACK when writing	blocks to acknowledge the SYN/ACK, it MUST use the binary encoding in
	the ACE field of a pure ACK with no SACK blocks by using the binary	Table 3 when writing the ACE field (which is the same as the encoding
	encoding in Table 3 (which is the same as that used on the SYN/ACK in	used on the SYN/ACK in Table 2). This feeds back which of the 4
	Table 2). This shall be called the "handshake encoding" of the ACE	possible values of the IP-ECN field was on the SYN/ACK. This shall
	field, and it is the only exception to the rule that the ACE field	be called the "handshake encoding" of the ACE field, and it is the
	carries the 3 least significant bits of the r.cep counter on packets	only exception to the rule that the ACE field carries the 3 least
	with SYN=0.	significant bits of the r.cep counter on packets with SYN=0.

	Normally, a TCP Client acknowledges a SYN/ACK with an ACK that	Normally, a TCP Client acknowledges a SYN/ACK with an ACK that
	satisfies the above conditions anyway (SYN=0, no data, no SACK	satisfies the above conditions anyway (SYN=0, no data, no SACK
	blocks). If an AccECN TCP Client intends to acknowledge the SYN/ACK	blocks). If an AccECN TCP Client intends to acknowledge the SYN/ACK
	with a packet that does not satisfy these conditions (e.g., it has	with a packet that does not satisfy these conditions (e.g., it has
	data to include on the ACK), it SHOULD first send a pure ACK that	data to include on the ACK), it SHOULD first send a pure ACK that
	does satisfy these conditions (see Section 5.2), so that it can feed	does satisfy these conditions (see Section 5.2), so that it can feed
	back which of the four values of the IP-ECN field arrived on the SYN/	back which of the four values of the IP-ECN field arrived on the SYN/
	ACK. A valid exception to this "SHOULD" would be where the	ACK. A valid exception to this "SHOULD" would be where the
	implementation will only be used in an environment where mangling of	implementation will only be used in an environment where mangling of

	skipping to change at line 2052 ¶	skipping to change at line 2052 ¶

	* the Data Receiver SHOULD include a counter that has continued	* the Data Receiver SHOULD include a counter that has continued
	to increment on the next scheduled ACK following a change-	to increment on the next scheduled ACK following a change-
	triggered AccECN TCP Option;	triggered AccECN TCP Option;

	* while the same counter continues to increment, it SHOULD	* while the same counter continues to increment, it SHOULD
	include the counter every n ACKs as consistently as possible,	include the counter every n ACKs as consistently as possible,
	where n can be chosen by the implementer;	where n can be chosen by the implementer;

	* it SHOULD always include an AccECN Option if the r.ceb counter	* it SHOULD always include an AccECN Option if the r.ceb counter

	is incrementing and it MAY include an AccECN Option if r.ec0b	is incrementing and it MAY include an AccECN Option if r.e0b or
	or r.ec1b is incrementing;	r.e1b is incrementing;

	* it SHOULD include each counter at least once for every 2^22	* it SHOULD include each counter at least once for every 2^22
	bytes incremented to prevent overflow during continual	bytes incremented to prevent overflow during continual
	repetition.	repetition.

	The above rules complement those in Section 3.2.2.5, which determine	The above rules complement those in Section 3.2.2.5, which determine
	when to generate an ACK irrespective of whether an AccECN TCP Option	when to generate an ACK irrespective of whether an AccECN TCP Option
	is to be included.	is to be included.

	The recommended scheme is intended as a simple way to ensure that all	The recommended scheme is intended as a simple way to ensure that all

	skipping to change at line 2079 ¶	skipping to change at line 2079 ¶

	As an example of the recommended scheme, if ECT(0) is the only	As an example of the recommended scheme, if ECT(0) is the only
	codepoint that has ever arrived in the IP-ECN field, the Data	codepoint that has ever arrived in the IP-ECN field, the Data
	Receiver will feed back an AccECN0 TCP Option with only the EE0B	Receiver will feed back an AccECN0 TCP Option with only the EE0B
	field on every packet that acknowledges new data. However, as soon	field on every packet that acknowledges new data. However, as soon
	as even one CE-marked packet arrives, on every packet that	as even one CE-marked packet arrives, on every packet that
	acknowledges new data it will start to include an option with two	acknowledges new data it will start to include an option with two
	fields, EE0B and ECEB. As a second example, if the first packet to	fields, EE0B and ECEB. As a second example, if the first packet to
	arrive happens to be CE marked, the Data Receiver will have to	arrive happens to be CE marked, the Data Receiver will have to
	arbitrarily choose whether to precede the ECEB field with an EE0B	arbitrarily choose whether to precede the ECEB field with an EE0B

	field or an EE1B field. If it chooses, say, EEB0 but it turns out	field or an EE1B field. If it chooses, say, EE0B but it turns out
	never to receive ECT(0), it can start sending EE1B and ECEB instead	never to receive ECT(0), it can start sending EE1B and ECEB instead
	-- it does not have to include the EE0B field if the r.e0b counter	-- it does not have to include the EE0B field if the r.e0b counter
	never changed during the connection.	never changed during the connection.

	With the recommended scheme, if the data sending direction switches	With the recommended scheme, if the data sending direction switches
	during a connection, there can be cases where the AccECN TCP Option	during a connection, there can be cases where the AccECN TCP Option
	that is meant to feed back the counter values at the end of a volley	that is meant to feed back the counter values at the end of a volley
	in one direction never reaches the other peer due to packet loss.	in one direction never reaches the other peer due to packet loss.
	ACE feedback ought to be sufficient to fill this gap, given accurate	ACE feedback ought to be sufficient to fill this gap, given accurate
	feedback becomes moot after data transmission has paused.	feedback becomes moot after data transmission has paused.

	skipping to change at line 2733 ¶	skipping to change at line 2733 ¶

	[RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding	[RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding
	Acknowledgement Congestion Control to TCP", RFC 5690,	Acknowledgement Congestion Control to TCP", RFC 5690,
	DOI 10.17487/RFC5690, February 2010,	DOI 10.17487/RFC5690, February 2010,
	<https://www.rfc-editor.org/info/rfc5690>.	<https://www.rfc-editor.org/info/rfc5690>.

	[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP	[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
	Authentication Option", RFC 5925, DOI 10.17487/RFC5925,	Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
	June 2010, <https://www.rfc-editor.org/info/rfc5925>.	June 2010, <https://www.rfc-editor.org/info/rfc5925>.


	[RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The
	NewReno Modification to TCP's Fast Recovery Algorithm",
	RFC 6582, DOI 10.17487/RFC6582, April 2012,
	<https://www.rfc-editor.org/info/rfc6582>.

	[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,	[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
	and K. Carlberg, "Explicit Congestion Notification (ECN)	and K. Carlberg, "Explicit Congestion Notification (ECN)
	for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August	for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
	2012, <https://www.rfc-editor.org/info/rfc6679>.	2012, <https://www.rfc-editor.org/info/rfc6679>.

	[RFC6994] Touch, J., "Shared Use of Experimental TCP Options",	[RFC6994] Touch, J., "Shared Use of Experimental TCP Options",
	RFC 6994, DOI 10.17487/RFC6994, August 2013,	RFC 6994, DOI 10.17487/RFC6994, August 2013,
	<https://www.rfc-editor.org/info/rfc6994>.	<https://www.rfc-editor.org/info/rfc6994>.

	[RFC7141] Briscoe, B. and J. Manner, "Byte and Packet Congestion	[RFC7141] Briscoe, B. and J. Manner, "Byte and Packet Congestion

End of changes. 5 change blocks.
	17 lines changed or deleted	12 lines changed or added
This html diff was produced by rfcdiff 1.48.