< draft-bormann-core-cocoa-01.txt		draft-bormann-core-cocoa-02.txt >
	CoRE Working Group C. Bormann		CoRE Working Group C. Bormann
	Internet-Draft Universitaet Bremen TZI		Internet-Draft Universitaet Bremen TZI
	Intended status: Informational February 14, 2014		Intended status: Informational A. Betzler
	Expires: August 18, 2014		Expires: January 4, 2015 C. Gomez
			I. Demirkol
			Universitat Politecnica de Catalunya/Fundacio i2CAT
			July 03, 2014
	CoAP Simple Congestion Control/Advanced		CoAP Simple Congestion Control/Advanced
	draft-bormann-core-cocoa-01		draft-bormann-core-cocoa-02
	Abstract		Abstract
	The CoAP protocol needs to be implemented in such a way that it does		The CoAP protocol needs to be implemented in such a way that it does
	not cause persistent congestion on the network it uses. The CoRE		not cause persistent congestion on the network it uses. The CoRE
	CoAP specification defines basic behavior that exhibits low risk of		CoAP specification defines basic behavior that exhibits low risk of
	congestion with minimal implementation requirements. It also leaves		congestion with minimal implementation requirements. It also leaves
	room for combining the base specification with advanced congestion		room for combining the base specification with advanced congestion
	control mechanisms with higher performance.		control mechanisms with higher performance.
	This specification defines some simple advanced CoRE Congestion		This specification defines some simple advanced CoRE Congestion
	Control mechanisms, Simple CoCoA. In the present version -01, it is		Control mechanisms, Simple CoCoA. In the present version -02, it is
	already making use of some input from simulations, but might still		making use of input from simulations and experiments in real
	benefit from simplifying it further.		networks. The specification might still benefit from simplifying it
			further.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 18, 2014.		This Internet-Draft will expire on January 4, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Advanced CoAP Congestion Control: RTO Estimation . . . . . . 3		3. Advanced CoAP Congestion Control: RTO Estimation . . . . . . 4
	3.1. Blind RTO Estimate . . . . . . . . . . . . . . . . . . . 4		3.1. Blind RTO Estimate . . . . . . . . . . . . . . . . . . . 4
	3.2. Measured RTO Estimate . . . . . . . . . . . . . . . . . . 4		3.2. Measured RTO Estimate . . . . . . . . . . . . . . . . . . 5
	3.2.1. Modifications to the algorithm of RFC 6298 . . . . . 5		3.2.1. Modifications to the algorithm of RFC 6298 . . . . . 5
	3.2.2. Discussion . . . . . . . . . . . . . . . . . . . . . 5		3.2.2. Discussion . . . . . . . . . . . . . . . . . . . . . 6
	3.3. Lifetime, Aging . . . . . . . . . . . . . . . . . . . . . 5		3.3. Lifetime, Aging . . . . . . . . . . . . . . . . . . . . . 6
	4. Advanced CoAP Congestion Control: Non-Confirmables . . . . . 6		4. Advanced CoAP Congestion Control: Non-Confirmables . . . . . 6
	4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 6		4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Normative References . . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . 8
	8.2. Informative References . . . . . . . . . . . . . . . . . 8		8.2. Informative References . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	(See Abstract.)		(See Abstract.)
	Extended rationale for this specification can be found in		Extended rationale for this specification can be found in
	[I-D.bormann-core-congestion-control] and		[I-D.bormann-core-congestion-control] and
	[I-D.eggert-core-congestion-control], as well as in the minutes of		[I-D.eggert-core-congestion-control], as well as in the minutes of
	the IETF 84 CoRE WG meetings.		the IETF 84 CoRE WG meetings.
	1.1. Terminology		1.1. Terminology
	This specification uses terms from [I-D.ietf-core-coap]. In		This specification uses terms from [RFC7252]. In addition, it
	addition, it defines the following terminology:		defines the following terminology:
	Initiator: The endpoint that sends the message that initiates an		Initiator: The endpoint that sends the message that initiates an
	exchange. E.g., the party that sends a confirmable message, or a		exchange. E.g., the party that sends a confirmable message, or a
	non-confirmable message conveying a request.		non-confirmable message conveying a request.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119] when they		document are to be interpreted as described in [RFC2119] when they
	appear in ALL CAPS. These words may also appear in this document in		appear in ALL CAPS. These words may also appear in this document in
	lower case as plain English words, absent their normative meanings.		lower case as plain English words, absent their normative meanings.
	skipping to change at page 3, line 22 ¶		skipping to change at page 3, line 34 ¶
	sense as a synonym for "octet".		sense as a synonym for "octet".
	2. Context		2. Context
	In the Vancouver IETF 84 CoRE meeting, a path forward was defined		In the Vancouver IETF 84 CoRE meeting, a path forward was defined
	that includes a very simple basic scheme (lock-step with a number of		that includes a very simple basic scheme (lock-step with a number of
	parallel exchanges of 1) in the base specification together with		parallel exchanges of 1) in the base specification together with
	performance-enhancing advanced mechanisms.		performance-enhancing advanced mechanisms.
	The present specification is based on the approved text in the		The present specification is based on the approved text in the
	[I-D.ietf-core-coap] base specification. It is making use of the		[RFC7252] base specification. It is making use of the text that
	text that permits advanced congestion control mechanisms and allows		permits advanced congestion control mechanisms and allows them to
	them to change protocol parameters, including NSTART and the binary		change protocol parameters, including NSTART and the binary
	exponential backoff mechanism. Note that Section 4.8 of		exponential backoff mechanism. Note that Section 4.8 of [RFC7252]
	[I-D.ietf-core-coap] limits the leeway that implementations have in		limits the leeway that implementations have in changing the CoRE
	changing the CoRE protocol parameters.		protocol parameters.
	The present specification also assumes that, outside of exchanges,		The present specification also assumes that, outside of exchanges,
	non-confirmable messages can only be used at a limited rate without		non-confirmable messages can only be used at a limited rate without
	an advanced congestion control mechanism (this is mainly relevant for		an advanced congestion control mechanism (this is mainly relevant for
	-observe). It is also intended to address the [RFC5405] guideline		-observe). It is also intended to address the [RFC5405] guideline
	about combining congestion control state for a destination; and to		about combining congestion control state for a destination; and to
	clarify its meaning for CoAP using the definition of an endpoint.		clarify its meaning for CoAP using the definition of an endpoint.
	The present specification does not address multicast or dithering		The present specification does not address multicast or dithering
	beyond basic retransmission dithering.		beyond basic retransmission dithering.
	3. Advanced CoAP Congestion Control: RTO Estimation		3. Advanced CoAP Congestion Control: RTO Estimation
	For an initiator that plans to make multiple requests to one		For an initiator that plans to make multiple requests to one
	destination endpoint, it may be worthwhile to make RTT measurements		destination endpoint, it may be worthwhile to make RTT measurements
	in order to obtain a better RTO estimation than that implied by the		in order to obtain a better RTO estimation than that implied by the
	default initial timeout of 2 to 3 s. This is based on the usual		default initial timeout of 2 to 3 s. This is based on the usual
	algorithms for RTO estimation [RFC6298], with appropriately extended		algorithms for RTO estimation [RFC6298], with appropriately extended
	default/base values, as proposed in Section 3.2.1. Note that such a		default/base values, as proposed in Section 3.2.1. Note that such a
	mechanism must, during idle periods, decay RTT estimates that are		mechanism must, during idle periods, decay RTO estimates that are
	shorter than the basic RTT estimate back to the basic RTT estimate,		shorter or longer than the basic RTO estimate back to the basic RTO
	until fresh measurements become available again, as proposed in		estimate, until fresh measurements become available again, as
	Section 3.3.		proposed in Section 3.3.
	One important consideration not relevant for TCP is the fact that a		One important consideration not relevant for TCP is the fact that a
	CoAP round-trip may include application processing time, which may be		CoAP round-trip may include application processing time, which may be
	hard to predict, and may differ between different resources available		hard to predict, and may differ between different resources available
	at the same endpoint. Servers will only trigger their early ACKs		at the same endpoint. Also, for communications with networks of
	(with a non-piggybacked response to be sent later) based on the		constrained devices that apply radio duty cycling, large and variable
	default timers, e.g. after 1 s. A client that has arrived at a RTO		round-trip times are likely to be observed. Servers will only
	estimate shorter than 1 s SHOULD therefore use a larger backoff		trigger their early ACKs (with a non-piggybacked response to be sent
	factor for retransmissions to avoid expending all of its		later) based on the default timers, e.g. after 1 s. A client that
	retransmissions in the default interval of 2 to 3 s. A proposal for		has arrived at a RTO estimate shorter than 1 s SHOULD therefore use a
	a mechanism with variable backoff factors is presented in		larger backoff factor for retransmissions to avoid expending all of
			its retransmissions in the default interval of 2 to 3 s. A proposal
			for a mechanism with variable backoff factors is presented in
	Section 3.2.1.		Section 3.2.1.
	It may also be worthwhile to do RTT estimates not just based on		It may also be worthwhile to do RTT estimates not just based on
	information measured from a single destination endpoint, but also		information measured from a single destination endpoint, but also
	based on entire hosts (IP addresses) and/or complete prefixes (e.g.,		based on entire hosts (IP addresses) and/or complete prefixes (e.g.,
	maintain an RTT estimate for a whole /64). The exact way this can be		maintain an RTT estimate for a whole /64). The exact way this can be
	used to reduce the amount of state in an initiator is for further		used to reduce the amount of state in an initiator is for further
	study.		study.
	3.1. Blind RTO Estimate		3.1. Blind RTO Estimate
	The initial RTO estimate for an endpoint is set to 2 seconds.		The initial RTO estimate for an endpoint is set to 2 seconds.
	If only the initial RTO estimate is available, the RTO estimate for		If only the initial RTO estimate is available, the RTO estimate for
	each of up to NSTART exchanges started in parallel is set to 1 s		each of up to NSTART exchanges started in parallel is set to 2 s
	times 2 to the power of the number of parallel exchanges, e.g. if two		times the number of parallel exchanges, e.g. if two exchanges are
	exchanges are already running, the initial RTO estimate for an		already running, the initial RTO estimate for an additional exchange
	additional exchange is 8 seconds.		is 6 seconds.
	The binary exponential backoff is truncated at 32 seconds. Similar
	to the way retransmissions are handled in the base specification,
	they are dithered between 1 x RTO and ACK_RANDOM_FACTOR x RTO.
	3.2. Measured RTO Estimate		3.2. Measured RTO Estimate
	The RTO estimator runs two copies of the algorithm defined in		The RTO estimator runs two copies of the algorithm defined in
	[RFC6298], as modified in Section 3.2.1: One copy for exchanges that		[RFC6298], as modified in Section 3.2.1: One copy for exchanges that
	complete on initial transmissions (the "strong estimator"), and one		complete on initial transmissions (the "strong estimator"), and one
	copy for exchanges that have run into retransmissions (the "weak		copy for exchanges that have run into retransmissions, where only the
	estimator"). For the latter, there is some ambiguity whether a		first two retransmissions are considered (the "weak estimator"). For
	response is based on the initial transmission or any retransmission.		the latter, there is some ambiguity whether a response is based on
	For the purposes of the weak estimator, the time from the initial		the initial transmission or the retransmissions. For the purposes of
	transmission counts.		the weak estimator, the time from the initial transmission counts.
			Responses obtained after the third retransmission are not used to
			update an estimator.
	The overall RTO estimate is a exponentially weighted moving average		The overall RTO estimate is an exponentially weighted moving average
	(alpha = 0.5) computed of the strong and the weak estimator, which is		(alpha = 0.5) computed of the strong and the weak estimator, which is
	evolved after each contribution to the weak estimator or to the		evolved after each contribution to the weak estimator (1) or to the
	strong estimator, from the estimator that made the most recent		strong estimator (2), from the estimator that made the most recent
	contribution:		contribution:
	RTO_overall_ := 0.5 * RTO_recent_ + 0.5 * RTO_overall_		RTO_overall_ := 0.25 * RTO_weak_ + 0.75 * RTO_overall_ (1)
	(Note that the contributionof the weak estimator may be too big in		RTO_overall_ := 0.5 * RTO_strong_ + 0.5 * RTO_overall_ (2)
	naturally lossy networks. TBD.)
			(Splitting this update into the two cases avoids making the
			contribution of the weak estimator too big in naturally lossy
			networks.)
	3.2.1. Modifications to the algorithm of RFC 6298		3.2.1. Modifications to the algorithm of RFC 6298
	This subsection presents three modifications that must be applied to		This subsection presents three modifications that must be applied to
	the algorithm of [RFC6298] as per this document. The first two		the algorithm of [RFC6298] as per this document. The first two
	recommend new parameter settings. The third one is the variable		recommend new parameter settings. The third one is the variable
	backoff factor mechanism.		backoff factor mechanism.
	The initial value for each of the two RTO estimators is 2 s.		The initial value for each of the two RTO estimators is 2 s.
	For the weak estimator, the factor K (the RTT variance multiplier) is		For the weak estimator, the factor K (the RTT variance multiplier) is
	set to 1 instead of 4. This is necessary to avoid a strong increase		set to 1 instead of 4. This is necessary to avoid a strong increase
	of the RTO in the case that the RTTVAR value is very large, which may		of the RTO in the case that the RTTVAR value is very large, which may
	be the case if a weak RTT measurement is obtained after one or more		be the case if a weak RTT measurement is obtained after one or more
	retransmissions.		retransmissions.
	If an RTO estimation is lower than 1 s or higher than 8 s, instead of		If an RTO estimation is lower than 1 s or higher than 3 s, instead of
	applying a binary backoff factor in both cases, a variable backoff		applying a binary backoff factor in both cases, a variable backoff
	factor is used. For RTO estimations below 1 s, the RTO for a		factor is used. For RTO estimations below 1 s, the RTO for a
	retransmission is multiplied by 3, while for estimations above 8 s,		retransmission is multiplied by 3, while for estimations above 3 s,
	the RTO is multiplied only by 1.3 (this initial choice of numbers to		the RTO is multiplied only by 1.5 (this updated choice of numbers to
	be verified by more simulations). This helps to avoid that exchanges		be verified by more simulations). This helps to avoid that exchanges
	with small initial RTOs use up all retransmissions in a short		with small initial RTOs use up all retransmissions in a short
	interval of time and exchanges with large initial RTOs may not be		interval of time and exchanges with large initial RTOs may not be
	able to carry out all retransmissions within MAX_TRANSMIT_WAIT		able to carry out all retransmissions within MAX_TRANSMIT_WAIT
	(93 s).		(93 s).
			The binary exponential backoff is truncated at 32 seconds. Similar
			to the way retransmissions are handled in the base specification,
			they are dithered between 1 x RTO and ACK_RANDOM_FACTOR x RTO.
	3.2.2. Discussion		3.2.2. Discussion
	In contrast to [RFC6298], this algorithm attempts to make use of		In contrast to [RFC6298], this algorithm attempts to make use of
	ambiguous information from retransmissions. This is motivated by the		ambiguous information from retransmissions. This is motivated by the
	high non-congestion loss rates expected in constrained node networks,		high non-congestion loss rates expected in constrained node networks,
	and the need to update the RTO estimators even in the presence of		and the need to update the RTO estimators even in the presence of
	loss. Additional investigation is required to determine whether this		loss. Additional investigation is required to determine whether this
	is indeed justified.		is indeed justified.
	3.3. Lifetime, Aging		3.3. Lifetime, Aging
	skipping to change at page 6, line 4 ¶		skipping to change at page 6, line 23 ¶
	3.2.2. Discussion		3.2.2. Discussion
	In contrast to [RFC6298], this algorithm attempts to make use of		In contrast to [RFC6298], this algorithm attempts to make use of
	ambiguous information from retransmissions. This is motivated by the		ambiguous information from retransmissions. This is motivated by the
	high non-congestion loss rates expected in constrained node networks,		high non-congestion loss rates expected in constrained node networks,
	and the need to update the RTO estimators even in the presence of		and the need to update the RTO estimators even in the presence of
	loss. Additional investigation is required to determine whether this		loss. Additional investigation is required to determine whether this
	is indeed justified.		is indeed justified.
	3.3. Lifetime, Aging		3.3. Lifetime, Aging
	The state of the RTO estimators for an endpoint SHOULD be kept as		The state of the RTO estimators for an endpoint SHOULD be kept as
	long as possible. If other state is kept for the endpoint (such as a		long as possible. If other state is kept for the endpoint (such as a
	DTLS connection), it is very strongly RECOMMENDED to keep the RTO		DTLS connection), it is very strongly RECOMMENDED to keep the RTO
	state alive at least as long as this other state. It MUST be kept		state alive at least as long as this other state. It MUST be kept
	for at least 255 s.		for at least 255 s.
	If an estimator has a value that is lower than 1 s, and it is left		If an estimator has a value that is lower than 1 s, and it is left
	without further update for a time that is more than 16 times its		without further update for 16 times its current value, the RTO
	current value, its value is doubled.		estimate is doubled. If an estimator has a value that is higher than
			3 s, and it is left without further update for 4 times its current
			value, the RTO estimate is set to be
	(It is allowed to implement this cumulatively at the time it is used		RTO_overall_ := 1 s + (0.5 * RTO_overall_)
	next, possibly approximating multiple doublings by replacing the
	value with 1/8th of the time that has elapsed since the last update.		(Note that, instead of running a timer, it is possible to implement
	Alternatively, simple estimators can be simply updated to 1 s after		these RTO aging calculations cumulatively at the time the estimator
	being without update for a time that is more than 16 times its value,		is used next.)
	or, even simpler, be clamped at 1 s or above.)
	4. Advanced CoAP Congestion Control: Non-Confirmables		4. Advanced CoAP Congestion Control: Non-Confirmables
	(TO DO: Align this with final consensus on -observe!)		(TO DO: Align this with final consensus on -observe!)
	A CoAP endpoint MUST NOT send non-confirmables to another CoAP		A CoAP endpoint MUST NOT send non-confirmables to another CoAP
	endpoint at a rate higher than defined by this document. Independent		endpoint at a rate higher than defined by this document. Independent
	of any congestion control mechanisms, a CoAP endpoint can always send		of any congestion control mechanisms, a CoAP endpoint can always send
	non-confirmables if their rate does not exceed 1 B/s.		non-confirmables if their rate does not exceed 1 B/s.
	skipping to change at page 7, line 4 ¶		skipping to change at page 7, line 24 ¶
	confirmable.		confirmable.
	2. The confirmable messages must be sent under an RTO estimator, as		2. The confirmable messages must be sent under an RTO estimator, as
	specified in Section 3.		specified in Section 3.
	3. The packet rate of non-confirmable messages cannot exceed 1/RTO,		3. The packet rate of non-confirmable messages cannot exceed 1/RTO,
	where RTO is the overall RTO estimator value at the time the non-		where RTO is the overall RTO estimator value at the time the non-
	confirmable packet is sent.		confirmable packet is sent.
	4.1. Discussion		4.1. Discussion
	This is relatively conservative. More advanced versions of this		This is relatively conservative. More advanced versions of this
	algorithm could run a TFRC-style Loss Event Rate calculator [RFC5348]		algorithm could run a TFRC-style Loss Event Rate calculator [RFC5348]
	and apply the TCP equation to achieve a higher rate than 1/RTO.		and apply the TCP equation to achieve a higher rate than 1/RTO.
	5. IANA Considerations		5. IANA Considerations
	This document makes no requirements on IANA. (This section to be		This document makes no requirements on IANA. (This section to be
	removed by RFC editor.)		removed by RFC editor.)
	6. Security Considerations		6. Security Considerations
	(TBD. The security considerations of, e.g., [RFC5681], [RFC2914],		(TBD. The security considerations of, e.g., [RFC5681], [RFC2914],
	and [RFC5405] apply. Some issues are already discussed in the		and [RFC5405] apply. Some issues are already discussed in the
	security considerations of [I-D.ietf-core-coap].)		security considerations of [RFC7252].)
	7. Acknowledgements		7. Acknowledgements
	The first document to examine CoAP congestion control issues in		The first document to examine CoAP congestion control issues in
	detail was [I-D.eggert-core-congestion-control], to which this draft		detail was [I-D.eggert-core-congestion-control], to which this draft
	owes a lot.		owes a lot.
	Michael Scharf did a review of CoAP congestion control issues that		Michael Scharf did a review of CoAP congestion control issues that
	asked a lot of good questions. Several Transport Area		asked a lot of good questions. Several Transport Area
	representatives made further significant inputs this discussion		representatives made further significant inputs this discussion
	during IETF84, including Lars Eggert, Michael Scharf, and David		during IETF84, including Lars Eggert, Michael Scharf, and David
	Black. Andrew McGregor, Eric Rescorla, Richard Kelsey, Ed Beroset,		Black. Andrew McGregor, Eric Rescorla, Richard Kelsey, Ed Beroset,
	Jari Arkko, Zach Shelby, Matthias Kovatsch and many others provided		Jari Arkko, Zach Shelby, Matthias Kovatsch and many others provided
	very useful additions. Carles Gomez, August Betzler and Ilker		very useful additions.
	Demirkol provided a first detailed review of the present document;
	August provided simulation results that shaped some of the		Authors from Universitat Politecnica de Catalunya have been supported
	recommendations here but also indicate a need for further effort.		in part by the Spanish Government's Ministerio de Economia y
			Competitividad through projects TEC2009-11453 and TEC2012-32531, and
			FEDER.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC		[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
	2914, September 2000.		2914, September 2000.
	[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines		[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
	for Application Designers", BCP 145, RFC 5405, November		for Application Designers", BCP 145, RFC 5405, November
	2008.		2008.
	[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,		[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
	"Computing TCP's Retransmission Timer", RFC 6298, June		"Computing TCP's Retransmission Timer", RFC 6298, June
	2011.		2011.
			[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
			Application Protocol (CoAP)", RFC 7252, June 2014.
	8.2. Informative References		8.2. Informative References
	[I-D.bormann-core-congestion-control]		[I-D.bormann-core-congestion-control]
	Bormann, C. and K. Hartke, "Congestion Control Principles		Bormann, C. and K. Hartke, "Congestion Control Principles
	for CoAP", draft-bormann-core-congestion-control-02 (work		for CoAP", draft-bormann-core-congestion-control-02 (work
	in progress), July 2012.		in progress), July 2012.
	[I-D.eggert-core-congestion-control]		[I-D.eggert-core-congestion-control]
	Eggert, L., "Congestion Control for the Constrained		Eggert, L., "Congestion Control for the Constrained
	Application Protocol (CoAP)", draft-eggert-core-		Application Protocol (CoAP)", draft-eggert-core-
	congestion-control-01 (work in progress), January 2011.		congestion-control-01 (work in progress), January 2011.
	[I-D.ietf-core-coap]
	Shelby, Z., Hartke, K., and C. Bormann, "Constrained
	Application Protocol (CoAP)", draft-ietf-core-coap-18
	(work in progress), June 2013.
	[I-D.ietf-core-observe]		[I-D.ietf-core-observe]
	Hartke, K., "Observing Resources in CoAP", draft-ietf-		Hartke, K., "Observing Resources in CoAP", draft-ietf-
	core-observe-11 (work in progress), October 2013.		core-observe-14 (work in progress), June 2014.
	[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP		[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
	Friendly Rate Control (TFRC): Protocol Specification", RFC		Friendly Rate Control (TFRC): Protocol Specification", RFC
	5348, September 2008.		5348, September 2008.
	[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion		[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
	Control", RFC 5681, September 2009.		Control", RFC 5681, September 2009.
	Author's Address		Authors' Addresses
	Carsten Bormann		Carsten Bormann
	Universitaet Bremen TZI		Universitaet Bremen TZI
	Postfach 330440		Postfach 330440
	Bremen D-28359		Bremen D-28359
	Germany		Germany
	Phone: +49-421-218-63921		Phone: +49-421-218-63921
	Email: cabo@tzi.org		Email: cabo@tzi.org
			August Betzler
			Universitat Politecnica de Catalunya/Fundacio i2CAT
			Departament d'Enginyeria Telematica
			C/Jordi Girona, 1-3
			Barcelona 08034
			Spain
			Email: august.betzler@entel.upc.edu
			Carles Gomez
			Universitat Politecnica de Catalunya/Fundacio i2CAT
			Escola d'Enginyeria de Telecomunicacio i Aeroespacial
			de Castelldefels
			C/Esteve Terradas, 7
			Castelldefels 08860
			Spain
			Phone: +34-93-413-7206
			Email: carlesgo@entel.upc.edu
			Ilker Demirkol
			Universitat Politecnica de Catalunya/Fundacio i2CAT
			Departament d'Enginyeria Telematica
			C/Jordi Girona, 1-3
			Barcelona 08034
			Spain
			Email: ilker.demirkol@entel.upc.edu
End of changes. 35 change blocks.
	77 lines changed or deleted		91 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/