idnits 2.17.1 draft-greevenbosch-core-block-minimum-time-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2012) is 4280 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 226, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-core-block-08 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-10 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 core B. Greevenbosch 3 Internet-Draft Huawei Technologies 4 Intended status: Informational July 9, 2012 5 Expires: January 10, 2013 7 CoAP Minimum Block Time 8 draft-greevenbosch-core-block-minimum-time-00 10 Abstract 12 This document defines an "MinimumBlockTime" option for CoAP, which 13 can be used to negotiate the minimum time between two subsequent 14 block requests. It can be used for overload and congestion control. 16 Note 18 Discussion and suggestions for improvement are requested, and should 19 be sent to core@ietf.org. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 10, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 57 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4. The "MinimumBlockTime" option . . . . . . . . . . . . . . . . 7 59 5. Legacy behaviour . . . . . . . . . . . . . . . . . . . . . . . 8 60 6. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 64 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 65 11. Normative References . . . . . . . . . . . . . . . . . . . . . 14 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 1. Introduction 70 The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a 71 RESTful protocol for constrained nodes and networks. In 72 [I-D.ietf-core-block], the block mechanism for block-wise 73 transmission of data is defined. 75 This document defines a "MinimumBlockTime" option, which can be used 76 to negotiate the minimum time between two subsequent block requests. 78 Negotiating the minimum time between the block requests can be used 79 to limit the associated traffic, providing a mechanism for congestion 80 control. In addition, it allows very constrained servers to limit 81 the number of requests they receive within a certain time period, 82 preventing them from becoming overloaded. 84 2. Requirements notation 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 3. Definitions 92 Block transaction 93 The block-wise transmission of a single resource, between a unique 94 client and server pair. 96 Two subsequent requests 97 In this document, the phrase "two subsequent requests" indicates 98 two requests in a same block transaction, in which one follows the 99 other, without other requests from the same block transaction in 100 between. Notice that the difference between the block numbers of 101 the two subsequent requests does not have to be one, although most 102 often this will be the case. 104 Block time 105 The time between two subsequent requests in a block transaction. 107 Block speed 108 The multiplicative inverse of the block time. 110 4. The "MinimumBlockTime" option 112 +------+-----+------------------+--------+--------+---------+ 113 | Type | C/E | Name | Format | Length | Default | 114 +------+-----+------------------+--------+--------+---------+ 115 | TBD | E | MinimumBlockTime | uint | 0-2B | 0 | 116 +------+-----+------------------+--------+--------+---------+ 118 Table 1: The "MinimumBlockTime" option 120 The "MinimumBlockTime" option is an elective option, which is used to 121 negotiate the minimum time in milliseconds that a client needs to 122 wait between sending two subsequent block requests. 124 In the remainder of this section, it is assumed that both the client 125 and the server support the "MinimumBlockTime" option. 127 If the client includes a "Block1" or "Block2" option in its first 128 request in a block transaction, it SHOULD include the 129 "MinimumBlockTime" option in that first request too. The server 130 SHOULD include the "MinimumBlockTime" option in its first block 131 response. 133 In a block request, the option's value T_C indicates the minimum 134 block time in ms that the client can support. 136 In a block response, the option's value T_S indicates the minimum 137 block time in ms that the server can support. 139 The client SHALL wait at least T_S ms between sending two subsequent 140 block requests. 142 The following MUST hold: T_S <= T_C. 144 The "MinimumBlockTime" option has a default value 0. A value T_S=0 145 indicates the server does not put any restrictions on the block 146 speed. A value T_C=0 indicates that the client prefers to send the 147 requests as quickly as possible. 149 5. Legacy behaviour 151 It is possible that either the client or server does not support the 152 "MinimumBlockTime" option. If the client does not support the 153 option, then obviously it cannot take the server's preference into 154 account. Similarly if the server does not support the option, it 155 cannot use it to restrict the block speed. 157 In either case, or their combination, the client will choose the 158 block speed as it prefers. This corresponds to the case T_S=0. 160 To allow the server to distinguish between a client that supports the 161 "MinimumBlockTime" option but wants to signal T_C=0, and a client 162 that does not support the "MinimumBlockTime" option, it is 163 RECOMMENDED for the compliant client to include option in the first 164 request in a Block transaction, even when the client wants to signal 165 T_C=0. 167 6. Open issues 169 For longer block transactions, there may be value in allowing updates 170 of the block speed during a block transaction. We should consider 171 whether increasing efficiency will justify the extra complexity. 173 7. Example 175 Figure 1 contains an example of a block transaction with the 176 "MinimumBlockTime" option. The client indicates its supported 177 minimum block time as 200ms. The associated block speed is too high 178 for the server, so the server indicates a minimum block time of 179 300ms. The client obeys this value for the rest of the transaction. 181 CLIENT SERVER 182 | | 183 / | CON [MID=1234], GET, /status, N=0, T_C = 200 ----> | 184 | | | 185 300ms | <---- ACK [MID=1234], 2.05 Content, N=0, T_S = 300 | 186 | | | 187 \ / | CON [MID=1235], GET, /status, N=1 ----> | 188 | | | 189 300ms| <---- ACK [MID=1235], 2.05 Content, N=1 | 190 | | | 191 / \ | CON [MID=1234], GET, /status, N=2 ----> | 192 | | | 193 300ms | <---- ACK [MID=1234], 2.05 Content, N=2 | 194 | | | 195 \ | CON [MID=1235], GET, /status, N=3 ----> | 196 : : 197 : ... : 198 : : 200 Figure 1: Example of transaction with "MinimumBlockTime" 202 8. Security Considerations 204 By modifying the value of the "MinimumBlockTime" option to a higher 205 value, a man-in-the-middle could increase the time used to perform a 206 block transaction. When the client encounters a response with a too 207 high "MinimumBlockTime" value, it MAY abort the transaction, and try 208 to reinitiate it. However, to prevent overloading the server, the 209 client MUST limit the number of these reinitiations. 211 By decreasing the value of the "MinimumBlockTime" option, the man-in- 212 the-middle can induce the client to send block requests at a speed 213 too high for the server. The server should be prepared for this, for 214 example by discarding requests that cannot be processed. This is 215 similar to the case where the server or client does not support the 216 "MinimumBlockTime" option. 218 9. IANA Considerations 220 This draft adds the following option numbers to the CoAP Option 221 Numbers registry of [I-D.ietf-core-coap]. 223 +----------------+------------------+-----------+ 224 | Number | Name | Reference | 225 +----------------+------------------+-----------+ 226 | TBD (elective) | MinimumBlockTime | [RFCXXXX] | 227 +----------------+------------------+-----------+ 229 Table 2: CoAP option numbers 231 10. Acknowledgements 233 The author would like to thank Kepeng Li for his ideas and feedback. 235 11. Normative References 237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 238 Requirement Levels", BCP 14, RFC 2119, March 1997. 240 [I-D.ietf-core-block] 241 Shelby, Z. and C. Bormann, "Constrained Application 242 Protocol (CoAP)", draft-ietf-core-block-08 (work in 243 progress), February 2012. 245 [I-D.ietf-core-coap] 246 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 247 "Constrained Application Protocol (CoAP)", 248 draft-ietf-core-coap-10 (work in progress), March 2012. 250 Author's Address 252 Bert Greevenbosch 253 Huawei Technologies Co., Ltd. 254 Huawei Industrial Base 255 Bantian, Longgang District 256 Shenzhen 518129 257 P.R. China 259 Phone: +86-755-28978088 260 Email: bert.greevenbosch@huawei.com