< draft-gomez-tcpm-ack-rate-request-03.txt		draft-gomez-tcpm-ack-rate-request-04.txt >
	TCPM Working Group C.G. Gomez		TCPM Working Group C. Gomez
	Internet-Draft UPC		Internet-Draft UPC
	Intended status: Experimental J.C. Crowcroft		Intended status: Experimental J. Crowcroft
	Expires: 7 September 2022 University of Cambridge		Expires: 28 September 2022 University of Cambridge
	March 2022		March 2022
	TCP ACK Rate Request Option		TCP ACK Rate Request Option
	draft-gomez-tcpm-ack-rate-request-03		draft-gomez-tcpm-ack-rate-request-04
	Abstract		Abstract
	TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism		TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism
	that allows reducing protocol overhead in many scenarios. However,		that allows reducing protocol overhead in many scenarios. However,
	Delayed ACKs may also contribute to suboptimal performance. When a		Delayed ACKs may also contribute to suboptimal performance. When a
	relatively large congestion window (cwnd) can be used, less frequent		relatively large congestion window (cwnd) can be used, less frequent
	ACKs may be desirable. On the other hand, in relatively small cwnd		ACKs may be desirable. On the other hand, in relatively small cwnd
	scenarios, eliciting an immediate ACK may avoid unnecessary delays		scenarios, eliciting an immediate ACK may avoid unnecessary delays
	that may be incurred by the Delayed ACKs mechanism. This document		that may be incurred by the Delayed ACKs mechanism. This document
	skipping to change at page 2, line 27 ¶		skipping to change at page 2, line 27 ¶
	3.2. Receiver behavior . . . . . . . . . . . . . . . . . . . . 4		3.2. Receiver behavior . . . . . . . . . . . . . . . . . . . . 4
	4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Changing the ACK rate during the lifetime of a TCP		5. Changing the ACK rate during the lifetime of a TCP
	connection . . . . . . . . . . . . . . . . . . . . . . . 6		connection . . . . . . . . . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9.1. Normative References . . . . . . . . . . . . . . . . . . 8		9.1. Normative References . . . . . . . . . . . . . . . . . . 8
	9.2. Informative References . . . . . . . . . . . . . . . . . 9		9.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	Delayed Acknowledgments (ACKs) were specified for TCP with the aim to		Delayed Acknowledgments (ACKs) were specified for TCP with the aim to
	reduce protocol overhead [RFC1122]. With Delayed ACKs, a TCP delays		reduce protocol overhead [RFC1122]. With Delayed ACKs, a TCP delays
	sending an ACK by up to 500 ms (often 200 ms, with lower values in		sending an ACK by up to 500 ms (often 200 ms, with lower values in
	recent implementations such as ~50 ms also reported), and typically		recent implementations such as ~50 ms also reported), and typically
	sends an ACK for at least every second segment received in a stream		sends an ACK for at least every second segment received in a stream
	of full-sized segments. This allows combining several segments into		of full-sized segments. This allows combining several segments into
	a single one (e.g. the application layer response to an application		a single one (e.g. the application layer response to an application
	skipping to change at page 4, line 37 ¶		skipping to change at page 4, line 37 ¶
	the R value requested by the sender (see section 4).		the R value requested by the sender (see section 4).
	When a TCP sender needs a data segment to be acknowledged immediately		When a TCP sender needs a data segment to be acknowledged immediately
	by a TARR-option-capable receiving TCP, the sender includes the TARR		by a TARR-option-capable receiving TCP, the sender includes the TARR
	option in the TCP header of the data segment, with a value of R equal		option in the TCP header of the data segment, with a value of R equal
	to 1.		to 1.
	A TCP segment carrying retransmitted data is not required to include		A TCP segment carrying retransmitted data is not required to include
	a TARR option.		a TARR option.
	A TCP sender that uses time-based loss detection (e.g. RACK-TLP
	[RFC8985] MAY use the Ignore Order feature, by which the sender
	indicates that it has a reordering tolerance of R packets.
	Otherwise, such feature SHOULD NOT be used. The Ignore Order feature
	can be used by setting the Ignore Order field of the TARR option to
	True (see Section 4).
	3.2. Receiver behavior		3.2. Receiver behavior
	A receiving TCP conforming to this specification MUST process a TARR		A receiving TCP conforming to this specification MUST process a TARR
	option present in a received segment.		option present in a received segment.
	A TARR-option-capable receiving TCP SHOULD modify its ACK rate to one		A TARR-option-capable receiving TCP SHOULD modify its ACK rate to one
	ACK every R received data segments from the sender. If a TARR-		ACK every R received data segments from the sender. If a TARR-
	option-capable TCP receives a segment carrying the TARR option with		option-capable TCP receives a segment carrying the TARR option with
	R=1, the receiving TCP SHOULD send an ACK immediately.		R=1, the receiving TCP SHOULD send an ACK immediately.
	If packet reordering occurs, a TCP receiver should send an immediate		If packet reordering occurs, a TARR-option-capable receiver should
	duplicate ACK when an out-of-order segment arrives [RFC2581], thus in		send a duplicate ACK immediately when an out-of-order segment arrives
	such cases the TCP receiver will not comply with the request. Note		[RFC5681]. After sending a duplicate ACK, the receiver MAY send the
	also that the receiver might be unable to send ACKs at the requested		next non-duplicate ACK after R data segments received. Note also
	rate (e.g., due to lack of resources); on the other hand, the		that the receiver might be unable to send ACKs at the requested rate
	receiver might opt not to fulfill a request for security reasons		(e.g., due to lack of resources); on the other hand, the receiver
	(e.g., to avoid or mitigate an attack by which a large number of		might opt not to fulfill a request for security reasons (e.g., to
	senders request disabling delayed ACKs simultaneously and send a		avoid or mitigate an attack by which a large number of senders
	large number of data segments to the receiver).		request disabling delayed ACKs simultaneously and send a large number
			of data segments to the receiver).
	The request to modify the ACK rate of the receiver holds until the		The request to modify the ACK rate of the receiver holds until the
	next segment carrying a TARR option is received.		next segment carrying a TARR option is received.
	A TARR-option-capable TCP that receives a TARR option with the Ignore
	Order (I) field set to True (see Section 4), MUST NOT send an ACK
	after each reordered data segment. Instead, it MUST continue to send
	one ACK every R received data segments. Otherwise (i.e., Ignore
	Order = False), such a receiver will need to send an ACK after each
	reordered data segment received.
	4. Option Format		4. Option Format
	The TARR option presents two different formats that can be identified		The TARR option presents two different formats that can be identified
	by the corresponding format length. For packets that have the SYN		by the corresponding format length. For packets that have the SYN
	bit set, the TARR option has the format shown in Fig. 1.		bit set, the TARR option has the format shown in Fig. 1.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Kind | Length | ExID |		| Kind | Length | ExID |
	skipping to change at page 6, line 10 ¶		skipping to change at page 5, line 42 ¶
	0x00AC.		0x00AC.
	For packets that do not have the SYN bit set, the TARR option has the		For packets that do not have the SYN bit set, the TARR option has the
	format and content shown in Fig. 2.		format and content shown in Fig. 2.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Kind | Length | ExID |		| Kind | Length | ExID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| R |V|I|		| R |V|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 2: TCP ACK Rate Request option format.		Figure 2: TCP ACK Rate Request option format.
	Kind: The Kind field value is TBD.		Kind: The Kind field value is TBD.
	Length: The Length field value is 5 bytes.		Length: The Length field value is 5 bytes.
	ExID: The experiment ID field size is 2 bytes, and its value is		ExID: The experiment ID field size is 2 bytes, and its value is
	0x00AC.		0x00AC.
	R: The size of this field is 6 bits. The field carries the ACK rate		R: The size of this field is 7 bits. The field carries the ACK rate
	requested by the sender. The minimum value of R is 1.		requested by the sender. The minimum value of R is 1.
			Note: there are currently two options being considered regarding the
			semantics of the R field:
	OPTION 1: the R field corresponds to the binary encoding of the		OPTION 1: the R field corresponds to the binary encoding of the
	requested ACK rate. The maximum value of R is 63. A receiver MUST		requested ACK rate. The maximum value of R is 127. A receiver MUST
	ignore an R field with all bits set to zero.		ignore an R field with all bits set to zero. (TO-DO: if OPTION 1 is
			selected, see how to handle all bits of R being equal to zero.)
	OPTION 2: the R field is composed of two subfields: the 4 leftmost		OPTION 2: the R field is composed of two subfields: the 5 leftmost
	bits represent a mantissa (m) and the 2 rightmost bits represent an		bits represent a mantissa (m) and the 2 rightmost bits represent an
	exponent (e). The value of the requested ACJ rate is obtained as R =		exponent (e). The value of the requested ACK rate is obtained as R =
	(m+1)*2^(2*e). The maximum value of R is 1024.		(m+1)*2^(2*e). The maximum value of R is 2048.
	ReserVed (V): The size of this field is 1 bit. This bit is reserved		ReserVed (V): The size of this field is 1 bit. This bit is reserved
	for future use.		for future use.
	Ignore Order (I): The size of this field is 1 bit. This field either
	has the value 1 ("True") or 0 ("False"). When this field is set to
	True, the receiver MUST NOT send an ACK after each reordered data
	segment. Instead, it SHOULD continue to send one ACK every R
	received data segments.
	5. Changing the ACK rate during the lifetime of a TCP connection		5. Changing the ACK rate during the lifetime of a TCP connection
	In some scenarios, especially when conditions are rather stable and/		In some scenarios, setting the ACK rate once for the whole lifetime
	or predictable, setting the ACK rate once for the whole lifetime of a		of a TCP connection may be suitable. However, there are also cases
	TCP connection may be suitable. However, there are also cases where		where it may be desirable to modify the ACK rate during the lifetime
	it may be desirable to modify the ACK rate during the lifetime of a		of a connection.
	connection.
	The ACK rate to be used may depend on the cwnd value used by the		The ACK rate to be used may depend on the cwnd value used by the
	sender, which can change over the lifetime of a connection. cwnd will		sender, which can change over the lifetime of a connection. cwnd will
	start at a low value and grow rapidly during the slow-start phase,		start at a low value and grow rapidly during the slow-start phase,
	then settle into a reasonably consistent range for the congestion-		then settle into a reasonably consistent range for the congestion-
	avoidance phase - assuming the underlying bandwidth-delay product		avoidance phase - assuming the underlying bandwidth-delay product
	(BDP) remains constant. Phenomena such as routing updates, link		(BDP) remains constant. Phenomena such as routing updates, link
	capacity changes or path load changes may modify the underlying BDP		capacity changes or path load changes may modify the underlying BDP
	significantly; the cwnd should be expected to change accordingly,		significantly; the cwnd should be expected to change accordingly,
	prompting the need for ACK rate updates.		prompting the need for ACK rate updates.
	skipping to change at page 8, line 6 ¶		skipping to change at page 7, line 39 ¶
	The authors plan to request the allocation of ExID value 0x00AC for		The authors plan to request the allocation of ExID value 0x00AC for
	the TCP option specified in this document.		the TCP option specified in this document.
	7. Security Considerations		7. Security Considerations
	The TARR option opens the door to new security threats. This section		The TARR option opens the door to new security threats. This section
	discusses such new threats, and suggests mitigation techniques.		discusses such new threats, and suggests mitigation techniques.
	An attacker might be able to impersonate a legitimate sender, and		An attacker might be able to impersonate a legitimate sender, and
	forge an apparently valid packet intended for the receiver, in order		forge an apparently valid packet intended for the receiver. In such
	to intentionally communicate a bad R value to the latter with the aim		case, the attacker may mount a variety of harmful actions. By using
	to damage communication or device performance. For example, in a		TARR, the attacker may intentionally communicate a bad R value to the
	small cwnd scenario, using a too high R value may lead to exacerbated		latter with the aim to damage communication or device performance.
	RTT increase and throughput decrease. In other scenarios, a too low		For example, in a small cwnd scenario, using a too high R value may
	R value may contribute to depleting the energy of a battery-operated		lead to exacerbated RTT increase and throughput decrease. In other
	receiver at a faster rate or may lead to increased network packet		scenarios, a too low R value may contribute to depleting the energy
	load.		of a battery-operated receiver at a faster rate or may lead to
			increased network packet load.
	While Transport Layer Security (TLS) [RFC8446] is strongly		While Transport Layer Security (TLS) [RFC8446] is strongly
	recommended for securing TCP-based communication, TLS does not		recommended for securing TCP-based communication, TLS does not
	protect TCP headers, and thus cannot protect the TARR option fields		protect TCP headers, and thus cannot protect the TARR option fields
	carried by a segment. One approach to address the problem is using		carried by a segment. One approach to address the problem is using
	network-layer protection, such as Internet Protocol Security (IPsec)		network-layer protection, such as Internet Protocol Security (IPsec)
	[RFC4301]. Another solution is using the TCP Authentication Option		[RFC4301]. Another solution is using the TCP Authentication Option
	(TCP-AO), which provides TCP segment integrity and protection against		(TCP-AO), which provides TCP segment integrity and protection against
	replay attacks [RFC5925].		replay attacks [RFC5925].
	While it is relatively hard for an off-path attacker to attack an		While it is relatively hard for an off-path attacker to attack an
	unprotected TCP session, it is RECOMMENDED for a TARR receiver to use		unprotected TCP session, it is RECOMMENDED for a TARR receiver to use
	the guidance and attack mitigation given in [RFC5961]. The TARR		the guidance and attack mitigation given in [RFC5961]. The TARR
	option MUST be ignored on a packet that is deemed invalid.		option MUST be ignored on a packet that is deemed invalid.
	A TARR receiver might opt not to fulfill a request to avoid or		A TARR receiver might opt not to fulfill a request to avoid or
	mitigate an attack by which a large number of senders request		mitigate an attack by which a large number of senders request
	disabling delayed ACKs simultaneously and send a large number of data		disabling delayed ACKs simultaneously and send a large number of data
	segments to the receiver.		segments to the receiver (see Section 3.2).
	8. Acknowledgments		8. Acknowledgments
	Bob Briscoe, Jonathan Morton, Richard Scheffenegger, Neal Cardwell,		Bob Briscoe, Jonathan Morton, Richard Scheffenegger, Neal Cardwell,
	Michael Tuexen, Yuchung Cheng, Matt Mathis, Jana Iyengar, Gorry		Michael Tuexen, Yuchung Cheng, Matt Mathis, Jana Iyengar, Gorry
	Fairhurst, and Stuart Cheshire provided useful comments and input for		Fairhurst, Stuart Cheshire, Yoshifumi Nishida, Michael Scharf, Ian
	this document. Jana Iyengar suggested including a field to allow a		Swett, and Martin Duke provided useful comments and input for this
	sender communicate its tolerance to reordering. Jonathan Morton and		document. Jana Iyengar suggested including a field to allow a sender
	Bob Briscoe provided the main input for Section 5.		communicate its tolerance to reordering. Jonathan Morton and Bob
			Briscoe provided the main input for Section 5.
	Carles Gomez has been funded in part by the Spanish Government		Carles Gomez has been funded in part by the Spanish Government
	through project PID2019-106808RA-I00, and by Secretaria		through project PID2019-106808RA-I00, and by Secretaria
	d'Universitats i Recerca del Departament d'Empresa i Coneixement de		d'Universitats i Recerca del Departament d'Empresa i Coneixement de
	la Generalitat de Catalunya 2017 through grant SGR 376.		la Generalitat de Catalunya 2017 through grant SGR 376.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -		[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
	Communication Layers", STD 3, RFC 1122,		Communication Layers", STD 3, RFC 1122,
	DOI 10.17487/RFC1122, October 1989,		DOI 10.17487/RFC1122, October 1989,
	<https://www.rfc-editor.org/info/rfc1122>.		<https://www.rfc-editor.org/info/rfc1122>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion		[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
	Control", RFC 2581, DOI 10.17487/RFC2581, April 1999,		Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
	<https://www.rfc-editor.org/info/rfc2581>.		<https://www.rfc-editor.org/info/rfc5681>.
	[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>.
	[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's		[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
	Robustness to Blind In-Window Attacks", RFC 5961,		Robustness to Blind In-Window Attacks", RFC 5961,
	DOI 10.17487/RFC5961, August 2010,		DOI 10.17487/RFC5961, August 2010,
	<https://www.rfc-editor.org/info/rfc5961>.		<https://www.rfc-editor.org/info/rfc5961>.
	[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>.
	[RFC8985] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "The
	RACK-TLP Loss Detection Algorithm for TCP", RFC 8985,
	DOI 10.17487/RFC8985, February 2021,
	<https://www.rfc-editor.org/info/rfc8985>.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-tcpm-generalized-ecn]		[I-D.ietf-tcpm-generalized-ecn]
	Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit		Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit
	Congestion Notification (ECN) to TCP Control Packets",		Congestion Notification (ECN) to TCP Control Packets",
	Work in Progress, Internet-Draft, draft-ietf-tcpm-		Work in Progress, Internet-Draft, draft-ietf-tcpm-
	generalized-ecn-09, 31 January 2022,		generalized-ecn-09, 31 January 2022,
	<https://www.ietf.org/archive/id/draft-ietf-tcpm-		<https://www.ietf.org/archive/id/draft-ietf-tcpm-
	generalized-ecn-09.txt>.		generalized-ecn-09.txt>.
End of changes. 20 change blocks.
	67 lines changed or deleted		48 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/