idnits 2.17.1 draft-ietf-core-new-block-02.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 (October 29, 2020) is 1274 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) == Missing Reference: 'RFCXXXX' is mentioned on line 862, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-10 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-25) exists of draft-ietf-dots-telemetry-13 -- Obsolete informational reference (is this intentional?): RFC 8782 (Obsoleted by RFC 9132) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CORE M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track J. Shallow 5 Expires: May 2, 2021 October 29, 2020 7 Constrained Application Protocol (CoAP) Block-Wise Transfer Options for 8 Faster Transmission 9 draft-ietf-core-new-block-02 11 Abstract 13 This document specifies alternative Constrained Application Protocol 14 (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. 16 These options are similar to the CoAP Block1 and Block2 Options, not 17 a replacement for them, but do enable faster transmission rates for 18 large amounts of data with less packet interchanges as well as 19 supporting faster recovery should any of the blocks get lost in 20 transmission. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 2, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Existing CoAP Block-Wise Transfer Options . . . . . . . . 3 58 1.2. Alternative CoAP Block-Wise Transfer Options . . . . . . 3 59 1.3. Updated CoAP Response Code (4.08) . . . . . . . . . . . . 4 60 1.4. Applicability Scope . . . . . . . . . . . . . . . . . . . 5 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. The Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 6 63 3.1. Properties of Q-Block1 and Q-Block2 Options . . . . . . . 6 64 3.2. Structure of Q-Block1 and Q-Block2 Options . . . . . . . 7 65 3.3. Using the Q-Block1 Option . . . . . . . . . . . . . . . . 8 66 3.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 9 67 3.5. Working with Observe and Q-Block2 Options . . . . . . . . 11 68 3.6. Working with Size1 and Size2 Options . . . . . . . . . . 11 69 3.7. Use of Q-Block1 and Q-Block2 Options Together . . . . . . 11 70 4. The Use of 4.08 (Request Entity Incomplete) Response Code . . 11 71 5. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 13 72 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 13 73 7. Caching Considerations . . . . . . . . . . . . . . . . . . . 14 74 8. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 15 75 9. Examples of Selective Block Recovery . . . . . . . . . . . . 15 76 9.1. Q-Block1 Option: Non-Confirmable Example . . . . . . . . 16 77 9.2. Q-Block2 Option: Non-Confirmable Example . . . . . . . . 17 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 79 10.1. New CoAP Options . . . . . . . . . . . . . . . . . . . . 19 80 10.2. New Content Format . . . . . . . . . . . . . . . . . . . 20 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 82 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 85 13.2. Informative References . . . . . . . . . . . . . . . . . 22 86 Appendix A. Examples with Confirmable Messages . . . . . . . . . 22 87 A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 22 88 A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 24 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 91 1. Introduction 92 1.1. Existing CoAP Block-Wise Transfer Options 94 The Constrained Application Protocol (CoAP) [RFC7252], although 95 inspired by HTTP, was designed to use UDP instead of TCP. The 96 message layer of CoAP over UDP includes support for reliable 97 delivery, simple congestion control, and flow control. [RFC7959] 98 introduced the CoAP Block1 and Block2 Options to handle data records 99 that cannot fit in a single IP packet, so not having to rely on IP 100 fragmentation and further updated by [RFC8323] for use over TCP, TLS, 101 and Websockets. 103 The CoAP Block1 and Block2 Options work well in environments where 104 there are no or minimal packet losses. These options operate 105 synchronously where each block has to be requested and can only ask 106 for (or send) the next block when the request for the previous block 107 has completed. Packet, and hence block transmission rate, is 108 controlled by Round Trip Times (RTTs). 110 There is a requirement for these blocks of data to be transmitted at 111 higher rates under network conditions where there may be asymmetrical 112 transient packet loss. An example is when a network is subject to a 113 Distributed Denial of Service (DDoS) attack and there is a need for 114 DDoS mitigation agents relying upon CoAP to communicate with each 115 other (e.g., [I-D.ietf-dots-telemetry]). As a reminder, [RFC7959] 116 recommends use of Confirmable (CON) responses to handle potential 117 packet loss; which does not work with a flooded pipe DDoS situation. 119 1.2. Alternative CoAP Block-Wise Transfer Options 121 This document introduces the CoAP Q-Block1 and Q-Block2 Options. 122 These options are similar in operation to the CoAP Block1 and Block2 123 Options respectively, they are not a replacement for them, but have 124 the following benefits: 126 o They can operate in environments where packet loss is highly 127 asymmetrical. 129 o They enable faster transmissions of sets of blocks of data with 130 less packet interchanges. 132 o They support faster recovery should any of the Blocks get lost in 133 transmission. 135 o They support sending an entire body using Non-confirmable (NON) 136 without requiring a response from the peer. 138 There are the following disadvantages over using CoAP Block 1 and 139 Block2 Options: 141 o Loss of lock-stepping so payloads are not always received in the 142 correct (block ascending) order. 144 o Additional congestion control measures need to be put in place. 146 Using NON messages, the faster transmissions occur as all the Blocks 147 can be transmitted serially (as are IP fragmented packets) without 148 having to wait for an acknowledgement or next request from the remote 149 CoAP peer. Recovery of missing Blocks is faster in that multiple 150 missing Blocks can be requested in a single CoAP packet. Even if 151 there is asymmetrical packet loss, a body can still be sent and 152 received by the peer whether the body compromises of a single or 153 multiple payloads assuming no recovery is required. 155 Note that the same performance benefits can be applied to Confirmable 156 messages if the value of NSTART is increased from 1 (Section 4.7 of 157 [RFC7252]). However, the asymmetrical packet loss is not a benefit 158 here. Some sample examples with Confirmable messages are provided in 159 Appendix A. 161 There is little, if any, benefit of using these options with CoAP 162 running over a reliable connection [RFC8323]. In this case, there is 163 no differentiation between Confirmable and NON as they are not used. 165 A CoAP endpoint can acknowledge all or a subset of the blocks. 166 Concretely, the receiving CoAP endpoint informs the CoAP endpoint 167 sender either successful receipt or reports on all blocks in the body 168 that have been not yet been received. The CoAP endpoint sender will 169 then retransmit only the blocks that have been lost in transmission. 171 Q-Block1 and Q-Block2 Options can be used instead of Block1 and 172 Block2 Options respectively when the different transmission semantics 173 are required. If the option is not supported by a peer, then 174 transmissions can fall back to using Block1 and Block2 respectively. 176 The deviations from Block1 and Block2 Options are specified in 177 Section 3. Pointers to appropriate [RFC7959] sections are provided. 179 The specification refers to the base CoAP methods defined in 180 Section 5.8 of [RFC7252] and the new CoAP methods, FETCH, PATCH, and 181 iPATCH introduced in [RFC8132]. 183 1.3. Updated CoAP Response Code (4.08) 185 This document updates the 4.08 (Request Entity Incomplete) by 186 defining an additional message format for reporting on payloads using 187 the Q-Block1 Option that are not received by the server. 189 See Section 4 for more details. 191 1.4. Applicability Scope 193 The block-wise transfer specified in [RFC7959] covers the general 194 case, but falls short in situations where packet loss is highly 195 asymmetrical. The mechanism specified in this document provides 196 roughly similar features to the Block1/Block2 Options. It provides 197 additional properties that are tailored towards the intended use 198 case. Concretely, this mechanism primarily targets applications such 199 as DDoS Open Threat Signaling (DOTS) that can't use Confirmable (CON) 200 responses to handle potential packet loss and that support 201 application-specific mechanisms to assess whether the remote peer is 202 able to handle the messages sent by a CoAP endpoint (e.g., DOTS 203 heartbeats in Section 4.7 of [RFC8782]). 205 The mechanism includes guards to prevent a CoAP agent from 206 overloading the network by adopting an aggressive sending rate. 207 These guards MUST be followed in addition to the existing CoAP 208 congestion control as specified in Section 4.7 of [RFC7252]. See 209 Section 6 for more details. 211 This mechanism is not intended for general CoAP usage, and any use 212 outside the intended use case should be carefully weighed against the 213 loss of interoperability with generic CoAP applications. It is hoped 214 that the experience gained with this mechanism can feed future 215 extensions of the block-wise mechanism that will both generally 216 applicable and serve this particular use case. 218 It is not recommended that these options are used in a NoSec security 219 mode (Section 9 of [RFC7252]) as the source endpoint needs to be 220 trusted. 222 2. Terminology 224 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 225 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 226 "OPTIONAL" in this document are to be interpreted as described in BCP 227 14 [RFC2119][RFC8174] when, and only when, they appear in all 228 capitals, as shown here. 230 Readers should be familiar with the terms and concepts defined in 231 [RFC7252]. 233 The terms "payload" and "body" are defined in [RFC7959]. The term 234 "payload" is thus used for the content of a single CoAP message 235 (i.e., a single block being transferred), while the term "body" is 236 used for the entire resource representation that is being transferred 237 in a block-wise fashion. 239 3. The Q-Block1 and Q-Block2 Options 241 3.1. Properties of Q-Block1 and Q-Block2 Options 243 The properties of Q-Block1 and Q-Block2 Options are shown in Table 1. 244 The formatting of this table follows the one used in Table 4 of 245 [RFC7252] (Section 5.10). The C, U, N, and R columns indicate the 246 properties Critical, Unsafe, NoCacheKey, and Repeatable defined in 247 Section 5.4 of [RFC7252]. Only C and U columns are marked for the 248 Q-Block1 Option. C, U, and R columns are marked for the Q-Block2 249 Option. 251 +--------+---+---+---+---+--------------+--------+--------+---------+ 252 | Number | C | U | N | R | Name | Format | Length | Default | 253 +========+===+===+===+===+==============+========+========+=========+ 254 | TBA1 | x | x | | | Q-Block1 | uint | 0-3 | (none) | 255 | TBA2 | x | x | | x | Q-Block2 | uint | 0-3 | (none) | 256 +--------+---+---+---+---+--------------+--------+--------+---------+ 258 Table 1: CoAP Q-Block1 and Q-Block2 Option Properties 260 The Q-Block1 and Q-Block2 Options can be present in both the request 261 and response messages. The Q-Block1 Option pertains to the request 262 payload and the Q-Block2 Option pertains to the response payload. 263 The Content-Format Option applies to the body, not to the payload 264 (i.e., it must be the same for all payloads of the same body). 266 Q-Block1 Option is useful with the payload-bearing POST, PUT, PATCH, 267 and iPATCH requests and their responses (2.01 and 2.04). 269 Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and 270 iPATCH requests and their payload-bearing responses (2.01, 2.03, 271 2.04, and 2.05) (Section 5.5 of [RFC7252]). 273 A CoAP endpoint (or proxy) MUST support either both or neither of the 274 Q-Block1 and Q-Block2 Options. 276 To indicate support for Q-Block2 responses, the CoAP client MUST 277 include the Q-Block2 Option in a GET or similar request, the Q-Block2 278 Option in a PUT or similar request, or the Q-Block1 Option in a PUT 279 or similar so that the server knows that the client supports this 280 Q-Block2 functionality should it need to send back a body that spans 281 multiple payloads. Otherwise, the server would use the Block2 Option 282 (if supported) to send back a message body that is too large to fit 283 into a single IP packet [RFC7959]. 285 If Q-Block1 Option is present in a request or Q-Block2 Option in a 286 response (i.e., in that message to the payload of which it pertains), 287 it indicates a block-wise transfer and describes how this specific 288 block-wise payload forms part of the entire body being transferred. 289 If it is present in the opposite direction, it provides additional 290 control on how that payload will be formed or was processed. 292 Implementation of the Q-Block1 and Q-Block2 Options is intended to be 293 optional. However, when it is present in a CoAP message, it MUST be 294 processed (or the message rejected). Therefore, Q-Block1 and 295 Q-Block2 Options are identified as Critical options. 297 The Q-Block1 and Q-Block2 Options are unsafe to forward. That is, a 298 CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option 299 MUST reject the request or response that uses either option. 301 The Q-Block2 Option is repeatable when requesting re-transmission of 302 missing Blocks, but not otherwise. Except that case, any request 303 carrying multiple Q-Block1 (or Q-Block2) Options MUST be handled 304 following the procedure specified in Section 5.4.5 of [RFC7252]. 306 The Q-Block1 and Q-Block2 Options, like the Block1 and Block2 307 Options, are both a class E and a class U in terms of OSCORE 308 processing (see Section 4.1 of [RFC8613]): The Q-Block1 (or Q-Block2) 309 Option MAY be an Inner or Outer option. The Inner and Outer values 310 are therefore independent of each other. The Inner option is 311 encrypted and integrity protected between clients and servers, and 312 provides message body identification in case of end-to-end 313 fragmentation of requests. The Outer option is visible to proxies 314 and labels message bodies in case of hop-by-hop fragmentation of 315 requests. 317 3.2. Structure of Q-Block1 and Q-Block2 Options 319 The structure of Q-Block1 and Q-Block2 Options follows the structure 320 defined in Section 2.2 of [RFC7959]. 322 There is no default value for the Q-Block1 and Q-Block2 Options. 323 Absence of one of these options is equivalent to an option value of 0 324 with respect to the value of block number (NUM) and more bit (M) that 325 could be given in the option, i.e., it indicates that the current 326 block is the first and only block of the transfer (block number is 327 set to 0, M is unset). However, in contrast to the explicit value 0, 328 which would indicate a size of the block (SZX) of 0, and thus a size 329 value of 16 bytes, there is no specific explicit size implied by the 330 absence of the option -- the size is left unspecified. (As for any 331 uint, the explicit value 0 is efficiently indicated by a zero-length 332 option; this, therefore, is different in semantics from the absence 333 of the option). 335 3.3. Using the Q-Block1 Option 337 The Q-Block1 Option is used when the client wants to send a large 338 amount of data to the server using the POST, PUT, PATCH, or iPATCH 339 methods where the data and headers do not fit into a single packet. 341 When Q-Block1 Option is used, the client MUST include a single 342 Request-Tag Option [I-D.ietf-core-echo-request-tag]. The Request-Tag 343 value MUST be the same for all of the blocks in the body of data that 344 is being transferred. It is also used to identify a particular block 345 of a body that needs to be re-transmitted. The Request-Tag is opaque 346 in nature, but it is RECOMMENDED that the client treats it as an 347 unsigned integer of 8 bytes in length. An implementation may want to 348 consider limiting this to 4 bytes to reduce packet overhead size. 349 The server still treats it as an opaque entity. The Request-Tag 350 value MUST be different for distinct bodies or sets of blocks of data 351 and SHOULD be incremented whenever a new body of data is being 352 transmitted for a CoAP session between peers. The initial Request- 353 Tag value SHOULD be randomly generated by the client. 355 For Confirmable transmission, the server MUST continue to acknowledge 356 each packet. NSTART will also need to be increased from the default 357 (1) to get faster transmission rates. 359 Each individual payload of the body is treated as a new request (see 360 Section 5). 362 A 2.01 (Created) or 2.04 (Changed) Response Code indicates successful 363 receipt of the entire body. 365 The 2.31 (Continue) Response is not used in the current version of 366 the specification. 368 A 4.00 (Bad Request) Response Code MUST be returned if the request 369 does not include a Request-Tag Option but does include a Q-Block1 370 option. 372 A 4.02 (Bad Option) Response Code MUST be returned if the server does 373 not support the Q-Block1 Option. 375 A 4.13 (Request Entity Too Large) Response Code can be returned under 376 similar conditions to those discussed in Section 2.9.3 of [RFC7959]. 378 A 4.08 (Request Entity Incomplete) Response Code returned without 379 Content-Type "application/missing-blocks+cbor-seq" (Section 10.2) is 380 handled as in Section 2.9.2 [RFC7959]. 382 A 4.08 (Request Entity Incomplete) Response Code returned with 383 Content-Type "application/missing-blocks+cbor-seq" indicates that 384 some of the payloads are missing and need to be resent. The client 385 then re-transmits the missing payloads using the Request-Tag and 386 Q-Block1 to specify the block number, SZX, and M bit as appropriate. 387 The Request-Tag value to use is determined from the payload of the 388 4.08 (Request Entity Incomplete) Response Code. If the client does 389 not recognize the Request-Tag, the client can ignore this response. 391 If the server has not received all the payloads of a body, but one or 392 more payloads have been received, it SHOULD wait for up to 393 MAX_TRANSMIT_SPAN (Section 4.8.2 of [RFC7252]) before sending the 394 4.08 (Request Entity Incomplete) Response Code. However, this time 395 MAY be reduced to two times ACK_TIMEOUT before sending a 4.08 396 (Request Entity Incomplete) Response Code to cover the situation 397 where MAX_PAYLOADS has been triggered by the client causing a break 398 in transmission. 400 If the client transmits a new body of data with a new Request-Tag to 401 the same resource on a server, the server MUST remove any partially 402 received body held for a previous Request-Tag for that resource. 404 If the server receives a duplicate block with the same Request-Tag, 405 it SHOULD silently ignore the packet. 407 A server SHOULD only maintain a partial body (missing payloads) for 408 up to EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). 410 3.4. Using the Q-Block2 Option 412 In a request for any block number, the M bit unset indicates the 413 request is just for that block. If the M bit is set, this indicates 414 that this is a request for this block and for all of the remaining 415 blocks within the body. If the server receives multiple requests 416 (implied or otherwise) for the same block, it MUST only send back one 417 instance of that block. 419 The payloads sent back from the server as a response MUST all have 420 the same ETag (Section 5.10.6 of [RFC7252]) for the same body. The 421 server MUST NOT use the same ETag value for different representations 422 of a resource. 424 The ETag is opaque in nature, but it is RECOMMENDED that the server 425 treats it as an unsigned integer of 8 bytes in length. An 426 implementation may want to consider limiting this to 4 bytes to 427 reduce packet overhead size. The client still treats it as an opaque 428 entity. The ETag value MUST be different for distinct bodies or sets 429 of blocks of data and SHOULD be incremented whenever a new body of 430 data is being transmitted for a CoAP session between peers. The 431 initial ETag value SHOULD be randomly generated by the server. 433 If the client detects that some of the payloads are missing, the 434 missing payloads are requested by issuing a new GET, POST, PUT, 435 FETCH, PATCH, or iPATCH request that contains one or more Q-Block2 436 Options that define the missing blocks with the M bit unset. 438 The requested missing block numbers MUST have an increasing block 439 number in each additional Q-Block2 Option with no duplicates. The 440 server SHOULD respond with a 4.00 (Bad Request) if this is the case. 442 The ETag Option MUST NOT be used in the request as the server could 443 respond with a 2.03 (Valid Response) with no payload. If the server 444 responds with a different ETag Option value (as the resource 445 representation has changed), then the client SHOULD drop all the 446 payloads for the current body that are no longer valid. 448 The client may elect to request the missing blocks or just ignore the 449 partial body. It SHOULD wait for up to MAX_TRANSMIT_SPAN 450 (Section 4.8.2 of [RFC7252]) before issuing a GET, POST, PUT, FETCH, 451 PATCH, or iPATCH request for the missing blocks. However, this time 452 MAY be reduced to two times ACK_TIMEOUT before sending the request to 453 cover the situation where MAX_PAYLOADS has been triggered by the 454 server causing a break in transmission. 456 With NON transmission, the client only needs to indicate that some of 457 the payloads are missing by issuing a GET, POST, PUT, FETCH, PATCH, 458 or iPATCH request for the missing blocks. 460 For Confirmable transmission, the client SHOULD continue to 461 acknowledge each packet as well as issuing a separate GET, POST, PUT, 462 FETCH, PATCH, or iPATCH for the missing blocks. 464 If the server transmits a new body of data (e.g., a triggered 465 Observe) with a new ETag to the same client as an additional 466 response, the client MUST remove any partially received body held for 467 a previous ETag. 469 If the client receives a duplicate block with the same ETag, it 470 SHOULD silently ignore the packet. 472 A client SHOULD only maintain a partial body (missing payloads) for 473 up to EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) or as defined by 474 the Max-Age Option whichever is the less. 476 If there is insufficient space to create a response PDU with a block 477 size of 16 bytes (SZX = 0) to reflect back all the request options as 478 appropriate, a 4.13 (Request Entity Too Large) is returned without 479 the Size2 Option. 481 3.5. Working with Observe and Q-Block2 Options 483 As the blocks of the body are sent without waiting for 484 acknowledgement of the individual blocks, the Observe value [RFC7641] 485 MUST be the same for all the blocks of the same body. 487 If the client requests missing blocks, this is treated as a new 488 request. The Observe value may change but MUST still be reported. 489 If the ETag value changes then the previously received partial body 490 should be destroyed and the whole body re-requested. 492 3.6. Working with Size1 and Size2 Options 494 Section 4 of [RFC7959] defines two CoAP options: Size1 for indicating 495 the size of the representation transferred in requests and Size2 for 496 indicating the size of the representation transferred in responses. 498 The Size1 or Size2 option values MUST exactly represent the size of 499 the data on the body so that any missing data can easily be 500 determined. 502 The Size1 Option MUST be used with the Q-Block1 Option when used in a 503 request. The Size2 Option MUST be used with the Q-Block2 Option when 504 used in a response. 506 If Size1 or Size2 Options are used, they MUST be used in all payloads 507 of the body and MUST have the same value. 509 3.7. Use of Q-Block1 and Q-Block2 Options Together 511 The behavior is similar to the one defined in Section 3.3 of 512 [RFC7959] with Q-Block1 substituted for Block1 and Q-Block2 for 513 Block2. 515 4. The Use of 4.08 (Request Entity Incomplete) Response Code 517 4.08 (Request Entity Incomplete) Response Code has a new Content-Type 518 "application/missing-blocks+cbor-seq" used to indicate that the 519 server has not received all of the blocks of the request body that it 520 needs to proceed. 522 Likely causes are the client has not sent all blocks, some blocks 523 were dropped during transmission, or the client has sent them 524 sufficiently long ago that the server has already discarded them. 526 The data payload of the 4.08 (Request Entity Incomplete) Response 527 Code is encoded as a CBOR Sequence [RFC8742]. First is CBOR encoded 528 Request-Tag followed by 1 or more missing CBOR encoded missing block 529 numbers. The missing block numbers MUST be unique in each 4.08 530 (Request Entity Incomplete) when created by the server; the client 531 SHOULD drop any duplicates in the same 4.08 (Request Entity 532 Incomplete) message. 534 The Content-Format Option (Section 5.10.3 of [RFC7252]) MUST be used 535 in the 4.08 (Request Entity Incomplete) Response Code. It MUST be 536 set to "application/missing-blocks+cbor-seq" (see Section 10.2). 538 The Concise Data Definition Language [RFC8610] for the data 539 describing these missing blocks is as follows: 541 ; This defines an array, the elements of which are to be used 542 ; in a CBOR Sequence: 543 payload = [request-tag, + missing-block-number] 544 request-tag = bstr 545 ; A unique block number not received: 546 missing-block-number = uint 548 Figure 1: Structure of the Missing Blocks Payload 550 If the size of the 4.08 (Request Entity Incomplete) response packet 551 is larger than that defined by Section 4.6 [RFC7252], then the number 552 of missing blocks MUST be limited so that the response can fit into a 553 single packet. If this is the case, then the server can send 554 subsequent 4.08 (Request Entity Incomplete) responses containing the 555 missing blocks on receipt of a new request providing a missing 556 payload with the same Request-Tag. 558 The missing blocks MUST be reported in ascending order without any 559 duplicates. The client SHOULD silently drop 4.08 (Request Entity 560 Incomplete) responses not adhering with this behavior. 562 Implementation Note: Updating the payload without overflowing the 563 overall packet size as each block number can be of varying length 564 needs consideration. It is possible to use Indefinite-Length 565 Arrays (Section 2.2.1 of [RFC7049]), limit the array count to 23 566 (Undefined value) so that the array data byte can be updated with 567 the overall length once the payload length is confirmed or limited 568 to MAX_PAYLOADS count. Limiting the count to MAX_PAYLOADS means 569 that Congestion Control is less likely to be invoked on the 570 server. 572 5. The Use of Tokens 574 Each new request MUST use a unique Token (Section 4 of 575 [I-D.ietf-core-echo-request-tag]). Additional responses may use the 576 same Token. 578 Implementation Note: To minimize on the number of tokens that have 579 to be tracked by clients, it is recommended that the bottom 32 580 bits is kept the same for the same body and the upper 32 bits 581 contains the individual payload number. 583 Servers continue to treat the token as a unique opaque entity. If 584 an individual payload has to be resent (e.g., requested upon 585 packet loss), then the retransmitted packet is treated as a new 586 request (i.e., the bottom 32 bits must change). 588 6. Congestion Control 590 PROBING_RATE parameter in CoAP indicates the average data rate that 591 must not be exceeded by a CoAP endpoint in sending to a peer endpoint 592 that does not respond. The body of blocks will be subjected to 593 PROBING_RATE (Section 4.7 of [RFC7252]). 595 Each NON 4.08 (Request Entity Incomplete) Response Codes is subjected 596 to PROBING_RATE. 598 Each NON GET or similar request using Q-Block2 Option is subjected to 599 PROBING_RATE. 601 As the sending of many payloads of a single body may itself cause 602 congestion, it is RECOMMENDED that after transmission of every set of 603 MAX_PAYLOADS payloads of a single body, a delay is introduced of 604 ACK_TIMEOUT (Section 4.8.2 of [RFC7252]) before the next set of 605 payload transmissions to manage potential congestion issues. 606 MAX_PAYLOADS should be configurable with a default value of 10. 608 Note: The default value is chosen for reasons similar to those 609 discussed in Section 5 of [RFC6928]. 611 For NON transmissions, it is permissible, but not required, to send 612 the ultimate payload of a MAX_PAYLOADS set as a Confirmable packet. 613 If a Confirmable packet is used, then the transmitting peer MUST wait 614 for the ACK to be returned before sending the next set of payloads, 615 which can be in time terms less than the ACK_TIMEOUT delay. 617 Also, for NON transmissions, it is permissible, but not required, to 618 send a Confirmable packet for the final payload of a body transfer 619 (that is, M bit unset). If a Confirmable packet is used, then the 620 transmitting peer MUST wait for the appropriate response to be 621 returned for successful transmission, or respond to requests for the 622 missing blocks (if any). 624 The sending of the set of missing blocks is subject to MAX_PAYLOADS. 626 Note: A delay of ACK_TIMEOUT after every transmission of 627 MAX_PAYLOADS blocks may be observed even if the peer agent is able 628 to handle more blocks without experiencing an overload. This 629 delay can be reduced by using CON for the MAX_PAYLOADS packet to 630 trigger sending the next set of data when the ACK is received. 631 Nevertheless, this behavior is likely to create other timeout 632 issues in a lossy environment (e.g., unidirectional loss as in 633 DDoS pipe flooding). The use of NON is thus superior but requires 634 an additional signal in the MAX_PAYLOADS packet to seek for a 2.31 635 (Continue) from the peer if it is ready to receive the next set of 636 blocks. 638 7. Caching Considerations 640 Caching block based information is not straight forward in a proxy. 641 For Q-Block1 and Q-Block2 Options, it is expected that the proxy will 642 reassemble the body (using any appropriate recovery options for 643 packet loss) before passing on the body to the appropriate CoAP 644 endpoint. The onward transmission of the body does not require the 645 use of the Q-Block1 or Q-Block2 Options as these options may not be 646 supported in that link. This means that the proxy must fully support 647 the Q-Block1 and Q-Block2 Options. 649 How the body is cached in the initial CoAP client (Q-Block1) or 650 ultimate CoAP server (Q-Block2) is implementation specific. 652 As the entire body is being cached in the proxy, the Q-Block1 and 653 Q-Block2 Options are not part of the cache key. 655 For Q-Block2 responses, the ETag Option value is associated with the 656 data (and onward transmitted to the CoAP client), but is not part of 657 the cache key. 659 For requests with Q-Block1 Option, the Request-Tag Option is 660 associated with the build up of the body from successive payloads, 661 but is not part of the cache key. For the onward transmission of the 662 body using CoAP, a new Request-Tag SHOULD be generated and used. 664 It is possible that two or more CoAP clients are concurrently 665 updating the same resource through a common proxy to the same CoAP 666 server using Q-Block1 (or Block1) Option. If this is the case, the 667 first client to complete building the body causes that body to start 668 transmitting to the CoAP server with an appropriate Request-Tag 669 value. When the next client completes building the body, any 670 existing partial body transmission to the CoAP server is terminated 671 and the new body representation transmission starts with a new 672 Request-Tag value. 674 A proxy that supports Q-Block2 Option MUST be prepared to receive a 675 GET or similar message indicating one or more missing blocks. The 676 proxy will serve from its cache the missing blocks that are available 677 in its cache in the same way a server would send all the appropriate 678 Q-Block2s. If the cache key matching body is not available in the 679 cache, the proxy MUST request the entire body from the CoAP server 680 using the information in the cache key. 682 How long a CoAP endpoint (or proxy) keeps the body in its cache is 683 implementation specific (e.g., it may be based on Max-Age). 685 8. HTTP-Mapping Considerations 687 As a reminder, the basic normative requirements on HTTP/CoAP mappings 688 are defined in Section 10 of [RFC7252]. The implementation 689 guidelines for HTTP/CoAP mappings are elaborated in [RFC8075]. 691 The rules defined in Section 5 of [RFC7959] are to be followed. 693 9. Examples of Selective Block Recovery 695 This section provides some sample flows to illustrate the use of 696 Q-Block1 and Q-Block2 Options. Figure 2 lists the conventions that 697 are used in the following subsections. 699 T: Token value 700 O: Observe Option value 701 M: Message ID 702 RT: Request-Tag 703 ET: ETag 704 QB1: Q-Block1 Option values NUM/More/SZX 705 QB2: Q-Block2 Option values NUM/More/SZX 706 \: Trimming long lines 707 [[]]: Comments 708 -->X: Message loss 709 X<--: Message loss 711 Figure 2: Notations Used in the Figures 713 9.1. Q-Block1 Option: Non-Confirmable Example 715 Figure 3 depicts an example of a NON PUT request conveying Q-Block1 716 Option. All the blocks are received by the server. 718 CoAP CoAP 719 Client Server 720 | | 721 +--------->| NON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024 722 +--------->| NON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024 723 +--------->| NON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024 724 +--------->| NON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024 725 |<---------+ NON 2.04 M:0xf1 T:0xf3 726 ... 728 Figure 3: Example of NON Request with Q-Block1 Option (Without Loss) 730 Consider now a scenario where a new body of data is to be sent by the 731 client, but some blocks are dropped in transmission as illustrated in 732 Figure 4. 734 CoAP CoAP 735 Client Server 736 | | 737 +--------->| NON PUT /path M:0x05 T:0xe0 RT=11 QB1:0/1/1024 738 +--->X | NON PUT /path M:0x06 T:0xe1 RT=11 QB1:1/1/1024 739 +--->X | NON PUT /path M:0x07 T:0xe2 RT=11 QB1:2/1/1024 740 +--------->| NON PUT /path M:0x08 T:0xe3 RT=11 QB1:3/0/1024 741 | | 742 ... 744 Figure 4: Example of NON Request with Q-Block1 Option (With Loss) 746 The server realizes that some blocks are missing and asks for the 747 missing ones in one go (Figure 5). It does so by indicating which 748 blocks have been received in the data portion of the response. 750 CoAP CoAP 751 Client Server 752 | | 753 ... 754 |<---------+ NON 4.08 M:0xf2 T:0xe3 [Missing 1,2 for RT=11] 755 +--------->| NON PUT /path M:0x09 T:0xe4 RT=11 QB1:1/1/1024 756 +--->X | NON PUT /path M:0x0a T:0xe5 RT=11 QB1:2/1/1024 757 | | 758 |<---------+ NON 4.08 M:0xf3 T:0xe4 [Missing 2 for RT=11] 759 +--------->| NON PUT /path M:0x0b T:0xe6 RT=11 QB1:2/1/1024 760 |<---------+ NON 2.04 M:0xf4 T:0xe6 761 | | 762 ... 764 Figure 5: Example of NON Request with Q-Block1 Option (Blocks 765 Recovery) 767 Under high levels of traffic loss, the client can elect not to retry 768 sending missing blocks of data. This decision is implementation 769 specific. 771 9.2. Q-Block2 Option: Non-Confirmable Example 773 Figure 6 illustrates the example of Q-Block2 Option. The client 774 sends a NON GET carrying an Observe and a Q-Block2 Options. The 775 Q-Block2 Option indicates a size hint (1024 bytes). This request is 776 replied by the server using four (4) blocks that are transmitted to 777 the client without any loss. Each of these blocks carries a Q-Block2 778 Option. The same process is repeated when an Observe is triggered, 779 but no loss is experienced by any of the notification blocks. 781 CoAP CoAP 782 Client Server 783 | | 784 +--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/0/1024 785 |<---------+ NON 2.05 M:0xf1 T:0xf0 O:1234 ET=21 QB2:0/1/1024 786 |<---------+ NON 2.05 M:0xf2 T:0xf0 O:1234 ET=21 QB2:1/1/1024 787 |<---------+ NON 2.05 M:0xf3 T:0xf0 O:1234 ET=21 QB2:2/1/1024 788 |<---------+ NON 2.05 M:0xf4 T:0xf0 O:1234 ET=21 QB2:3/0/1024 789 ... 790 [[Observe triggered]] 791 |<---------+ NON 2.05 M:0xf5 T:0xf0 O:1235 ET=22 QB2:0/1/1024 792 |<---------+ NON 2.05 M:0xf6 T:0xf0 O:1235 ET=22 QB2:1/1/1024 793 |<---------+ NON 2.05 M:0xf7 T:0xf0 O:1235 ET=22 QB2:2/1/1024 794 |<---------+ NON 2.05 M:0xf8 T:0xf0 O:1235 ET=22 QB2:3/0/1024 795 ... 797 Figure 6: Example of NON Notifications with Q-Block2 Option (Without 798 Loss) 800 Figure 7 shows the example of an Observe that is triggered but for 801 which some notification blocks are lost. The client detects the 802 missing blocks and request their retransmission. It does so by 803 indicating the blocks that were successfully received. 805 CoAP CoAP 806 Client Server 807 | | 808 ... 809 [[Observe triggered]] 810 |<---------+ NON 2.05 M:0xf9 T:0xf0 O:1236 ET=23 QB2:0/1/1024 811 | X<---+ NON 2.05 M:0xfa T:0xf0 O:1236 ET=23 QB2:1/1/1024 812 | X<---+ NON 2.05 M:0xfb T:0xf0 O:1236 ET=23 QB2:2/1/1024 813 |<---------+ NON 2.05 M:0xfc T:0xf0 O:1236 ET=23 QB2:3/0/1024 814 | | 815 [[Client realizes blocks are missing and asks for the missing 816 ones in one go]] 817 +--------->| NON GET /path M:0x02 T:0xf1 QB2:1/0/1024\ 818 | | QB2:2/0/1024 819 | X<---+ NON 2.05 M:0xfd T:0xf1 ET=23 QB2:1/1/1024 820 |<---------+ NON 2.05 M:0xfe T:0xf1 ET=23 QB2:2/1/1024 821 | | 822 [[Get the final missing block]] 823 +--------->| NON GET /path M:0x03 T:0xf2 QB2:1/0/1024 824 |<---------+ NON 2.05 M:0xff T:0xf2 ET=23 QB2:1/1/1024 825 ... 827 Figure 7: Example of NON Notifications with Q-Block2 Option (Blocks 828 Recovery) 830 Under high levels of traffic loss, the client can elect not to retry 831 getting missing blocks of data. This decision is implementation 832 specific. 834 10. IANA Considerations 836 10.1. New CoAP Options 838 IANA is requested to add the following entries to the "CoAP Option 839 Numbers" sub-registry [Options]: 841 +--------+------------------+-----------+ 842 | Number | Name | Reference | 843 +========+==================+===========+ 844 | TBA1 | Q-Block1 | [RFCXXXX] | 845 | TBA2 | Q-Block2 | [RFCXXXX] | 846 +--------+------------------+-----------+ 848 Table 2: CoAP Q-Block1 and Q-Block2 Option Numbers 850 This document suggests 19 (TBA1) and 51 (TBA2) as a values to be 851 assigned for the new option numbers. 853 10.2. New Content Format 855 This document requests IANA to register the CoAP Content-Format ID 856 for the "application/missing-blocks+cbor-seq" media type in the "CoAP 857 Content-Formats" registry [Format]: 859 o Media Type: application/missing-blocks+cbor-seq 860 o Encoding: - 861 o Id: TBD3 862 o Reference: [RFCXXXX] 864 11. Security Considerations 866 Security considerations discussed in Section 7 of [RFC7959] should be 867 taken into account. 869 Security considerations discussed in Sections 11.3 and 11.4 of 870 [RFC7252] should be taken into account. In particular, it is NOT 871 RECOMMENDED that the NoSec security mode is used if the Q-Block1 and 872 Q-Block2 Options are to be used. 874 Security considerations related to the use of Request-Tag are 875 discussed in Section 5 of [I-D.ietf-core-echo-request-tag]. 877 12. Acknowledgements 879 Thanks to Achim Kraus, Jim Schaad, and Michael Richardson for the 880 comments on the mailing list. 882 Special thanks to Christian Amsuess and Carsten Bormann for their 883 suggestions and several reviews, which improved this specification 884 significantly. 886 Some text from [RFC7959] is reused for readers convenience. 888 13. References 890 13.1. Normative References 892 [I-D.ietf-core-echo-request-tag] 893 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 894 Request-Tag, and Token Processing", draft-ietf-core-echo- 895 request-tag-10 (work in progress), July 2020. 897 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 898 Requirement Levels", BCP 14, RFC 2119, 899 DOI 10.17487/RFC2119, March 1997, 900 . 902 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 903 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 904 October 2013, . 906 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 907 Application Protocol (CoAP)", RFC 7252, 908 DOI 10.17487/RFC7252, June 2014, 909 . 911 [RFC7641] Hartke, K., "Observing Resources in the Constrained 912 Application Protocol (CoAP)", RFC 7641, 913 DOI 10.17487/RFC7641, September 2015, 914 . 916 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 917 the Constrained Application Protocol (CoAP)", RFC 7959, 918 DOI 10.17487/RFC7959, August 2016, 919 . 921 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 922 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 923 the Constrained Application Protocol (CoAP)", RFC 8075, 924 DOI 10.17487/RFC8075, February 2017, 925 . 927 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 928 FETCH Methods for the Constrained Application Protocol 929 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 930 . 932 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 933 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 934 May 2017, . 936 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 937 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 938 Application Protocol) over TCP, TLS, and WebSockets", 939 RFC 8323, DOI 10.17487/RFC8323, February 2018, 940 . 942 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 943 "Object Security for Constrained RESTful Environments 944 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 945 . 947 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 948 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 949 . 951 13.2. Informative References 953 [Format] , . 956 [I-D.ietf-dots-telemetry] 957 Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c., 958 and J. Shallow, "Distributed Denial-of-Service Open Threat 959 Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-13 960 (work in progress), October 2020. 962 [Options] , . 965 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 966 "Increasing TCP's Initial Window", RFC 6928, 967 DOI 10.17487/RFC6928, April 2013, 968 . 970 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 971 Definition Language (CDDL): A Notational Convention to 972 Express Concise Binary Object Representation (CBOR) and 973 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 974 June 2019, . 976 [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., 977 Mortensen, A., and N. Teague, "Distributed Denial-of- 978 Service Open Threat Signaling (DOTS) Signal Channel 979 Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, 980 . 982 Appendix A. Examples with Confirmable Messages 984 These examples assume NSTART has been increased to at least 4. 986 The notations provided in Figure 2 are used in the following 987 subsections. 989 A.1. Q-Block1 Option 991 Let's now consider the use Q-Block1 Option with a CON request as 992 shown in Figure 8. All the blocks are acknowledged (ACK). 994 CoAP CoAP 995 Client Server 996 | | 997 +--------->| CON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024 998 +--------->| CON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024 999 +--------->| CON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024 1000 +--------->| CON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024 1001 |<---------+ ACK 0.00 M:0x01 1002 |<---------+ ACK 0.00 M:0x02 1003 |<---------+ ACK 0.00 M:0x03 1004 |<---------+ ACK 2.04 M:0x04 1006 Figure 8: Example of CON Request with Q-Block1 Option (Without Loss) 1008 Now, suppose that a new body of data is to sent but with some blocks 1009 dropped in transmission as illustrated in Figure 9. The client will 1010 retry sending blocks for which no ACK was received. 1012 CoAP CoAP 1013 Client Server 1014 | | 1015 +--------->| CON PUT /path M:0x05 T:0xf4 RT=11 QB1:0/1/1024 1016 +--->X | CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 1017 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 1018 +--------->| CON PUT /path M:0x08 T:0xf7 RT=11 QB1:3/1/1024 1019 |<---------+ ACK 0.00 M:0x05 1020 |<---------+ ACK 0.00 M:0x08 1021 | | 1022 [[The client retries sending packets not acknowledged]] 1023 +--------->| CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 1024 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 1025 |<---------+ ACK 0.00 M:0x06 1026 | | 1027 [[The client retransmits messages not acknowledged 1028 (exponential backoff)]] 1029 +--->? | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 1030 | | 1031 [[Either transmission failure (acknowledge retry timeout) 1032 or successfully transmitted.]] 1034 Figure 9: Example of CON Request with Q-Block1 Option (Blocks 1035 Recovery) 1037 It is implementation dependent as to whether a CoAP session is 1038 terminated following acknowledge retry timeout, or whether the CoAP 1039 session continues to be used under such adverse traffic conditions. 1041 If there is likely to be the possibility of network transient losses, 1042 then the use of Non-confirmable traffic should be considered. 1044 A.2. Q-Block2 Option 1046 An example of the use of Q-Block2 Option with Confirmable messages is 1047 shown in Figure 10. 1049 Client Server 1050 | | 1051 +--------->| CON GET /path M:0x01 T:0xf0 O:0 QB2:0/0/1024 1052 |<---------+ ACK 2.05 M:0x01 T:0xf0 O:1234 ET=21 QB2:0/1/1024 1053 |<---------+ ACK 2.05 M:0xe1 T:0xf0 O:1234 ET=21 QB2:1/1/1024 1054 |<---------+ ACK 2.05 M:0xe2 T:0xf0 O:1234 ET=21 QB2:2/1/1024 1055 |<---------+ ACK 2.05 M:0xe3 T:0xf0 O:1234 ET=21 QB2:3/0/1024 1056 ... 1057 [[Observe triggered]] 1058 |<---------+ CON 2.05 M:0xe4 T:0xf0 O:1235 ET=22 QB2:0/1/1024 1059 |<---------+ CON 2.05 M:0xe5 T:0xf0 O:1235 ET=22 QB2:1/1/1024 1060 |<---------+ CON 2.05 M:0xe6 T:0xf0 O:1235 ET=22 QB2:2/1/1024 1061 |<---------+ CON 2.05 M:0xe7 T:0xf0 O:1235 ET=22 QB2:3/0/1024 1062 |--------->+ ACK 0.00 M:0xe4 1063 |--------->+ ACK 0.00 M:0xe5 1064 |--------->+ ACK 0.00 M:0xe6 1065 |--------->+ ACK 0.00 M:0xe7 1066 ... 1067 [[Observe triggered]] 1068 |<---------+ CON 2.05 M:0xe8 T:0xf0 O:1236 ET=23 QB2:0/1/1024 1069 | X<---+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 1070 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 1071 |<---------+ CON 2.05 M:0xeb T:0xf0 O:1236 ET=23 QB2:3/0/1024 1072 |--------->+ ACK 0.00 M:0xe8 1073 |--------->+ ACK 0.00 M:0xeb 1074 | | 1075 [[Server retransmits messages not acknowledged]] 1076 |<---------+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 1077 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 1078 |--------->+ ACK 0.00 M:0xe9 1079 | | 1080 [[Server retransmits messages not acknowledged 1081 (exponential backoff)]] 1082 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 1083 | | 1084 [[Either transmission failure (acknowledge retry timeout) 1085 or successfully transmitted.]] 1087 Figure 10: Example of CON Notifications with Q-Block2 Option 1089 It is implementation-dependent as to whether a CoAP session is 1090 terminated following acknowledge retry timeout, or whether the CoAP 1091 session continues to be used under such adverse traffic conditions. 1093 If there is likely to be the possibility of network transient losses, 1094 then the use of Non-confirmable traffic should be considered. 1096 Authors' Addresses 1098 Mohamed Boucadair 1099 Orange 1100 Rennes 35000 1101 France 1103 Email: mohamed.boucadair@orange.com 1105 Jon Shallow 1106 United Kingdom 1108 Email: supjps-ietf@jpshallow.com