core B. Greevenbosch
Internet-Draft Huawei Technologies
Intended status: Standards Track September 25, 2012
Expires: March 29, 2013
CoAP Minimum Request Interval
draft-greevenbosch-core-minimum-request-interval-00
Abstract
This document defines an "MinimumRequestInterval" option for CoAP,
which can be used to negotiate the minimum time between two
subsequent requests within a single client and server pair. It can
be used for flow and congestion control, reducing the consumption of
server and network resources when needed.
Greevenbosch Expires March 29, 2013 [Page 1]
Internet-Draft CoAP Minimum Request Interval September 2012
Note
Discussion and suggestions for improvement are requested, and should
be sent to core@ietf.org.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 29, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Greevenbosch Expires March 29, 2013 [Page 2]
Internet-Draft CoAP Minimum Request Interval September 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. The "MinimumRequestInterval" option . . . . . . . . . . . . . 8
6. Legacy behaviour . . . . . . . . . . . . . . . . . . . . . . . 9
7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
11. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Greevenbosch Expires March 29, 2013 [Page 3]
Internet-Draft CoAP Minimum Request Interval September 2012
1. Introduction
The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a
RESTful protocol for constrained nodes and networks.
This document defines a "MinimumRequestInterval" option, which can be
used to negotiate the minimum time between two subsequent requests
within a single client and server pair.
Negotiating the minimum time between the requests can be used to
limit the associated traffic, thereby reducing network congestion.
In addition, it allows constrained servers to limit the number of
requests they receive within a certain time period, preventing them
from becoming overloaded.
The mechanism is especially useful for a block transaction, as
defined in [I-D.ietf-core-block]. However it can also be used for
other transactions involving multiple requests from the client, for
example when the client browses the server's resources.
Greevenbosch Expires March 29, 2013 [Page 4]
Internet-Draft CoAP Minimum Request Interval September 2012
2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Greevenbosch Expires March 29, 2013 [Page 5]
Internet-Draft CoAP Minimum Request Interval September 2012
3. Definitions
transaction
A series of request/response pairs within a unique client and
server pair.
block transaction
A transaction which consists of the transfer of a single source
using the block mechanism.
two subsequent requests
Two requests within a single transaction, in which one request
follows the other request, without a third request from the
transaction in between.
request interval
The time between two subsequent requests.
request speed
The multiplicative inverse of the request interval.
ms
Milliseconds or mibiseconds, depending on the implementation.
mibisecond
1/1024 of a second.
Greevenbosch Expires March 29, 2013 [Page 6]
Internet-Draft CoAP Minimum Request Interval September 2012
4. Motivation
It would be beneficial for the server to control the amount of
requests it receives from the client within a certain time period.
In this way, the server can achieve better usage of its internal
resources, such as memory, processor load and message buffers.
Limiting the number of incoming requests increases the reliability in
responding to them, and decreases the chance on server overload.
One method to reduce the client's request speed is for the server to
delay sending its ACKs. This indeed can slow down the client,
especially in case the client only issues a new request after receipt
of the ACK of the previous request. However, it has the disadvantage
that the server has to keep the transaction open, and needs to use
resources for delaying the ACK that could have been used to perform
other tasks.
If, however, the server can explicitly signal the client's request
speed, then the server does not need to keep track of its own minimum
time to respond to each request, and can handle requests as soon as
possible. This allows the server to use its resources for other
tasks sooner. Since all clients will have a better probability that
their requests are handled and that they will receive responses, the
overall system's reliability is increased.
Greevenbosch Expires March 29, 2013 [Page 7]
Internet-Draft CoAP Minimum Request Interval September 2012
5. The "MinimumRequestInterval" option
+------+-----+------------------------+--------+--------+---------+
| Type | C/E | Name | Format | Length | Default |
+------+-----+------------------------+--------+--------+---------+
| TBD | E | MinimumRequestInterval | uint | 0-2B | 0 |
+------+-----+------------------------+--------+--------+---------+
Table 1: The "MinimumRequestInterval" option
The "MinimumRequestInterval" option is an elective option, which is
used to negotiate the minimum time in ms that a client needs to wait
between sending two subsequent requests.
In the remainder of this section, it is assumed that both the client
and the server support the "MinimumRequestInterval" option.
If the client plans to perform a transaction consisting of multiple
requests, it SHOULD include the "MinimumRequestInterval" option in
the first request of the transaction.
The server MUST include the "MinimumRequestInterval" option in a
response to a request that contained a "MinimumRequestInterval"
option.
If a client receives a response with the "MinimumRequestInterval"
option, it MUST include the "MinimumRequestInterval" in its
subsequent request.
In the request, the option's value T_C is the request interval the
client is currently using. An exception is the first request in the
transaction, in which case the value T_C is a proposed request
interval.
In a response, the option's value T_S indicates the minimum request
interval in ms that the server can support at that particular moment.
Depending on its workload, the server MAY increase or decrease the
latest value of T_C to form T_S.
The client SHALL wait at least T_S ms between sending two subsequent
requests. It MAY also send at a slower speed.
The "MinimumRequestInterval" option has a default value 0. A value
T_S=0 indicates the server does not put any restrictions on the
transaction speed. Similiarly value T_C=0 in the first request
indicates that the client prefers to send the following requests as
quickly as possible.
Greevenbosch Expires March 29, 2013 [Page 8]
Internet-Draft CoAP Minimum Request Interval September 2012
6. Legacy behaviour
It is possible that either the client or server does not support the
"MinimumRequestInterval" option. If the client does not support the
option, then obviously it cannot take the server's preference into
account. Similarly if the server does not support the option, it
cannot use it to restrict the transaction speed.
In either case, or their combination, the client will choose the
transaction speed as it prefers. This corresponds to the case T_S=0.
To allow the server to distinguish between a client that supports the
"MinimumRequestInterval" option but wants to signal T_C=0, and a
client that does not support the "MinimumRequestInterval" option, it
is RECOMMENDED for the compliant client to include the option in the
requests of a multiple request transaction, even when the client
wants to signal T_C=0.
Greevenbosch Expires March 29, 2013 [Page 9]
Internet-Draft CoAP Minimum Request Interval September 2012
7. Example
Figure 1 contains an example of a block transaction with the
"MinimumRequestInterval" option.
In the first request, the client proposes a minimum request interval
of T_C=150ms. As the server is too busy, it wants to slow down the
client and returns a minimum request interval of T_S=200ms.
The client uses this request interval for the timing of the next
requests, and keeps informing the server of its current request
speed. Likewise, in the first several messages the server echos the
T_C in T_S, signalling that it is comfortable with the current
request speed.
After sending three blocks, the server becomes less busy. It
therefore increases the allowed request speed by signalling a new
T_S=150ms. The client uses this speed until the end of the
transaction.
CLIENT SERVER
| |
/ | CON [MID=1234], GET, /status, N=0, T_C=150 -------> |
| | |
200ms | <------- ACK [MID=1234], 2.05 Content, N=0, T_S=200 |
| | |
\ / | CON [MID=1235], GET, /status, N=1, T_C=200 -------> |
| | |
200ms| <------- ACK [MID=1235], 2.05 Content, N=1, T_S=200 |
| | |
/ \ | CON [MID=1234], GET, /status, N=2, T_C=200 -------> |
| | |
200ms | <------- ACK [MID=1234], 2.05 Content, N=2, T_S=200 |
| | |
\ / | CON [MID=1235], GET, /status, N=3, T_C=200 -------> |
| | |
150ms| <------- ACK [MID=1235], 2.05 Content, N=3, T_S=150 |
| | |
/ \ | CON [MID=1234], GET, /status, N=4, T_C=150 -------> |
| | |
150ms | <------- ACK [MID=1234], 2.05 Content, N=4, T_S=150 |
| | |
\ | CON [MID=1235], GET, /status, N=5, T_C=150 -------> |
: :
: ... :
: :
Greevenbosch Expires March 29, 2013 [Page 10]
Internet-Draft CoAP Minimum Request Interval September 2012
Figure 1: Example of transaction with "MinimumRequestInterval"
Greevenbosch Expires March 29, 2013 [Page 11]
Internet-Draft CoAP Minimum Request Interval September 2012
8. Security Considerations
By modifying the value of the "MinimumRequestInterval" option in a
response to a higher value, a man-in-the-middle could increase the
time used to perform a transaction. When the client encounters a
response with a too high "MinimumRequestInterval" value, it MAY abort
the transaction, and try to reinitiate it. However, to prevent
overloading the server, the client MUST limit the number of these
reinitiations.
By decreasing the value of the "MinimumRequestInterval" option in a
response, the man-in-the-middle can induce the client to send
requests at a speed too high for the server. The server should be
prepared for this, for example by discarding requests that cannot be
processed. This is similar to the case where the server or client
does not support the "MinimumRequestInterval" option.
By altering the value of the "MinimumRequestInterval" option in a
request, the man-in-the-middle can induce the server to believe that
the client is using another transaction speed than it really is.
This could lead to a false adjustment of the request interval.
All these attacks depend on the man-in-the-middle being able to
modify multiple messages, as the speed would otherwise stabilise
again after several adjustments by the server.
Greevenbosch Expires March 29, 2013 [Page 12]
Internet-Draft CoAP Minimum Request Interval September 2012
9. IANA Considerations
This draft adds the following option numbers to the CoAP Option
Numbers registry of [I-D.ietf-core-coap].
+----------------+------------------------+-----------+
| Number | Name | Reference |
+----------------+------------------------+-----------+
| TBD (elective) | MinimumRequestInterval | [RFCXXXX] |
+----------------+------------------------+-----------+
Table 2: CoAP option numbers
Greevenbosch Expires March 29, 2013 [Page 13]
Internet-Draft CoAP Minimum Request Interval September 2012
10. Acknowledgements
The author would like to thank Carsten Borrman, Esko Dijk and Kepeng
Li for their feedback.
Greevenbosch Expires March 29, 2013 [Page 14]
Internet-Draft CoAP Minimum Request Interval September 2012
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-core-block]
Shelby, Z. and C. Bormann, "Constrained Application
Protocol (CoAP)", draft-ietf-core-block-08 (work in
progress), February 2012.
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-10 (work in progress), March 2012.
Greevenbosch Expires March 29, 2013 [Page 15]
Internet-Draft CoAP Minimum Request Interval September 2012
Author's Address
Bert Greevenbosch
Huawei Technologies Co., Ltd.
Huawei Industrial Base
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone: +86-755-28978088
Email: bert.greevenbosch@huawei.com
Greevenbosch Expires March 29, 2013 [Page 16]