core B. Greevenbosch
Internet-Draft Huawei Technologies
Intended status: Informational July 9, 2012
Expires: January 10, 2013
CoAP Minimum Block Time
draft-greevenbosch-core-block-minimum-time-00
Abstract
This document defines an "MinimumBlockTime" option for CoAP, which
can be used to negotiate the minimum time between two subsequent
block requests. It can be used for overload and congestion control.
Greevenbosch Expires January 10, 2013 [Page 1]
Internet-Draft CoAP Minimum Block Time July 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 January 10, 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 January 10, 2013 [Page 2]
Internet-Draft CoAP Minimum Block Time July 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. The "MinimumBlockTime" option . . . . . . . . . . . . . . . . 7
5. Legacy behaviour . . . . . . . . . . . . . . . . . . . . . . . 8
6. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
11. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Greevenbosch Expires January 10, 2013 [Page 3]
Internet-Draft CoAP Minimum Block Time July 2012
1. Introduction
The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a
RESTful protocol for constrained nodes and networks. In
[I-D.ietf-core-block], the block mechanism for block-wise
transmission of data is defined.
This document defines a "MinimumBlockTime" option, which can be used
to negotiate the minimum time between two subsequent block requests.
Negotiating the minimum time between the block requests can be used
to limit the associated traffic, providing a mechanism for congestion
control. In addition, it allows very constrained servers to limit
the number of requests they receive within a certain time period,
preventing them from becoming overloaded.
Greevenbosch Expires January 10, 2013 [Page 4]
Internet-Draft CoAP Minimum Block Time July 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 January 10, 2013 [Page 5]
Internet-Draft CoAP Minimum Block Time July 2012
3. Definitions
Block transaction
The block-wise transmission of a single resource, between a unique
client and server pair.
Two subsequent requests
In this document, the phrase "two subsequent requests" indicates
two requests in a same block transaction, in which one follows the
other, without other requests from the same block transaction in
between. Notice that the difference between the block numbers of
the two subsequent requests does not have to be one, although most
often this will be the case.
Block time
The time between two subsequent requests in a block transaction.
Block speed
The multiplicative inverse of the block time.
Greevenbosch Expires January 10, 2013 [Page 6]
Internet-Draft CoAP Minimum Block Time July 2012
4. The "MinimumBlockTime" option
+------+-----+------------------+--------+--------+---------+
| Type | C/E | Name | Format | Length | Default |
+------+-----+------------------+--------+--------+---------+
| TBD | E | MinimumBlockTime | uint | 0-2B | 0 |
+------+-----+------------------+--------+--------+---------+
Table 1: The "MinimumBlockTime" option
The "MinimumBlockTime" option is an elective option, which is used to
negotiate the minimum time in milliseconds that a client needs to
wait between sending two subsequent block requests.
In the remainder of this section, it is assumed that both the client
and the server support the "MinimumBlockTime" option.
If the client includes a "Block1" or "Block2" option in its first
request in a block transaction, it SHOULD include the
"MinimumBlockTime" option in that first request too. The server
SHOULD include the "MinimumBlockTime" option in its first block
response.
In a block request, the option's value T_C indicates the minimum
block time in ms that the client can support.
In a block response, the option's value T_S indicates the minimum
block time in ms that the server can support.
The client SHALL wait at least T_S ms between sending two subsequent
block requests.
The following MUST hold: T_S <= T_C.
The "MinimumBlockTime" option has a default value 0. A value T_S=0
indicates the server does not put any restrictions on the block
speed. A value T_C=0 indicates that the client prefers to send the
requests as quickly as possible.
Greevenbosch Expires January 10, 2013 [Page 7]
Internet-Draft CoAP Minimum Block Time July 2012
5. Legacy behaviour
It is possible that either the client or server does not support the
"MinimumBlockTime" 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 block speed.
In either case, or their combination, the client will choose the
block speed as it prefers. This corresponds to the case T_S=0.
To allow the server to distinguish between a client that supports the
"MinimumBlockTime" option but wants to signal T_C=0, and a client
that does not support the "MinimumBlockTime" option, it is
RECOMMENDED for the compliant client to include option in the first
request in a Block transaction, even when the client wants to signal
T_C=0.
Greevenbosch Expires January 10, 2013 [Page 8]
Internet-Draft CoAP Minimum Block Time July 2012
6. Open issues
For longer block transactions, there may be value in allowing updates
of the block speed during a block transaction. We should consider
whether increasing efficiency will justify the extra complexity.
Greevenbosch Expires January 10, 2013 [Page 9]
Internet-Draft CoAP Minimum Block Time July 2012
7. Example
Figure 1 contains an example of a block transaction with the
"MinimumBlockTime" option. The client indicates its supported
minimum block time as 200ms. The associated block speed is too high
for the server, so the server indicates a minimum block time of
300ms. The client obeys this value for the rest of the transaction.
CLIENT SERVER
| |
/ | CON [MID=1234], GET, /status, N=0, T_C = 200 ----> |
| | |
300ms | <---- ACK [MID=1234], 2.05 Content, N=0, T_S = 300 |
| | |
\ / | CON [MID=1235], GET, /status, N=1 ----> |
| | |
300ms| <---- ACK [MID=1235], 2.05 Content, N=1 |
| | |
/ \ | CON [MID=1234], GET, /status, N=2 ----> |
| | |
300ms | <---- ACK [MID=1234], 2.05 Content, N=2 |
| | |
\ | CON [MID=1235], GET, /status, N=3 ----> |
: :
: ... :
: :
Figure 1: Example of transaction with "MinimumBlockTime"
Greevenbosch Expires January 10, 2013 [Page 10]
Internet-Draft CoAP Minimum Block Time July 2012
8. Security Considerations
By modifying the value of the "MinimumBlockTime" option to a higher
value, a man-in-the-middle could increase the time used to perform a
block transaction. When the client encounters a response with a too
high "MinimumBlockTime" 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 "MinimumBlockTime" option, the man-in-
the-middle can induce the client to send block 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
"MinimumBlockTime" option.
Greevenbosch Expires January 10, 2013 [Page 11]
Internet-Draft CoAP Minimum Block Time July 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) | MinimumBlockTime | [RFCXXXX] |
+----------------+------------------+-----------+
Table 2: CoAP option numbers
Greevenbosch Expires January 10, 2013 [Page 12]
Internet-Draft CoAP Minimum Block Time July 2012
10. Acknowledgements
The author would like to thank Kepeng Li for his ideas and feedback.
Greevenbosch Expires January 10, 2013 [Page 13]
Internet-Draft CoAP Minimum Block Time July 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 January 10, 2013 [Page 14]
Internet-Draft CoAP Minimum Block Time July 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 January 10, 2013 [Page 15]