idnits 2.17.1 draft-li-core-coap-patience-option-04.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 04, 2014) is 3574 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-13 == Outdated reference: A later version (-27) exists of draft-bormann-coap-misc-26 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: January 5, 2015 E. Dijk 6 Philips Research 7 S. Loreto 8 Ericsson 9 July 04, 2014 11 CoAP Option Extension: Patience 12 draft-li-core-coap-patience-option-04 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 January 5, 2015. 51 Copyright Notice 53 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . 10 89 1. Introduction 91 This specification adds a new option Patience to CoAP [RFC7252]. The 92 main purpose is for the requester to inform the recipient of the 93 preferred time frame for a response. In the unicast request case, it 94 is used to indicate the patience it has in waiting for a response. 95 It then indicates "a response is most useful within the specified 96 time frame". In the multicast request case, it indicates the 97 patience that a server should have in sending a response. In other 98 words, it indicates "if possible please delay your response by a 99 randomly chosen time within the specified time frame". A second 100 purpose is for use by a server when sending CoAP observe 101 [I-D.ietf-core-observe] notifications, to indicate the maximum time 102 an observer should wait (i.e. patience of the observer) before 103 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 [RFC7252]. The same document specifies how to compute the a rough 123 lower bound for Leisure, as well as the DEFAULT_LEISURE. A Patience 124 option, if present, can be used as an upper bound for the Leisure, 125 i.e. the server SHOULD respond before the time frame indicated by 126 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. 236 If the recipient can't provide a response within the required time, 237 the recipient SHOULD discard the request. 239 2.2.2. Multicast usage 241 In the multicast case, Leisure is defined in [RFC7252] to work as a 242 duration for the period of time during which a server intends to 243 respond to a multicast request. The Patience option in a CoAP 244 request can be used as an upper bound for the Leisure. 246 How to use Leisure is defined in [RFC7252]. 248 2.2.3. Observe usage 250 In a CoAP observe [I-D.ietf-core-observe] scenario, the Patience 251 Option MAY be used in a notification to indicate the maximum time an 252 observer should wait before starting any observation relationship 253 recovery. 255 The Max-Age Option indicates the maximum time a response 256 (notification) may be cached before it MUST be considered stale. The 257 Max-Age Option of a notification is usually set to a value that 258 estimates when the server will send the next notification. However, 259 in the case the value has not changed, the server can decide not to 260 send a new notification, possibly confusing the observer. It is 261 quite difficult for an observer to discriminate the situation that it 262 has not received a new notification because the value has not changed 263 from situations where the server has lost its state, or for some 264 reason has given up on notification delivery. 266 The Patience Option in a notification is used to indicate the maximum 267 time a server will try to reach the client before giving up. This is 268 to save the client some effort in re-establishing observation 269 relationships each time max-age is reached. This option is also 270 useful to give a server the time to send out the notifications, in 271 case there are many CoAP clients observing simultaneously a resource, 272 while avoiding network congestion issues. 274 The server adds the Patience option to any notification related to an 275 observation relationship from which it wants delay an observation 276 refresh request made by the observer. The server sets the option to 277 the maximum time that it is prepared to spend to reach the observer 278 before giving up. 280 The observer interprets this option as the minimum time between the 281 expiration of a notification (as indicated by its Max-Age Option 282 value) and the moment it MAY start an observation relationship 283 recovery action with the server. 285 If the observer does not receive a response within the indicated time 286 interval, the observer SHOULD attempt to re-establish the observation 287 relationship with the server if it is still interested in observing 288 the particular resource. 290 2.3. Detection of IP unicast or multicast CoAP request 292 A single Patience Option, used to indicate potentially either client 293 patience (in the IP unicast case) or server patience (in the IP 294 multicast case), requires that a CoAP server is able to distinguish 295 between IP unicast and multicast requests. If there exist commonly 296 used IP stacks that do not offer such functionality [to be checked], 297 requiring servers to be able to make the unicast/multicast 298 distinction seems unwise and limits the applicability of the Patience 299 Option. 301 Approaches for a CoAP server to detect unicast versus multicast 302 requests may include: 304 1) CoAP server application opens a specific socket and sets IP 305 multicast reception using the POSIX setsockopt function [to be 306 verified if IP unicast traffic also is received in this case, or 307 not]. 309 2) CoAP server checks the IP destination address of incoming packets. 310 If this has the FF00::/8 IPv6 prefix, then it's treated as multicast 311 otherwise unicast [to be verified if IP stack APIs allow to get IP 312 destination]. 314 3) Receiving CoAP multicast requests always occurs on a different 315 port than the standard CoAP port. For example, similar to coaps:// 316 that uses a different port than coap://, a scheme coapm:// on a 317 different port may be defined for multicast requests. 319 3. Example 321 3.1. Unicast Usage Example 323 This section gives a short example with a message flow that 324 illustrates the use of the Patience option in a GET request. 326 This example (Figure 1) shows that the requester wants to get a 327 response within 3200 milliseconds, when T=25, TX=1. 329 requester recipient 330 | | 331 | | 332 +----->| Header: GET (T=CON, Code=1, MID=0x7d38) 333 | GET | Token: 0x53 334 | | Patience: 25/1 335 | | Uri-Path: "temperature" 336 | | 337 |<-----+ Header: 2.05 Content (T=ACK, Code=69, MID=0x7d38) 338 | 2.05 | Token: 0x53 339 | | Payload: "22.3 C" 340 | | 342 Figure 1: Patience Option in a unicast request 344 3.2. Observe Usage Example 346 This section gives a short example with a message flow that 347 illustrates the use of the Patience option in an Observe 348 notification. 350 This example (Figure 2) shows that the server wants the observer to 351 wait 819 seconds (T=25, TX=3) before starting any observation 352 relationship recovery, even though the Max-Age of the temperature 353 value notification is only 120 seconds. 355 Observer Server 356 | | 357 | | 358 +----->| Header: GET (T=CON, Code=1, MID=0x7d38) 359 | GET | Token: 0x53 360 | | Observe: 0 361 | | Uri-Path: "temperature" 362 | | 363 |<-----+ Header: 2.05 Content (T=ACK, Code=69, MID=0x7d38) 364 | 2.05 | Token: 0x53 365 | | Max-Age: 120 366 | | Patience: 25/3 367 | | Payload: "22.3 C" 368 | | 370 Figure 2: Patience Option in an observe notification 372 4. Security Considerations 374 This presents no security considerations beyond those in section 10 375 of the base CoAP specification [RFC7252]. 377 5. IANA Considerations 379 The IANA is requested to add the following "CoAP Option Numbers" 380 entry as per Section 12.2 of [RFC7252]. 382 +-----+---+---+---+---+----------+---------------+--------+---------+ 383 | No. | C | U | N | R | Name | Format | Length | Default | 384 +-----+---+---+---+---+----------+---------------+--------+---------+ 385 | 28 | | | x | | Patience | (ref to this | 1 B | (none) | 386 | | | | | | | document) | | | 387 +-----+---+---+---+---+----------+---------------+--------+---------+ 389 6. Acknowledgements 391 The authors of this draft would like to thank the participants of the 392 email discussion on this issue. Thanks to Carsten Bormann, Peter 393 Bigot, Barry Leiba, Linyi Tian, Gengyu Wei for the reviews and 394 discussions. 396 7. References 398 7.1. Normative References 400 [I-D.ietf-core-observe] 401 Hartke, K., "Observing Resources in CoAP", draft-ietf- 402 core-observe-13 (work in progress), April 2014. 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, March 1997. 407 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 408 Application Protocol (CoAP)", RFC 7252, June 2014. 410 7.2. Informative References 412 [I-D.bormann-coap-misc] 413 Bormann, C. and K. Hartke, "Miscellaneous additions to 414 CoAP", draft-bormann-coap-misc-26 (work in progress), 415 December 2013. 417 Authors' Addresses 419 Kepeng Li 420 Huawei Technologies 421 Huawei Base, Bantian, Longgang District 422 Shenzhen, Guangdong 518129 423 P. R. China 425 Email: likepeng@huawei.com 427 Bert Greevenbosch 428 Huawei Technologies 429 Huawei Base, Bantian, Longgang District 430 Shenzhen, Guangdong 518129 431 P. R. China 433 Email: bert.greevenbosch@huawei.com 435 Esko Dijk 436 Philips Research 437 High Tech Campus 34 438 Eindhoven 439 The Netherlands 441 Email: esko.dijk@philips.com 443 Salvatore Loreto 444 Ericsson 445 Hirsalantie 11 446 Jorvas 02420 447 Finland 449 Email: salvatore.loreto@ericsson.com