Internet DRAFT - draft-greevenbosch-core-minimum-request-interval
draft-greevenbosch-core-minimum-request-interval
core B. Greevenbosch
Internet-Draft Huawei Technologies
Intended status: Standards Track April 26, 2013
Expires: October 28, 2013
CoAP Minimum Request Interval
draft-greevenbosch-core-minimum-request-interval-01
Abstract
This document defines an "Minimum-Request-Interval" 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.
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 October 28, 2013.
Copyright Notice
Copyright (c) 2013 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
Greevenbosch Expires October 28, 2013 [Page 1]
Internet-Draft CoAP Minimum Request Interval April 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. The "Minimum-Request-Interval" option . . . . . . . . . . . . 4
6. Legacy behaviour . . . . . . . . . . . . . . . . . . . . . . 5
7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
11. Normative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
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 "Minimum-Request-Interval" 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.
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 October 28, 2013 [Page 2]
Internet-Draft CoAP Minimum Request Interval April 2013
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.
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
Greevenbosch Expires October 28, 2013 [Page 3]
Internet-Draft CoAP Minimum Request Interval April 2013
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.
5. The "Minimum-Request-Interval" option
+-----+---+---+---+---+--------------------+---------+------+-------+
| No. | C | U | N | R | Name | Format | Leng | Defau |
| | | | | | | | th | lt |
+-----+---+---+---+---+--------------------+---------+------+-------+
| 60 | | | x | | Minimum-Request- | (ref to | 0-2 | 0 |
| | | | | | Interval | this do | B | |
| | | | | | | cument) | | |
+-----+---+---+---+---+--------------------+---------+------+-------+
Table 1: The "Minimum-Request-Interval" option
The "Minimum-Request-Interval" 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 "Minimum-Request-Interval" option.
If the client plans to perform a transaction consisting of multiple
requests, it SHOULD include the "Minimum-Request-Interval" option in
the first request of the transaction.
The server MUST include the "Minimum-Request-Interval" option in a
response to a request that contained a "Minimum-Request-Interval"
option.
If a client receives a response with the "Minimum-Request-Interval"
option, it MUST include the "Minimum-Request-Interval" 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.
Greevenbosch Expires October 28, 2013 [Page 4]
Internet-Draft CoAP Minimum Request Interval April 2013
The "Minimum-Request-Interval" 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.
6. Legacy behaviour
It is possible that either the client or server does not support the
"Minimum-Request-Interval" 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
"Minimum-Request-Interval" option but wants to signal T_C=0, and a
client that does not support the "Minimum-Request-Interval" 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.
7. Example
Figure 1 contains an example of a block transaction with the
"Minimum-Request-Interval" 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 -------> |
| | |
Greevenbosch Expires October 28, 2013 [Page 5]
Internet-Draft CoAP Minimum Request Interval April 2013
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 -------> |
: :
: ... :
: :
Figure 1: Example of transaction with "Minimum-Request-Interval"
8. Security Considerations
By modifying the value of the "Minimum-Request-Interval" 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 "Minimum-Request-Interval" 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 "Minimum-Request-Interval" 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 "Minimum-Request-Interval" option.
By altering the value of the "Minimum-Request-Interval" 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.
Greevenbosch Expires October 28, 2013 [Page 6]
Internet-Draft CoAP Minimum Request Interval April 2013
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.
9. IANA Considerations
This draft adds the following option numbers to the CoAP Option
Numbers registry of [I-D.ietf-core-coap].
+-----+---+---+---+---+--------------------+---------+------+-------+
| No. | C | U | N | R | Name | Format | Leng | Defau |
| | | | | | | | th | lt |
+-----+---+---+---+---+--------------------+---------+------+-------+
| 60 | | | x | | Minimum-Request- | (ref to | 0-2 | 0 |
| | | | | | Interval | this do | B | |
| | | | | | | cument) | | |
+-----+---+---+---+---+--------------------+---------+------+-------+
10. Acknowledgements
The author would like to thank Carsten Borrman, Esko Dijk and Kepeng
Li for their feedback.
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-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-15
(work in progress), April 2013.
[I-D.ietf-core-block]
Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP",
draft-ietf-core-block-11 (work in progress), March 2013.
Author's Address
Greevenbosch Expires October 28, 2013 [Page 7]
Internet-Draft CoAP Minimum Request Interval April 2013
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 October 28, 2013 [Page 8]
