rfc9177v2.txt		rfc9177.txt
	Internet Engineering Task Force (IETF) M. Boucadair		Internet Engineering Task Force (IETF) M. Boucadair
	Request for Comments: 9177 Orange		Request for Comments: 9177 Orange
	Category: Standards Track J. Shallow		Category: Standards Track J. Shallow
	ISSN: 2070-1721 February 2022		ISSN: 2070-1721 March 2022
	Constrained Application Protocol (CoAP) Block-Wise Transfer Options		Constrained Application Protocol (CoAP) Block-Wise Transfer Options
	Supporting Robust Transmission		Supporting Robust Transmission
	Abstract		Abstract
	This document specifies alternative Constrained Application Protocol		This document specifies alternative Constrained Application Protocol
	(CoAP) block-wise transfer options: Q-Block1 and Q-Block2.		(CoAP) block-wise transfer options: Q-Block1 and Q-Block2.
	These options are similar to, but distinct from, the CoAP Block1 and		These options are similar to, but distinct from, the CoAP Block1 and
	skipping to change at line 1037 ¶		skipping to change at line 1037 ¶
	Table 3: Congestion Control Parameters		Table 3: Congestion Control Parameters
	The PROBING_RATE parameter in CoAP indicates the average data rate		The PROBING_RATE parameter in CoAP indicates the average data rate
	that must not be exceeded by a CoAP endpoint in sending to a peer		that must not be exceeded by a CoAP endpoint in sending to a peer
	endpoint that does not respond. A single body will be subjected to		endpoint that does not respond. A single body will be subjected to
	PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets.		PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets.
	If the wait time between sending bodies that are not being responded		If the wait time between sending bodies that are not being responded
	to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time		to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time
	is limited to NON_PROBING_WAIT.		is limited to NON_PROBING_WAIT.
	Note: For the particular DOTS application, PROBING_RATE and other		| Note: For the particular DOTS application, PROBING_RATE and
	transmission parameters are negotiated between peers. Even when		| other transmission parameters are negotiated between peers.
	not negotiated, the DOTS application uses customized defaults, as		| Even when not negotiated, the DOTS application uses customized
	discussed in Section 4.5.2 of [RFC9132]. Note that MAX_PAYLOADS,		| defaults, as discussed in Section 4.5.2 of [RFC9132]. Note
	NON_MAX_RETRANSMIT, NON_TIMEOUT, NON_PROBING_WAIT, and		| that MAX_PAYLOADS, NON_MAX_RETRANSMIT, NON_TIMEOUT,
	NON_PARTIAL_TIMEOUT can be negotiated between DOTS peers, e.g., as		| NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT can be negotiated
	per [DOTS-QUICK-BLOCKS]. When explicit values are configured for		| between DOTS peers, e.g., as per [DOTS-QUICK-BLOCKS]. When
	NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT, these values are used		| explicit values are configured for NON_PROBING_WAIT and
	without applying any jitter.		| NON_PARTIAL_TIMEOUT, these values are used without applying any
			| jitter.
	Each NON 4.08 (Request Entity Incomplete) response is subject to		Each NON 4.08 (Request Entity Incomplete) response is subject to
	PROBING_RATE.		PROBING_RATE.
	Each NON GET or FETCH request using a Q-Block2 option is subject to		Each NON GET or FETCH request using a Q-Block2 option is subject to
	PROBING_RATE.		PROBING_RATE.
	As the sending of many payloads of a single body may itself cause		As the sending of many payloads of a single body may itself cause
	congestion, after transmission of every MAX_PAYLOADS_SET of a single		congestion, after transmission of every MAX_PAYLOADS_SET of a single
	body, a delay of NON_TIMEOUT_RANDOM MUST be introduced before sending		body, a delay of NON_TIMEOUT_RANDOM MUST be introduced before sending
	skipping to change at line 1083 ¶		skipping to change at line 1084 ¶
	(Continue) response code for the latest payload sent, then the client		(Continue) response code for the latest payload sent, then the client
	can continue to send the next MAX_PAYLOADS_SET without any further		can continue to send the next MAX_PAYLOADS_SET without any further
	delay. If the server responds with a 4.08 (Request Entity		delay. If the server responds with a 4.08 (Request Entity
	Incomplete) response code, then the missing payloads SHOULD be		Incomplete) response code, then the missing payloads SHOULD be
	retransmitted before going into another NON_TIMEOUT_RANDOM delay		retransmitted before going into another NON_TIMEOUT_RANDOM delay
	prior to sending the next set of payloads.		prior to sending the next set of payloads.
	For the server receiving NON Q-Block1 requests, it SHOULD send back a		For the server receiving NON Q-Block1 requests, it SHOULD send back a
	2.31 (Continue) response code on receipt of all of the		2.31 (Continue) response code on receipt of all of the
	MAX_PAYLOADS_SET to prevent the client unnecessarily delaying the		MAX_PAYLOADS_SET to prevent the client unnecessarily delaying the
	transer of remaing blocks. If not all of the MAX_PAYLOADS_SET were		transfer of remaing blocks. If not all of the MAX_PAYLOADS_SET were
	received, the server SHOULD delay for NON_RECEIVE_TIMEOUT		received, the server SHOULD delay for NON_RECEIVE_TIMEOUT
	(exponentially scaled based on the repeat request count for a		(exponentially scaled based on the repeat request count for a
	payload) before sending the 4.08 (Request Entity Incomplete) response		payload) before sending the 4.08 (Request Entity Incomplete) response
	code for the missing payload(s). If all of the MAX_PAYLOADS_SET were		code for the missing payload(s). If all of the MAX_PAYLOADS_SET were
	received and a 2.31 (Continue) response code had been sent, but no		received and a 2.31 (Continue) response code had been sent, but no
	more payloads were received for NON_RECEIVE_TIMEOUT (exponentially		more payloads were received for NON_RECEIVE_TIMEOUT (exponentially
	scaled), the server SHOULD send a 4.08 (Request Entity Incomplete)		scaled), the server SHOULD send a 4.08 (Request Entity Incomplete)
	response detailing the missing payloads after the block number that		response detailing the missing payloads after the block number that
	was indicated in the sent 2.31 (Continue) response code. If the		was indicated in the sent 2.31 (Continue) response code. If the
	repeat response count of the 4.08 (Request Entity Incomplete) exceeds		repeat response count of the 4.08 (Request Entity Incomplete) exceeds
End of changes. 3 change blocks.
	11 lines changed or deleted		12 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/