idnits 2.17.1 draft-li-core-coap-patience-option-03.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 (December 04, 2013) is 3796 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-11 == Outdated reference: A later version (-27) exists of draft-bormann-coap-misc-25 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 core K. Li 3 Internet-Draft B. Greevenbosch 4 Intended status: Standards Track Huawei Technologies 5 Expires: June 7, 2014 E. Dijk 6 Philips Research 7 S. Loreto 8 Ericsson 9 December 04, 2013 11 CoAP Option Extension: Patience 12 draft-li-core-coap-patience-option-03 14 Abstract 16 CoAP is a RESTful application protocol for constrained nodes and 17 networks. This specification provides a simple extension for CoAP, 18 the Patience option. This option informs a recipient of the 19 preferred time frame for a request or response depending on usage 20 context. In a unicast request, it indicates the patience a client 21 has in waiting for a response. The CoAP server tries to return the 22 response within the specified time frame. In a multicast request, it 23 indicates the patience a server should have in sending its response. 24 The recipient would then try to randomly delay its response within 25 the time frame that the requester indicated or computed by the 26 recipient itself. In a CoAP observe notification, it indicates the 27 patience an observer should have in both waiting for a subsequent 28 notification and in re-establishing an observation relation. 30 Note 32 Discussion and suggestions for improvement are requested, and should 33 be sent to core@ietf.org. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on June 7, 2014. 51 Copyright Notice 53 Copyright (c) 2013 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 1.1. Justification . . . . . . . . . . . . . . . . . . . . . . 3 70 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Patience Option Extension . . . . . . . . . . . . . . . . . . 4 72 2.1. Patience Option Definition . . . . . . . . . . . . . . . 4 73 2.2. Using the Patience Option . . . . . . . . . . . . . . . . 5 74 2.2.1. Unicast usage . . . . . . . . . . . . . . . . . . . . 5 75 2.2.2. Multicast usage . . . . . . . . . . . . . . . . . . . 6 76 2.2.3. Observe usage . . . . . . . . . . . . . . . . . . . . 6 77 2.3. Detection of IP unicast or multicast CoAP request . . . . 7 78 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 3.1. Unicast Usage Example . . . . . . . . . . . . . . . . . . 7 80 3.2. Observe Usage Example . . . . . . . . . . . . . . . . . . 8 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 83 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 86 7.2. Informative References . . . . . . . . . . . . . . . . . 9 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 89 1. Introduction 91 This specification adds a new option Patience to CoAP 92 [I-D.ietf-core-coap]. The main purpose is for the requester to 93 inform the recipient of the preferred time frame for a response. In 94 the unicast request case, it is used to indicate the patience it has 95 in waiting for a response. It then indicates "a response is most 96 useful within the specified time frame". In the multicast request 97 case, it indicates the patience that a server should have in sending 98 a response. In other words, it indicates "if possible please delay 99 your response by a randomly chosen time within the specified time 100 frame". A second purpose is for use by a server when sending CoAP 101 observe [I-D.ietf-core-observe] notifications, to indicate the 102 maximum time an observer should wait (i.e. patience of the observer) 103 before starting any observation relationship recovery. 105 1.1. Justification 107 In the unicast case, it is useful for the requester (client) to 108 indicate that the response is required to be returned within a 109 certain amount of time. For example, the requester could require a 110 response within 2 seconds, otherwise the response is not of interest 111 anymore. With this indication of the patience for a response, the 112 requester knows how long it should wait for the response, and it 113 needs to keep the state of the request only for the indicated time. 114 After this period, the request will be given up. It can avoid that 115 the recipient wastes resources by sending a response which already 116 exceeds the set patience timeout of the requester. 118 In the multicast case, if a server decides to respond to a multicast 119 request, it should not respond immediately. Instead, it should pick 120 a duration for the period of time during which it intends to respond. 121 The length of this period is called the Leisure, and defined in 122 [I-D.ietf-core-coap]. The same document specifies how to compute the 123 a rough lower bound for Leisure, as well as the DEFAULT_LEISURE. A 124 Patience option, if present, can be used as an upper bound for the 125 Leisure, i.e. the server SHOULD respond before the time frame 126 indicated by Patience has been exceeded. 128 In an observe scenario, it is useful for a server to indicate to an 129 observer that, after the period of time in the Max-Age option has 130 expired, a new notification will be sent within the time interval 131 indicated by the Patience option. The server may use this to send 132 notifications with a dithered delay i.e. randomly chosen within the 133 Patience-specified time interval, when there are many CoAP clients 134 simultaneously observing a resource on the server, avoiding network 135 congestion issues. Another use is for the server to delay sending a 136 new notification because e.g. the resource has not changed. The 137 observer in this case can assume that the server will do its best to 138 deliver a notification at least before the Patience time interval 139 runs out. 141 If the Patience option is combined with Observe option in a request, 142 currently it indicates the maximum time an observer is prepared to 143 wait for an initial notification. 145 1.2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 2. Patience Option Extension 153 2.1. Patience Option Definition 155 +-----+---+---+---+---+----------+-----------+--------+---------+ 156 | No. | C | U | N | R | Name | Format | Length | Default | 157 +-----+---+---+---+---+----------+-----------+--------+---------+ 158 | 28 | | | x | | Patience | see below | 1 B | (none) | 159 +-----+---+---+---+---+----------+-----------+--------+---------+ 161 The value carried in the Patience Option is in a specific format 162 resembling a pseudo-Floating Point value (as in 163 [I-D.bormann-coap-misc] Appendix B.2): 165 0 166 0 1 2 3 4 5 6 7 167 +-+-+-+-+-+-+-+-+ 168 | T | TX| 169 +-+-+-+-+-+-+-+-+ 171 T = Time 173 TX = Time Exponent 175 where the patience time is calculated as: 177 Patience time = 2^(TX * 4 + 3) * T 179 The value of the Patience option is calculated in milliseconds or 180 alternatively mibiseconds (1/1024s) if this would ease numerical 181 operations on above values on constrained platforms. The minimum 182 non-zero patience time is 8ms, when TX=0, T=1 and a milliseconds time 183 base is used. The maximum patience time is then 2064384ms, around 34 184 minutes, when TX=3 and T=63. 186 The Patience option is "elective". It MUST NOT occur more than once. 188 2.2. Using the Patience Option 190 The semantics of the Patience Option depends on its usage context, as 191 detailed in below sections. 193 2.2.1. Unicast usage 195 In the unicast case, this option is used by a CoAP client to indicate 196 the maximum time a requester is prepared to wait for a response. 198 The requester adds the Patience option to any request for which it is 199 prepared to wait for a response. The requester sets the option to 200 the maximum time that it is prepared to wait. 202 The Patience option applies to both piggy-backed response and 203 separate response. For a separate response, the patience applies to 204 the actual response after the ACK. ACK should be sent immediately 205 upon receipt of the CON message. 207 TBD: In case a requester retransmits a request, the Patience Option 208 value MAY be decreased by an amount of time equivalent to the time 209 since the previous transmission attempt. In case a requester did not 210 receive an ACK to a confirmable request and a time interval of at 211 least the interval indicated in the Patience Option of the request 212 has passed, the requester SHOULD give up the request. 214 The recipient interprets this option as the maximum time between 215 receipt of the complete request and the time that it begins sending 216 the response. The requester will observe a longer time interval 217 between request and response, as network transit and processing by 218 proxies add delays. If timing is critical, the requester SHOULD 219 consider the possible delays and choose the value for the option 220 accordingly. 222 The recipient MAY apply a lower value to the patience timeout based 223 on local policy. A recipient MAY choose to take longer to produce a 224 response, at the risk that the requester is no longer able to use the 225 response. 227 In case that the CoAP message is transmitted through a proxy, the 228 Proxy MAY reduce the value of a Patience option based on a local 229 policy (e.g. to consider the maximum time that an idle connection is 230 kept open by a local NAT or Firewall). A Proxy MAY add a Patience 231 option if none is present. The value in the Patience option MUST NOT 232 be increased or removed. 234 If the requester does not receive a response within the indicated 235 response time, the requester SHOULD consider the request as failed. 237 If the recipient can't provide a response within the required time, 238 the recipient SHOULD discard the request. 240 2.2.2. Multicast usage 242 In the multicast case, Leisure is defined in [I-D.ietf-core-coap] to 243 work as a duration for the period of time during which a server 244 intends to respond to a multicast request. The Patience option in a 245 CoAP request can be used as an upper bound for the Leisure. 247 How to use Leisure is defined in [I-D.ietf-core-coap]. 249 2.2.3. Observe usage 251 In a CoAP observe [I-D.ietf-core-observe] scenario, the Patience 252 Option MAY be used in a notification to indicate the maximum time an 253 observer should wait before starting any observation relationship 254 recovery. 256 The Max-Age Option indicates the maximum time a response 257 (notification) may be cached before it MUST be considered stale. The 258 Max-Age Option of a notification is usually set to a value that 259 estimates when the server will send the next notification. However, 260 in the case the value has not changed, the server can decide not to 261 send a new notification, possibly confusing the observer. It is 262 quite difficult for an observer to discriminate the situation that it 263 has not received a new notification because the value has not changed 264 from situations where the server has lost its state, or for some 265 reason has given up on notification delivery. 267 The Patience Option in a notification is used to indicate the maximum 268 time a server will try to reach the client before giving up. This is 269 to save the client some effort in re-establishing observation 270 relationships each time max-age is reached. This option is also 271 useful to give a server the time to send out the notifications, in 272 case there are many CoAP clients observing simultaneously a resource, 273 while avoiding network congestion issues. 275 The server adds the Patience option to any notification related to an 276 observation relationship from which it wants delay an observation 277 refresh request made by the observer. The server sets the option to 278 the maximum time that it is prepared to spend to reach the observer 279 before giving up. 281 The observer interprets this option as the minimum time between the 282 expiration of a notification (as indicated by its Max-Age Option 283 value) and the moment it MAY start an observation relationship 284 recovery action with the server. 286 If the observer does not receive a response within the indicated time 287 interval, the observer SHOULD attempt to re-establish the observation 288 relationship with the server if it is still interested in observing 289 the particular resource. 291 2.3. Detection of IP unicast or multicast CoAP request 293 A single Patience Option, used to indicate potentially either client 294 patience (in the IP unicast case) or server patience (in the IP 295 multicast case), requires that a CoAP server is able to distinguish 296 between IP unicast and multicast requests. If there exist commonly 297 used IP stacks that do not offer such functionality [to be checked], 298 requiring servers to be able to make the unicast/multicast 299 distinction seems unwise and limits the applicability of the Patience 300 Option. 302 Approaches for a CoAP server to detect unicast versus multicast 303 requests may include: 305 1) CoAP server application opens a specific socket and sets IP 306 multicast reception using the POSIX setsockopt function [to be 307 verified if IP unicast traffic also is received in this case, or 308 not]. 310 2) CoAP server checks the IP destination address of incoming packets. 311 If this has the FF00::/8 IPv6 prefix, then it's treated as multicast 312 otherwise unicast [to be verified if IP stack APIs allow to get IP 313 destination]. 315 3) Receiving CoAP multicast requests always occurs on a different 316 port than the standard CoAP port. For example, similar to coaps:// 317 that uses a different port than coap://, a scheme coapm:// on a 318 different port may be defined for multicast requests. 320 3. Example 322 3.1. Unicast Usage Example 324 This section gives a short example with a message flow that 325 illustrates the use of the Patience option in a GET request. 327 This example (Figure 1) shows that the requester wants to get a 328 response within 3200 milliseconds, when T=25, TX=1. 330 requester recipient 331 | | 332 | | 333 +----->| Header: GET (T=CON, Code=1, MID=0x7d38) 334 | GET | Token: 0x53 335 | | Patience: 25/1 336 | | Uri-Path: "temperature" 337 | | 338 |<-----+ Header: 2.05 Content (T=ACK, Code=69, MID=0x7d38) 339 | 2.05 | Token: 0x53 340 | | Payload: "22.3 C" 341 | | 343 Figure 1: Patience Option in a unicast request 345 3.2. Observe Usage Example 347 This section gives a short example with a message flow that 348 illustrates the use of the Patience option in an Observe 349 notification. 351 This example (Figure 2) shows that the server wants the observer to 352 wait 819 seconds (T=25, TX=3) before starting any observation 353 relationship recovery, even though the Max-Age of the temperature 354 value notification is only 120 seconds. 356 Observer Server 357 | | 358 | | 359 +----->| Header: GET (T=CON, Code=1, MID=0x7d38) 360 | GET | Token: 0x53 361 | | Observe: 0 362 | | Uri-Path: "temperature" 363 | | 364 |<-----+ Header: 2.05 Content (T=ACK, Code=69, MID=0x7d38) 365 | 2.05 | Token: 0x53 366 | | Max-Age: 120 367 | | Patience: 25/3 368 | | Payload: "22.3 C" 369 | | 371 Figure 2: Patience Option in an observe notification 373 4. Security Considerations 374 This presents no security considerations beyond those in section 10 375 of the base CoAP specification [I-D.ietf-core-coap]. 377 5. IANA Considerations 379 The IANA is requested to add the following "CoAP Option Numbers" 380 entry as per Section 11.2 of [I-D.ietf-core-coap]. 382 +-----+-----+---+---+---+----------+-------------+--------+---------+ 383 | No. | C | U | N | R | Name | Format | Length | Default | 384 +-----+-----+---+---+---+----------+-------------+--------+---------+ 385 | 28 | | | x | | Patience | (ref to | 1 B | (none) | 386 | | | | | | | this | | | 387 | | | | | | | document) | | | 388 +-----+-----+---+---+---+----------+-------------+--------+---------+ 390 6. Acknowledgements 392 The authors of this draft would like to thank the participants of the 393 email discussion on this issue. Thanks to Carsten Bormann, Peter 394 Bigot, Barry Leiba, Linyi Tian for the reviews and discussions. 396 7. References 398 7.1. Normative References 400 [I-D.ietf-core-coap] 401 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 402 Application Protocol (CoAP)", draft-ietf-core-coap-18 403 (work in progress), June 2013. 405 [I-D.ietf-core-observe] 406 Hartke, K., "Observing Resources in CoAP", draft-ietf- 407 core-observe-11 (work in progress), October 2013. 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, March 1997. 412 7.2. Informative References 414 [I-D.bormann-coap-misc] 415 Bormann, C. and K. Hartke, "Miscellaneous additions to 416 CoAP", draft-bormann-coap-misc-25 (work in progress), May 417 2013. 419 Authors' Addresses 420 Kepeng Li 421 Huawei Technologies 422 Huawei Base, Bantian, Longgang District 423 Shenzhen, Guangdong 518129 424 P. R. China 426 Email: likepeng@huawei.com 428 Bert Greevenbosch 429 Huawei Technologies 430 Huawei Base, Bantian, Longgang District 431 Shenzhen, Guangdong 518129 432 P. R. China 434 Email: bert.greevenbosch@huawei.com 436 Esko Dijk 437 Philips Research 438 High Tech Campus 34 439 Eindhoven 440 The Netherlands 442 Email: esko.dijk@philips.com 444 Salvatore Loreto 445 Ericsson 446 Hirsalantie 11 447 Jorvas 02420 448 Finland 450 Email: salvatore.loreto@ericsson.com