idnits 2.17.1 draft-ietf-core-new-block-14.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 26, 2021) is 1059 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: 'Missing 1' is mentioned on line 1625, but not defined -- Looks like a reference, but probably isn't: '9' on line 1310 == Missing Reference: 'Missing 10' is mentioned on line 1320, but not defined -- Looks like a reference, but probably isn't: '2' on line 1625 == Missing Reference: 'RFCXXXX' is mentioned on line 1795, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-12 == Outdated reference: A later version (-03) exists of draft-bosh-dots-quick-blocks-01 == Outdated reference: A later version (-25) exists of draft-ietf-dots-telemetry-15 -- Obsolete informational reference (is this intentional?): RFC 8782 (Obsoleted by RFC 9132) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track J. Shallow 5 Expires: November 27, 2021 May 26, 2021 7 Constrained Application Protocol (CoAP) Block-Wise Transfer Options 8 Supporting Robust Transmission 9 draft-ietf-core-new-block-14 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, but distinct from, the CoAP Block1 and 17 Block2 Options defined in RFC 7959. Q-Block1 and Q-Block2 Options 18 are not intended to replace Block1 and Block2 Options, but rather 19 have the goal of supporting Non-confirmable messages for large 20 amounts of data with fewer packet interchanges. Also, the Q-Block1 21 and Q-Block2 Options support faster recovery should any of the blocks 22 get lost in transmission. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 27, 2021. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Alternative CoAP Block-Wise Transfer Options . . . . . . . . 5 61 3.1. CoAP Response Code (4.08) Usage . . . . . . . . . . . . . 7 62 3.2. Applicability Scope . . . . . . . . . . . . . . . . . . . 7 63 4. The Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 8 64 4.1. Properties of Q-Block1 and Q-Block2 Options . . . . . . . 8 65 4.2. Structure of Q-Block1 and Q-Block2 Options . . . . . . . 10 66 4.3. Using the Q-Block1 Option . . . . . . . . . . . . . . . . 11 67 4.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 15 68 4.5. Using Observe Option . . . . . . . . . . . . . . . . . . 17 69 4.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 17 70 4.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 18 71 4.8. Using Q-Block2 Option With Multicast . . . . . . . . . . 18 72 5. The Use of 4.08 (Request Entity Incomplete) Response Code . . 18 73 6. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 19 74 7. Congestion Control for Unreliable Transports . . . . . . . . 20 75 7.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 20 76 7.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 20 77 8. Caching Considerations . . . . . . . . . . . . . . . . . . . 25 78 9. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 26 79 10. Examples with Non-confirmable Messages . . . . . . . . . . . 26 80 10.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . 27 81 10.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 27 82 10.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 27 83 10.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 27 84 10.1.4. Handling Recovery with Failure . . . . . . . . . . . 29 85 10.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . 30 86 10.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 30 87 10.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 31 88 10.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 32 89 10.2.4. Handling Recovery using M-bit Set . . . . . . . . . 33 90 10.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . 34 91 10.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 34 92 10.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 35 93 10.3.3. Handling Recovery . . . . . . . . . . . . . . . . . 36 94 11. Security Considerations . . . . . . . . . . . . . . . . . . . 38 95 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 96 12.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 39 97 12.2. Media Type Registration . . . . . . . . . . . . . . . . 39 98 12.3. CoAP Content-Formats Registry . . . . . . . . . . . . . 40 99 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 100 13.1. Normative References . . . . . . . . . . . . . . . . . . 41 101 13.2. Informative References . . . . . . . . . . . . . . . . . 42 102 Appendix A. Examples with Confirmable Messages . . . . . . . . . 43 103 A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 43 104 A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 45 105 Appendix B. Examples with Reliable Transports . . . . . . . . . 47 106 B.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 47 107 B.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 47 108 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 48 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 111 1. Introduction 113 The Constrained Application Protocol (CoAP) [RFC7252], although 114 inspired by HTTP, was designed to use UDP instead of TCP. The 115 message layer of CoAP over UDP includes support for reliable 116 delivery, simple congestion control, and flow control. CoAP supports 117 two message types (Section 1.2 of [RFC7252]): Confirmable (CON) and 118 Non-confirmable (NON) messages. Unlike NON messages, every CON 119 message will elicit an acknowledgement or a reset. 121 The CoAP specification recommends that a CoAP message should fit 122 within a single IP packet (i.e., avoid IP fragmentation). To handle 123 data records that cannot fit in a single IP packet, [RFC7959] 124 introduced the concept of block-wise transfer and the companion CoAP 125 Block1 and Block2 Options. However, this concept is designed to work 126 exclusively with Confirmable messages (Section 1 of [RFC7959]). Note 127 that the block-wise transfer was further updated by [RFC8323] for use 128 over TCP, TLS, and WebSockets. 130 The CoAP Block1 and Block2 Options work well in environments where 131 there are no, or minimal, packet losses. These options operate 132 synchronously, i.e., each individual block has to be requested. A 133 CoAP endpoint can only ask for (or send) the next block when the 134 transfer of the previous block has completed. Packet transmission 135 rate, and hence block transmission rate, is controlled by Round Trip 136 Times (RTTs). 138 There is a requirement for blocks of data larger than a single IP 139 datagram to be transmitted under network conditions where there may 140 be asymmetrical transient packet loss (e.g., acknowledgment responses 141 may get dropped). An example is when a network is subject to a 142 Distributed Denial of Service (DDoS) attack and there is a need for 143 DDoS mitigation agents relying upon CoAP to communicate with each 144 other (e.g., [RFC8782][I-D.ietf-dots-telemetry]). As a reminder, 146 [RFC7959] recommends the use of CON responses to handle potential 147 packet loss. However, such a recommendation does not work with a 148 flooded pipe DDoS situation (e.g., [RFC8782]). 150 This document introduces the CoAP Q-Block1 and Q-Block2 Options which 151 allow block-wise transfer to work with series of Non-confirmable 152 messages, instead of lock-stepping using Confirmable messages 153 (Section 3). In other words, this document provides a missing piece 154 of [RFC7959], namely the support of block-wise transfer using Non- 155 confirmable where an entire body of data can be transmitted without 156 the requirement that intermediate acknowledgments be received from 157 the peer (but recovery is available should it be needed). 159 Similar to [RFC7959], this specification does not remove any of the 160 constraints posed by the base CoAP specification [RFC7252] it is 161 strictly layered on top of. 163 2. Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in BCP 168 14 [RFC2119][RFC8174] when, and only when, they appear in all 169 capitals, as shown here. 171 Readers should be familiar with the terms and concepts defined in 172 [RFC7252], [RFC7959], and [RFC8132]. Particularly, the document uses 173 the following key concepts: 175 Token: is used to match responses to requests independently from the 176 underlying messages (Section 5.3.1 of [RFC7252]). 178 ETag: is used as a resource-local identifier for differentiating 179 between representations of the same resource that vary over time 180 (Section 5.10.6 of [RFC7252]). 182 The terms "payload" and "body" are defined in [RFC7959]. The term 183 "payload" is thus used for the content of a single CoAP message 184 (i.e., a single block being transferred), while the term "body" is 185 used for the entire resource representation that is being transferred 186 in a block-wise fashion. 188 Request-Tag refers to an option that allows a CoAP server to match 189 message fragments belonging to the same request 190 [I-D.ietf-core-echo-request-tag]. 192 MAX_PAYLOADS is the maximum number of payloads that can be 193 transmitted at any one time. 195 MAX_PAYLOADS_SET is the set of blocks identified by block numbers 196 that, when divided by MAX_PAYLOADS, have the same numeric result. 197 For example, if MAX_PAYLOADS is set to '10', a MAX_PAYLOADS_SET could 198 be blocks #0 to #9, #10 to #19, etc. Depending on the overall data 199 size, there could be fewer than MAX_PAYLOADS blocks in the final 200 MAX_PAYLOADS_SET. 202 3. Alternative CoAP Block-Wise Transfer Options 204 This document introduces the CoAP Q-Block1 and Q-Block2 Options. 205 These options are designed to work in particular with NON requests 206 and responses. 208 Using NON messages, faster transmissions can occur as all the blocks 209 can be transmitted serially (akin to fragmented IP packets) without 210 having to wait for a response or next request from the remote CoAP 211 peer. Recovery of missing blocks is faster in that multiple missing 212 blocks can be requested in a single CoAP message. Even if there is 213 asymmetrical packet loss, a body can still be sent and received by 214 the peer whether the body comprises a single or multiple payloads, 215 assuming no recovery is required. 217 A CoAP endpoint can acknowledge all or a subset of the blocks. 218 Concretely, the receiving CoAP endpoint either informs the CoAP 219 sender endpoint of successful reception or reports on all blocks in 220 the body that have not yet been received. The CoAP sender endpoint 221 will then retransmit only the blocks that have been lost in 222 transmission. 224 Note that similar transmission rate benefits can be applied to 225 Confirmable messages if the value of NSTART is increased from 1 226 (Section 4.7 of [RFC7252]). However, the use of Confirmable messages 227 will not work effectively if there is asymmetrical packet loss. Some 228 examples with Confirmable messages are provided in Appendix A. 230 There is little, if any, benefit of using these options with CoAP 231 running over a reliable connection [RFC8323]. In this case, there is 232 no differentiation between CON and NON as they are not used. Some 233 examples using a reliable transport are provided in Appendix B. 235 Q-Block1 and Q-Block2 Options are similar in operation to the CoAP 236 Block1 and Block2 Options, respectively. They are not a replacement 237 for them, but have the following benefits: 239 o They can operate in environments where packet loss is highly 240 asymmetrical. 242 o They enable faster transmissions of sets of blocks of data with 243 fewer packet interchanges. 245 o They support faster recovery should any of the blocks get lost in 246 transmission. 248 o They support sending an entire body using NON messages without 249 requiring that an intermediate response be received from the peer. 251 There are the following disadvantages over using CoAP Block1 and 252 Block2 Options: 254 o Loss of lock-stepping so payloads are not always received in the 255 correct (block ascending) order. 257 o Additional congestion control measures need to be put in place for 258 NON messages (Section 7.2). 260 o To reduce the transmission times for CON transmission of large 261 bodies, NSTART needs to be increased from 1, but this affects 262 congestion control and incurs a requirement to re-tune other 263 parameters (Section 4.7 of [RFC7252]). Such tuning is out of 264 scope of this document. 266 o Mixing of NON and CON during requests/responses using Q-Block is 267 not supported. 269 o The Q-Block Options do not support stateless operation/random 270 access. 272 o Proxying of Q-Block is limited to caching full representations. 274 o There is no multicast support. 276 Q-Block1 and Q-Block2 Options can be used instead of Block1 and 277 Block2 Options when the different transmission properties are 278 required. If the new options are not supported by a peer, then 279 transmissions can fall back to using Block1 and Block2 Options 280 (Section 4.1). 282 The deviations from Block1 and Block2 Options are specified in 283 Section 4. Pointers to appropriate [RFC7959] sections are provided. 285 The specification refers to the base CoAP methods defined in 286 Section 5.8 of [RFC7252] and the new CoAP methods, FETCH, PATCH, and 287 iPATCH introduced in [RFC8132]. 289 The No-Response Option [RFC7967] was considered but was abandoned as 290 it does not apply to Q-Block2 responses. A unified solution is 291 defined in the document. 293 3.1. CoAP Response Code (4.08) Usage 295 This document adds a media type for the 4.08 (Request Entity 296 Incomplete) response defining an additional message format for 297 reporting on payloads using the Q-Block1 Option that are not received 298 by the server. 300 See Section 5 for more details. 302 3.2. Applicability Scope 304 The block-wise transfer specified in [RFC7959] covers the general 305 case using Confirmable messages, but falls short in situations where 306 packet loss is highly asymmetrical or there is no need for an 307 acknowledgement. In other words, there is a need for Non-confirmable 308 support. 310 The mechanism specified in this document provides roughly similar 311 features to the Block1/Block2 Options. It provides additional 312 properties that are tailored towards the intended use case of Non- 313 confirmable transmission. Concretely, this mechanism primarily 314 targets applications such as DDoS Open Threat Signaling (DOTS) that 315 cannot use CON requests/responses because of potential packet loss 316 and that support application-specific mechanisms to assess whether 317 the remote peer is not overloaded and thus is able to process the 318 messages sent by a CoAP endpoint (e.g., DOTS heartbeats in 319 Section 4.7 of [RFC8782]). Other use cases are when an application 320 sends data but has no need for an acknowledgement of receipt and, any 321 data transmission loss is not critical. 323 The mechanism includes guards to prevent a CoAP agent from 324 overloading the network by adopting an aggressive sending rate. 325 These guards MUST be followed in addition to the existing CoAP 326 congestion control as specified in Section 4.7 of [RFC7252]. See 327 Section 7 for more details. 329 Any usage outside the primary use case of Non-confirmable with block 330 transfers should be carefully weighed against the potential loss of 331 interoperability with generic CoAP applications (See the 332 disadvantages listed in Section 3). It is hoped that the experience 333 gained with this mechanism can feed future extensions of the block- 334 wise mechanism that will both be generally applicable and serve this 335 particular use case. 337 It is not recommended that these options are used in a NoSec security 338 mode (Section 9 of [RFC7252]) as the source endpoint needs to be 339 trusted. Using OSCORE [RFC8613] does provide a security context and, 340 hence, a trust of the source endpoint that prepared the inner OSCORE 341 content. However, even with OSCORE, using a NoSec security mode with 342 these options may still be inadequate, for reasons discussed in 343 Section 11. 345 4. The Q-Block1 and Q-Block2 Options 347 4.1. Properties of Q-Block1 and Q-Block2 Options 349 The properties of the Q-Block1 and Q-Block2 Options are shown in 350 Table 1. The formatting of this table follows the one used in 351 Table 4 of [RFC7252] (Section 5.10). The C, U, N, and R columns 352 indicate the properties Critical, UnSafe, NoCacheKey, and Repeatable 353 defined in Section 5.4 of [RFC7252]. Only Critical and UnSafe 354 columns are marked for the Q-Block1 Option. Critical, UnSafe, and 355 Repeatable columns are marked for the Q-Block2 Option. As these 356 options are UnSafe, NoCacheKey has no meaning and so is marked with a 357 dash. 359 +--------+---+---+---+---+--------------+--------+--------+---------+ 360 | Number | C | U | N | R | Name | Format | Length | Default | 361 +========+===+===+===+===+==============+========+========+=========+ 362 | TBA1 | x | x | - | | Q-Block1 | uint | 0-3 | (none) | 363 | TBA2 | x | x | - | x | Q-Block2 | uint | 0-3 | (none) | 364 +--------+---+---+---+---+--------------+--------+--------+---------+ 366 Table 1: CoAP Q-Block1 and Q-Block2 Option Properties 368 The Q-Block1 and Q-Block2 Options can be present in both the request 369 and response messages. The Q-Block1 Option pertains to the request 370 payload and the Q-Block2 Option pertains to the response payload. 371 When the Content-Format Option is present together with the Q-Block1 372 or Q-Block2 Option, the option applies to the body not to the payload 373 (i.e., it must be the same for all payloads of the same body). 375 The Q-Block1 Option is useful with the payload-bearing, e.g., POST, 376 PUT, FETCH, PATCH, and iPATCH requests and their responses. 378 The Q-Block2 Option is useful, e.g., with GET, POST, PUT, FETCH, 379 PATCH, and iPATCH requests and their payload-bearing responses 380 (response codes 2.01, 2.02, 2.04, and 2.05) (Section 5.5 of 381 [RFC7252]). 383 A CoAP endpoint (or proxy) MUST support either both or neither of the 384 Q-Block1 and Q-Block2 Options. 386 If the Q-Block1 Option is present in a request or the Q-Block2 Option 387 is returned in a response, this indicates a block-wise transfer and 388 describes how this specific block-wise payload forms part of the 389 entire body being transferred. If it is present in the opposite 390 direction, it provides additional control on how that payload will be 391 formed or was processed. 393 To indicate support for Q-Block2 responses, the CoAP client MUST 394 include the Q-Block2 Option in a GET or similar request (FETCH, for 395 example), the Q-Block2 Option in a PUT or similar request (POST, for 396 example), or the Q-Block1 Option in a PUT or similar request so that 397 the server knows that the client supports this Q-Block functionality 398 should it need to send back a body that spans multiple payloads. 399 Otherwise, the server would use the Block2 Option (if supported) to 400 send back a message body that is too large to fit into a single IP 401 packet [RFC7959]. 403 How a client decides whether it needs to include a Q-Block1 or 404 Q-Block2 Option can be driven by a local configuration parameter, 405 triggered by an application (DOTS, for example), etc. Such 406 considerations are out of the scope of the document. 408 Implementation of the Q-Block1 and Q-Block2 Options is intended to be 409 optional. However, when it is present in a CoAP message, it MUST be 410 processed (or the message rejected). Therefore, Q-Block1 and 411 Q-Block2 Options are identified as Critical options. 413 With CoAP over UDP, the way a request message is rejected for 414 critical options depends on the message type. A Confirmable message 415 with an unrecognized critical option is rejected with a 4.02 (Bad 416 Option) response (Section 5.4.1 of [RFC7252]). A Non-confirmable 417 message with an unrecognized critical option is either rejected with 418 a Reset message or just silently ignored (Sections 5.4.1 and 4.3 of 419 [RFC7252]). To reliably get a rejection message, it is therefore 420 REQUIRED that clients use a Confirmable message for determining 421 support for Q-Block1 and Q-Block2 Options. This CON message can be 422 sent under the base CoAP congestion control setup specified in 423 Section 4.7 of [RFC7252] (that is, NSTART does not need to be 424 increased (Section 7.1)). 426 The Q-Block1 and Q-Block2 Options are unsafe to forward. That is, a 427 CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option 428 must reject the request or response that uses either option (See 429 Section 5.7.1 of [RFC7252]). 431 The Q-Block2 Option is repeatable when requesting retransmission of 432 missing blocks, but not otherwise. Except that case, any request 433 carrying multiple Q-Block1 (or Q-Block2) Options MUST be handled 434 following the procedure specified in Section 5.4.5 of [RFC7252]. 436 The Q-Block1 and Q-Block2 Options, like the Block1 and Block2 437 Options, are of both class E and class U for OSCORE processing 438 (Table 2). The Q-Block1 (or Q-Block2) Option MAY be an Inner or 439 Outer option (Section 4.1 of [RFC8613]). The Inner and Outer values 440 are therefore independent of each other. The Inner option is 441 encrypted and integrity protected between clients and servers, and 442 provides message body identification in case of end-to-end 443 fragmentation of requests. The Outer option is visible to proxies 444 and labels message bodies in case of hop-by-hop fragmentation of 445 requests. 447 +--------+-----------------+---+---+ 448 | Number | Name | E | U | 449 +========+=================+===+===+ 450 | TBA1 | Q-Block1 | x | x | 451 | TBA2 | Q-Block2 | x | x | 452 +--------+-----------------+---+---+ 453 Table 2: OSCORE Protection of Q-Block1 and Q-Block2 Options 455 Note that if Q-Block1 or Q-Block2 Options are included in a packet as 456 Inner options, Block1 or Block2 Options MUST NOT be included as Inner 457 options. Similarly, there MUST NOT be a mix of Q-Block and Block for 458 the Outer options. Messages that do not adhere with this behavior 459 MUST be rejected with 4.02 (Bad Option). Q-Block and Block Options 460 can be mixed across Inner and Outer options as these are handled 461 independently of each other. For clarity, if OSCORE is not being 462 used, there MUST NOT be a mix of Q-Block and Block Options in the 463 same packet. 465 4.2. Structure of Q-Block1 and Q-Block2 Options 467 The structure of Q-Block1 and Q-Block2 Options follows the structure 468 defined in Section 2.2 of [RFC7959]. 470 There is no default value for the Q-Block1 and Q-Block2 Options. 471 Absence of one of these options is equivalent to an option value of 0 472 with respect to the value of block number (NUM) and more bit (M) that 473 could be given in the option, i.e., it indicates that the current 474 block is the first and only block of the transfer (block number is 475 set to 0, M is unset). However, in contrast to the explicit value 0, 476 which would indicate a size of the block (SZX) of 0, and thus a size 477 value of 16 bytes, there is no specific explicit size implied by the 478 absence of the option -- the size is left unspecified. (As for any 479 uint, the explicit value 0 is efficiently indicated by a zero-length 480 option; this, therefore, is different in semantics from the absence 481 of the option). 483 4.3. Using the Q-Block1 Option 485 The Q-Block1 Option is used when the client wants to send a large 486 amount of data to the server using the POST, PUT, FETCH, PATCH, or 487 iPATCH methods where the data and headers do not fit into a single 488 packet. 490 When Q-Block1 Option is used, the client MUST include a Request-Tag 491 Option [I-D.ietf-core-echo-request-tag]. The Request-Tag value MUST 492 be the same for all of the requests for the body of data that is 493 being transferred. The Request-Tag is opaque, but the client MUST 494 ensure that it is unique for every different body of transmitted 495 data. 497 Implementation Note: It is suggested that the client treats the 498 Request-Tag as an unsigned integer of 8 bytes in length. An 499 implementation may want to consider limiting this to 4 bytes to 500 reduce packet overhead size. The initial Request-Tag value should 501 be randomly generated and then subsequently incremented by the 502 client whenever a new body of data is being transmitted between 503 peers. 505 Section 4.6 discusses the use of Size1 Option. 507 For Confirmable transmission, the server continues to acknowledge 508 each packet, but a response is not required (whether separate or 509 piggybacked) until successful receipt of the body by the server. For 510 Non-confirmable transmission, no response is required until either 511 the successful receipt of the body by the server or a timer expires 512 with some of the payloads having not yet arrived. In the latter 513 case, a "retransmit missing payloads" response is needed. For 514 reliable transports (e.g., [RFC8323]), a response is not required 515 until successful receipt of the body by the server. 517 Each individual message that carries a block of the body is treated 518 as a new request (Section 6). 520 The client MUST send the payloads in order of increasing block 521 number, starting from zero, until the body is complete (subject to 522 any congestion control (Section 7)). Any missing payloads requested 523 by the server must in addition be separately transmitted with 524 increasing block numbers. 526 The following Response Codes are used: 528 2.01 (Created) 530 This Response Code indicates successful receipt of the entire body 531 and that the resource was created. The token to use MUST be one 532 of the tokens that were received in a request for this block-wise 533 exchange. However, it is desirable to provide the one used in the 534 last received request, since that will aid any troubleshooting. 535 The client should then release all of the tokens used for this 536 body. Note that the last received payload might not be the one 537 with the highest block number. 539 2.02 (Deleted) 541 This Response Code indicates successful receipt of the entire body 542 and that the resource was deleted when using POST (Section 5.8.2 543 [RFC7252]). The token to use MUST be one of the tokens that were 544 received in a request for this block-wise exchange. However, it 545 is desirable to provide the one used in the last received request. 546 The client should then release all of the tokens used for this 547 body. 549 2.04 (Changed) 551 This Response Code indicates successful receipt of the entire body 552 and that the resource was updated. The token to use MUST be one 553 of the tokens that were received in a request for this block-wise 554 exchange. However, it is desirable to provide the one used in the 555 last received request. The client should then release all of the 556 tokens used for this body. 558 2.05 (Content) 560 This Response Code indicates successful receipt of the entire 561 FETCH request body (Section 2 of [RFC8132]) and that the 562 appropriate representation of the resource is being returned. The 563 token to use MUST be one of the tokens that were received in a 564 request for this block-wise exchange. However, it is desirable to 565 provide the one used in the last received request. 567 If the FETCH request includes the Observe Option, then the server 568 MUST use the same token as used for the 2.05 (Content) response 569 for returning any Observe triggered responses so that the client 570 can match them up. 572 The client should then release all of the tokens used for this 573 body apart from the one used for tracking an observed resource. 575 2.31 (Continue) 576 This Response Code can be used to indicate that all of the blocks 577 up to and including the Q-Block1 Option block NUM (all having the 578 M bit set) have been successfully received. The token to use MUST 579 be one of the tokens that were received in a request for this 580 latest MAX_PAYLOADS_SET block-wise exchange. However, it is 581 desirable to provide the one used in the last received request. 583 The client should then release all of the tokens used for this 584 MAX_PAYLOADS_SET. 586 A response using this Response Code MUST NOT be generated for 587 every received Q-Block1 Option request. It SHOULD only be 588 generated when all the payload requests are Non-confirmable and a 589 MAX_PAYLOADS_SET has been received by the server. More details 590 about the motivations for this optimization are discussed in 591 Section 7.2. 593 This Response Code SHOULD NOT be generated for CON as this may 594 cause duplicated payloads to unnecessarily be sent. 596 4.00 (Bad Request) 598 This Response Code MUST be returned if the request does not 599 include a Request-Tag Option or a Size1 Option but does include a 600 Q-Block1 option. 602 4.02 (Bad Option) 604 This Response Code MUST be returned for a Confirmable request if 605 the server does not support the Q-Block Options. Note that a 606 reset message may be sent in case of Non-confirmable request. 608 4.08 (Request Entity Incomplete) 610 As a reminder, this Response Code returned without Content-Type 611 "application/missing-blocks+cbor-seq" (Section 12.3) is handled as 612 in Section 2.9.2 [RFC7959]. 614 This Response Code returned with Content-Type "application/ 615 missing-blocks+cbor-seq" indicates that some of the payloads are 616 missing and need to be resent. The client then retransmits the 617 individual missing payloads using the same Request-Tag, Size1, 618 and, Q-Block1 Option to specify the same NUM, SZX, and M bit as 619 sent initially in the original, but not received, packet. 621 The Request-Tag value to use is determined by taking the token in 622 the 4.08 (Request Entity Incomplete) response, locating the 623 matching client request, and then using its Request-Tag. 625 The token to use in the 4.08 (Request Entity Incomplete) response 626 MUST be one of the tokens that were received in a request for this 627 block-wise body exchange. However, it is desirable to provide the 628 one used in the last received request. See Section 5 for further 629 information. 631 If the server has not received all the blocks of a body, but one 632 or more NON payloads have been received, it SHOULD wait for 633 NON_RECEIVE_TIMEOUT (Section 7.2) before sending a 4.08 (Request 634 Entity Incomplete) response. 636 4.13 (Request Entity Too Large) 638 This Response Code can be returned under similar conditions to 639 those discussed in Section 2.9.3 of [RFC7959]. 641 This Response Code can be returned if there is insufficient space 642 to create a response PDU with a block size of 16 bytes (SZX = 0) 643 to send back all the response options as appropriate. In this 644 case, the Size1 Option is not included in the response. 646 Further considerations related to the transmission timings of 4.08 647 (Request Entity Incomplete) and 2.31 (Continue) Response Codes are 648 discussed in Section 7.2. 650 If a server receives payloads with different Request-Tags for the 651 same resource, it should continue to process all the bodies as it has 652 no way of determining which is the latest version, or which body, if 653 any, the client is terminating the transmission for. 655 If the client elects to stop the transmission of a complete body, and 656 absent any local policy, the client MUST "forget" all tracked tokens 657 associated with the body's Request-Tag so that a reset message is 658 generated for the invalid token in the 4.08 (Request Entity 659 Incomplete) response. The server on receipt of the reset message 660 SHOULD delete the partial body. 662 If the server receives a duplicate block with the same Request-Tag, 663 it MUST ignore the payload of the packet, but MUST still respond as 664 if the block was received for the first time. 666 A server SHOULD maintain a partial body (missing payloads) for 667 NON_PARTIAL_TIMEOUT (Section 7.2). 669 4.4. Using the Q-Block2 Option 671 In a request for any block number, the M bit unset indicates the 672 request is just for that block. If the M bit is set, this has 673 different meanings based on the NUM value: 675 NUM is zero: This is a request for the entire body. 677 'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero: This is 678 used to confirm that the current MAX_PAYLOADS_SET (the latest 679 block having block number NUM-1) has been successfully received 680 and that, upon receipt of this request, the server can continue to 681 send the next MAX_PAYLOADS_SET (the first block having block 682 number NUM). This is the 'Continue' Q-Block-2 and conceptually 683 has the same usage (i.e., continue sending the next set of data) 684 as the use of 2.31 (Continue) for Q-Block1. 686 Any other value of NUM: This is a request for that block and for all 687 of the remaining blocks in the current MAX_PAYLOADS_SET. 689 If the request includes multiple Q-Block2 Options and these options 690 overlap (e.g., combination of M being set (this and later blocks) and 691 being unset (this individual block)) resulting in an individual block 692 being requested multiple times, the server MUST only send back one 693 instance of that block. This behavior is meant to prevent 694 amplification attacks. 696 The payloads sent back from the server as a response MUST all have 697 the same ETag (Section 5.10.6 of [RFC7252]) for the same body. The 698 server MUST NOT use the same ETag value for different representations 699 of a resource. 701 The ETag is opaque, but the server MUST ensure that it is unique for 702 every different body of transmitted data. 704 Implementation Note: It is suggested that the server treats the 705 ETag as an unsigned integer of 8 bytes in length. An 706 implementation may want to consider limiting this to 4 bytes to 707 reduce packet overhead size. The initial ETag value should be 708 randomly generated and then subsequently incremented by the server 709 whenever a new body of data is being transmitted between peers. 711 Section 4.6 discusses the use of Size2 Option. 713 The client may elect to request any detected missing blocks or just 714 ignore the partial body. This decision is implementation specific. 716 For NON payloads, the client SHOULD wait NON_RECEIVE_TIMEOUT 717 (Section 7.2) after the last received payload before requesting 718 retransmission of any missing blocks. Retransmission is requested by 719 issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request that 720 contains one or more Q-Block2 Options that define the missing 721 block(s). Generally the M bit on the Q-Block2 Option(s) SHOULD be 722 unset, although the M bit MAY be set to request this and later blocks 723 from this MAX_PAYLOADS_SET, see Section 10.2.4 for an example of this 724 in operation. Further considerations related to the transmission 725 timing for missing requests are discussed in Section 7.2. 727 The missing block numbers requested by the client MUST have an 728 increasing block number in each additional Q-Block2 Option with no 729 duplicates. The server SHOULD respond with a 4.00 (Bad Request) to 730 requests not adhering to this behavior. Note that the ordering 731 constraint is meant to force the client to check for duplicates and 732 remove them. This also helps with troubleshooting. 734 If the client receives a duplicate block with the same ETag, it MUST 735 silently ignore the payload. 737 A client SHOULD maintain a partial body (missing payloads) for 738 NON_PARTIAL_TIMEOUT (Section 7.2) or as defined by the Max-Age Option 739 (or its default of 60 seconds (Section 5.6.1 of [RFC7252])), 740 whichever is the less. On release of the partial body, the client 741 should then release all of the tokens used for this body apart from 742 the token that is used to track a resource that is being observed. 744 The ETag Option should not be used in the request for missing blocks 745 as the server could respond with a 2.03 (Valid) response with no 746 payload. It can be used in the request if the client wants to check 747 the freshness of the locally cached body response. 749 The server SHOULD maintain a cached copy of the body when using the 750 Q-Block2 Option to facilitate retransmission of any missing payloads. 752 If the server detects part way through a body transfer that the 753 resource data has changed and the server is not maintaining a cached 754 copy of the old data, then the transmission is terminated. Any 755 subsequent missing block requests MUST be responded to using the 756 latest ETag and Size2 Option values with the updated data. 758 If the server responds during a body update with a different ETag 759 Option value (as the resource representation has changed), then the 760 client should treat the partial body with the old ETag as no longer 761 being fresh. The client may then request all of the new data by 762 specifying Q-Block2 with block number '0' and the M bit set. 764 If the server transmits a new body of data (e.g., a triggered Observe 765 notification) with a new ETag to the same client as an additional 766 response, the client should remove any partially received body held 767 for a previous ETag for that resource as it is unlikely the missing 768 blocks can be retrieved. 770 If there is insufficient space to create a response PDU with a block 771 size of 16 bytes (SZX = 0) to send back all the response options as 772 appropriate, a 4.13 (Request Entity Too Large) is returned without 773 the Size1 Option. 775 For Confirmable traffic, the server typically acknowledges the 776 initial request using an ACK with a piggybacked payload, and then 777 sends the subsequent payloads of the MAX_PAYLOADS_SET as CON 778 responses. These CON responses are individually ACKed by the client. 779 The server will detect failure to send a packet and SHOULD terminate 780 the body transfer, but the client can issue, after a 781 MAX_TRANSMIT_SPAN delay, a separate GET, POST, PUT, FETCH, PATCH, or 782 iPATCH for any missing blocks as needed. 784 4.5. Using Observe Option 786 For a request that uses Q-Block1, the Observe value [RFC7641] MUST be 787 the same for all the payloads of the same body. This includes any 788 missing payloads that are retransmitted. 790 For a response that uses Q-Block2, the Observe value MUST be the same 791 for all the payloads of the same body. This is different from Block2 792 usage where the Observe value is only present in the first block 793 (Section 3.4 of [RFC7959]). This includes payloads transmitted 794 following receipt of the 'Continue' Q-Block2 Option (Section 4.4) by 795 the server. If a missing payload is requested by a client, then both 796 the request and response MUST NOT include the Observe Option. 798 4.6. Using Size1 and Size2 Options 800 Section 4 of [RFC7959] defines two CoAP options: Size1 for indicating 801 the size of the representation transferred in requests and Size2 for 802 indicating the size of the representation transferred in responses. 804 For Q-Block1 and Q-Block2 Options, the Size1 or Size2 Option values 805 MUST exactly represent the size of the data on the body so that any 806 missing data can easily be determined. 808 The Size1 Option MUST be used with the Q-Block1 Option when used in a 809 request and MUST be present in all payloads of the request, 810 preserving the same value. The Size2 Option MUST be used with the 811 Q-Block2 Option when used in a response and MUST be present in all 812 payloads of the response, preserving the same value. 814 4.7. Using Q-Block1 and Q-Block2 Options Together 816 The behavior is similar to the one defined in Section 3.3 of 817 [RFC7959] with Q-Block1 substituted for Block1 and Q-Block2 for 818 Block2. 820 4.8. Using Q-Block2 Option With Multicast 822 Servers MUST ignore multicast requests that contain the Q-Block2 823 Option. As a reminder, Block2 Option can be used as stated in 824 Section 2.8 of [RFC7959]. 826 5. The Use of 4.08 (Request Entity Incomplete) Response Code 828 4.08 (Request Entity Incomplete) Response Code has a new Content-Type 829 "application/missing-blocks+cbor-seq" used to indicate that the 830 server has not received all of the blocks of the request body that it 831 needs to proceed. Such messages must not be treated by the client as 832 a fatal error. 834 Likely causes are the client has not sent all blocks, some blocks 835 were dropped during transmission, or the client has sent them 836 sufficiently long ago that the server has already discarded them. 838 The new data payload of the 4.08 (Request Entity Incomplete) response 839 with Content-Type set to "application/missing-blocks+cbor-seq" is 840 encoded as a CBOR Sequence [RFC8742]. It comprises one or more 841 missing block numbers encoded as CBOR unsigned integers [RFC8949]. 842 The missing block numbers MUST be unique in each 4.08 (Request Entity 843 Incomplete) response when created by the server; the client MUST 844 ignore any duplicates in the same 4.08 (Request Entity Incomplete) 845 response. 847 The Content-Format Option (Section 5.10.3 of [RFC7252]) MUST be used 848 in the 4.08 (Request Entity Incomplete) response. It MUST be set to 849 "application/missing-blocks+cbor-seq" (Section 12.3). 851 The Concise Data Definition Language [RFC8610] (and see Section 4.1 852 [RFC8742]) for the data describing these missing blocks is as 853 follows: 855 ; This defines an array, the elements of which are to be used 856 ; in a CBOR Sequence: 857 payload = [+ missing-block-number] 858 ; A unique block number not received: 859 missing-block-number = uint 861 Figure 1: Structure of the Missing Blocks Payload 863 This CDDL syntax MUST be followed. 865 It is desirable that the token to use for the response is the token 866 that was used in the last block number received so far with the same 867 Request-Tag value. Note that the use of any received token with the 868 same Request-Tag would be acceptable, but providing the one used in 869 the last received payload will aid any troubleshooting. The client 870 will use the token to determine what was the previously sent request 871 to obtain the Request-Tag value that was used. 873 If the size of the 4.08 (Request Entity Incomplete) response packet 874 is larger than that defined by Section 4.6 [RFC7252], then the number 875 of reported missing blocks MUST be limited so that the response can 876 fit into a single packet. If this is the case, then the server can 877 send subsequent 4.08 (Request Entity Incomplete) responses containing 878 the missing other blocks on receipt of a new request providing a 879 missing payload with the same Request-Tag. 881 The missing blocks MUST be reported in ascending order without any 882 duplicates. The client SHOULD silently drop 4.08 (Request Entity 883 Incomplete) responses not adhering with this behavior. 885 Implementation Note: Consider limiting the number of missing 886 payloads to MAX_PAYLOADS to minimize congestion control being 887 needed. The CBOR sequence does not include any array wrapper. 889 The 4.08 (Request Entity Incomplete) with Content-Type "application/ 890 missing-blocks+cbor-seq" SHOULD NOT be used when using Confirmable 891 requests or a reliable connection [RFC8323] as the client will be 892 able to determine that there is a transmission failure of a 893 particular payload and hence that the server is missing that payload. 895 6. The Use of Tokens 897 Each new request generally uses a new Token (and sometimes must, see 898 Section 4 of [I-D.ietf-core-echo-request-tag]). Additional responses 899 to a request all use the token of the request they respond to. 901 Implementation Note: By using 8-byte tokens, it is possible to 902 easily minimize the number of tokens that have to be tracked by 903 clients, by keeping the bottom 32 bits the same for the same body 904 and the upper 32 bits containing the current body's request number 905 (incrementing every request, including every re-transmit). This 906 allows the client to be alleviated from keeping all the per- 907 request-state, e.g., in Section 3 of [RFC8974]. However, if using 908 NoSec, Section 5.2 of [RFC8974] needs to be considered for 909 security implications. 911 7. Congestion Control for Unreliable Transports 913 The transmission of all the blocks of a single body over an 914 unreliable transport MUST either all be Confirmable or all be Non- 915 confirmable. This is meant to simplify the congestion control 916 procedure. 918 As a reminder, there is no need for CoAP-specific congestion control 919 for reliable transports [RFC8323]. 921 7.1. Confirmable (CON) 923 Congestion control for CON requests and responses is specified in 924 Section 4.7 of [RFC7252]. In order to benefit from faster 925 transmission rates, NSTART will need to be increased from 1. 926 However, the other CON congestion control parameters will need to be 927 tuned to cover this change. This tuning is not specified in this 928 document, given that the applicability scope of the current 929 specification assumes that all requests and responses using Q-Block1 930 and Q-Block2 will be Non-confirmable (Section 3.2) apart from the 931 initial Q-Block functionality negotiation. 933 Following the failure to transmit a packet due to packet loss after 934 MAX_TRANSMIT_SPAN time (Section 4.8.2 of [RFC7252]), it is 935 implementation specific as to whether there should be any further 936 requests for missing data. 938 7.2. Non-confirmable (NON) 940 This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT, 941 NON_TIMEOUT_RANDOM, NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, 942 NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT primarily for use with NON 943 (Table 3). 945 Note: Randomness may naturally be provided based on the traffic 946 profile, how PROBING_RATE is computed (as this is an average), and 947 when the peer responds. Randomness is explicitly added for some 948 of the congestion control parameters to handle situations where 949 every thing is in sync when retrying. 951 MAX_PAYLOADS should be configurable with a default value of 10. Both 952 CoAP endpoints MUST have the same value (otherwise there will be 953 transmission delays in one direction) and the value MAY be negotiated 954 between the endpoints to a common value by using a higher level 955 protocol (out of scope of this document). This is the maximum number 956 of payloads that can be transmitted at any one time. 958 Note: The default value of 10 is chosen for reasons similar to 959 those discussed in Section 5 of [RFC6928], especially given the 960 target application discussed in Section 3.2. 962 NON_TIMEOUT is used to compute the delay between sending 963 MAX_PAYLOADS_SET for the same body. By default, NON_TIMEOUT has the 964 same value as ACK_TIMEOUT (Section 4.8 of [RFC7252]). 966 NON_TIMEOUT_RANDOM is the initial actual delay between sending the 967 first two MAX_PAYLOADS_SETs of the same body. The same delay is then 968 used between the subsequent MAX_PAYLOADS_SETs. It is a random 969 duration (not an integral number of seconds) between NON_TIMEOUT and 970 (NON_TIMEOUT * ACK_RANDOM_FACTOR). ACK_RANDOM_FACTOR is set to 1.5 971 as discussed in Section 4.8 of [RFC7252]. 973 NON_RECEIVE_TIMEOUT is the initial time to wait for a missing payload 974 before requesting retransmission for the first time. Every time the 975 missing payload is re-requested, the time to wait value doubles. The 976 time to wait is calculated as: 978 Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count - 1)) 980 NON_RECEIVE_TIMEOUT has a default value of twice NON_TIMEOUT. 981 NON_RECEIVE_TIMEOUT MUST always be greater than NON_TIMEOUT_RANDOM by 982 at least one second so that the sender of the payloads has the 983 opportunity to start sending the next MAX_PAYLOADS_SET before the 984 receiver times out. 986 NON_MAX_RETRANSMIT is the maximum number of times a request for the 987 retransmission of missing payloads can occur without a response from 988 the remote peer. After this occurs, the local endpoint SHOULD 989 consider the body stale, remove any body, and release Tokens and 990 Request-Tag on the client (or the ETag on the server). By default, 991 NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT (Section 4.8 992 of [RFC7252]). 994 NON_PROBING_WAIT is used to limit the potential wait needed when 995 using PROBING_RATE. By default, NON_PROBING_WAIT is computed in a 996 similar way as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) but 997 with ACK_TIMEOUT, MAX_RETRANSMIT, and PROCESSING_DELAY substituted 998 with NON_TIMEOUT, NON_MAX_RETRANSMIT, and NON_TIMEOUT_RANDOM, 999 respectively: 1001 NON_PROBING_WAIT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - 1) * 1002 ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT_RANDOM 1004 NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. 1005 By default, NON_PARTIAL_TIMEOUT is computed in the same way as 1006 EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) but with ACK_TIMEOUT 1007 and MAX_RETRANSMIT substituted with NON_TIMEOUT and 1008 NON_MAX_RETRANSMIT, respectively: 1010 NON_PARTIAL_TIMEOUT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - 1011 1) * ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT 1013 +---------------------+-------------------+ 1014 | Parameter Name | Default Value | 1015 +=====================+===================+ 1016 | MAX_PAYLOADS | 10 | 1017 | NON_MAX_RETRANSMIT | 4 | 1018 | NON_TIMEOUT | 2 s | 1019 | NON_TIMEOUT_RANDOM | between 2-3 s | 1020 | NON_RECEIVE_TIMEOUT | 4 s | 1021 | NON_PROBING_WAIT | between 247-248 s | 1022 | NON_PARTIAL_TIMEOUT | 247 s | 1023 +---------------------+-------------------+ 1025 Table 3: Congestion Control Parameters 1027 The PROBING_RATE parameter in CoAP indicates the average data rate 1028 that must not be exceeded by a CoAP endpoint in sending to a peer 1029 endpoint that does not respond. A single body will be subjected to 1030 PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets. 1031 If the wait time between sending bodies that are not being responded 1032 to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time 1033 is limited to NON_PROBING_WAIT. 1035 Note: For the particular DOTS application, PROBING_RATE and other 1036 transmission parameters are negotiated between peers. Even when 1037 not negotiated, the DOTS application uses customized defaults as 1038 discussed in Section 4.5.2 of [RFC8782]. Note that MAX_PAYLOADS, 1039 NON_MAX_RETRANSMIT, NON_TIMEOUT, NON_PROBING_WAIT, and 1040 NON_PARTIAL_TIMEOUT can be negotiated between DOTS peers, e.g., as 1041 per [I-D.bosh-dots-quick-blocks]. When explicit values are 1042 configured for NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT, these 1043 values are used without applying any jitter. 1045 Each NON 4.08 (Request Entity Incomplete) response is subject to 1046 PROBING_RATE. 1048 Each NON GET or FETCH request using a Q-Block2 Option is subject to 1049 PROBING_RATE. 1051 As the sending of many payloads of a single body may itself cause 1052 congestion, after transmission of every MAX_PAYLOADS_SET of a single 1053 body, a delay MUST be introduced of NON_TIMEOUT_RANDOM before sending 1054 the next MAX_PAYLOADS_SET unless a 'Continue' is received from the 1055 peer for the current MAX_PAYLOADS_SET, in which case the next 1056 MAX_PAYLOADS_SET MAY start transmission immediately. 1058 Note: Assuming 1500-byte packets and the MAX_PAYLOADS_SET having 1059 10 payloads, this corresponds to 1500 * 10 * 8 = 120 Kbits. With 1060 a delay of 2 seconds between MAX_PAYLOADS_SET, this indicates an 1061 average speed requirement of 60 Kbps for a single body should 1062 there be no responses. This transmission rate is further reduced 1063 by being subject to PROBING_RATE. 1065 The sending of a set of missing blocks of a body is restricted to 1066 those in a MAX_PAYLOADS_SET at a time. In other words, a 1067 NON_TIMEOUT_RANDOM delay is still observed between each 1068 MAX_PAYLOAD_SET. 1070 For Q-Block1 Option, if the server responds with a 2.31 (Continue) 1071 Response Code for the latest payload sent, then the client can 1072 continue to send the next MAX_PAYLOADS_SET without any further delay. 1073 If the server responds with a 4.08 (Request Entity Incomplete) 1074 Response Code, then the missing payloads SHOULD be retransmitted 1075 before going into another NON_TIMEOUT_RANDOM delay prior to sending 1076 the next set of payloads. 1078 For the server receiving NON Q-Block1 requests, it SHOULD send back a 1079 2.31 (Continue) Response Code on receipt of all of the 1080 MAX_PAYLOADS_SET to prevent the client unnecessarily delaying. If 1081 not all of the MAX_PAYLOADS_SET were received, the server SHOULD 1082 delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the 1083 repeat request count for a payload) before sending the 4.08 (Request 1084 Entity Incomplete) Response Code for the missing payload(s). If all 1085 of the MAX_PAYLOADS_SET were received and a 2.31 (Continue) had been 1086 sent, but no more payloads were received for NON_RECEIVE_TIMEOUT 1087 (exponentially scaled), the server SHOULD send a 4.08 (Request Entity 1088 Incomplete) response detailing the missing payloads after the block 1089 number that was indicated in the sent 2.31 (Continue). If the 1090 repeated response count of the 4.08 (Request Entity Incomplete) 1091 exceeds NON_MAX_RETRANSMIT, the server SHOULD discard the partial 1092 body and stop requesting the missing payloads. 1094 It is likely that the client will start transmitting the next 1095 MAX_PAYLOADS_SET before the server times out on waiting for the last 1096 of the previous MAX_PAYLOADS_SET. On receipt of a payload from the 1097 next MAX_PAYLOADS_SET, the server SHOULD send a 4.08 (Request Entity 1098 Incomplete) Response Code indicating any missing payloads from any 1099 previous MAX_PAYLOADS_SET. Upon receipt of the 4.08 (Request Entity 1100 Incomplete) Response Code, the client SHOULD send the missing 1101 payloads before continuing to send the remainder of the 1102 MAX_PAYLOADS_SET and then go into another NON_TIMEOUT_RANDOM delay 1103 prior to sending the next MAX_PAYLOADS_SET. 1105 For the client receiving NON Q-Block2 responses, it SHOULD send a 1106 'Continue' Q-Block2 request (Section 4.4) for the next 1107 MAX_PAYLOADS_SET on receipt of all of the MAX_PAYLOADS_SET, to 1108 prevent the server unnecessarily delaying. Otherwise the client 1109 SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on 1110 the repeat request count for a payload), before sending the request 1111 for the missing payload(s). If the repeat request count for a 1112 missing payload exceeds NON_MAX_RETRANSMIT, the client SHOULD discard 1113 the partial body and stop requesting the missing payloads. 1115 The server SHOULD recognize the 'Continue' Q-Block2 request as a 1116 continue request and just continue the transmission of the body 1117 (including Observe Option, if appropriate for an unsolicited 1118 response) rather than as a request for the remaining missing blocks. 1120 It is likely that the server will start transmitting the next 1121 MAX_PAYLOADS_SET before the client times out on waiting for the last 1122 of the previous MAX_PAYLOADS_SET. Upon receipt of a payload from the 1123 new MAX_PAYLOADS_SET, the client SHOULD send a request indicating any 1124 missing payloads from any previous MAX_PAYLOADS_SET. Upon receipt of 1125 such request, the server SHOULD send the missing payloads before 1126 continuing to send the remainder of the MAX_PAYLOADS_SET and then go 1127 into another NON_TIMEOUT_RANDOM delay prior to sending the next 1128 MAX_PAYLOADS_SET. 1130 The client does not need to acknowledge the receipt of the entire 1131 body. 1133 Note: If there is asymmetric traffic loss causing responses to 1134 never get received, a delay of NON_TIMEOUT_RANDOM after every 1135 transmission of MAX_PAYLOADS_SET will be observed. The endpoint 1136 receiving the body is still likely to receive the entire body. 1138 8. Caching Considerations 1140 Caching block based information is not straight forward in a proxy. 1141 For Q-Block1 and Q-Block2 Options, for simplicity it is expected that 1142 the proxy will reassemble the body (using any appropriate recovery 1143 options for packet loss) before passing on the body to the 1144 appropriate CoAP endpoint. This does not preclude an implementation 1145 doing a more complex per payload caching, but how to do this is out 1146 of the scope of this document. The onward transmission of the body 1147 does not require the use of the Q-Block1 or Q-Block2 Options as these 1148 options may not be supported in that link. This means that the proxy 1149 must fully support the Q-Block1 and Q-Block2 Options. 1151 How the body is cached in the CoAP client (for Q-Block1 1152 transmissions) or the CoAP server (for Q-Block2 transmissions) is 1153 implementation specific. 1155 As the entire body is being cached in the proxy, the Q-Block1 and 1156 Q-Block2 Options are removed as part of the block assembly and thus 1157 do not reach the cache. 1159 For Q-Block2 responses, the ETag Option value is associated with the 1160 data (and onward transmitted to the CoAP client), but is not part of 1161 the cache key. 1163 For requests with Q-Block1 Option, the Request-Tag Option is 1164 associated with the build up of the body from successive payloads, 1165 but is not part of the cache key. For the onward transmission of the 1166 body using CoAP, a new Request-Tag SHOULD be generated and used. 1167 Ideally this new Request-Tag should replace the client's request 1168 Request-Tag. 1170 It is possible that two or more CoAP clients are concurrently 1171 updating the same resource through a common proxy to the same CoAP 1172 server using Q-Block1 (or Block1) Option. If this is the case, the 1173 first client to complete building the body causes that body to start 1174 transmitting to the CoAP server with an appropriate Request-Tag 1175 value. When the next client completes building the body, any 1176 existing partial body transmission to the CoAP server is terminated 1177 and the new body representation transmission starts with a new 1178 Request-Tag value. Note that it cannot be assumed that the proxy 1179 will always receive a complete body from a client. 1181 A proxy that supports Q-Block2 Option MUST be prepared to receive a 1182 GET or similar request indicating one or more missing blocks. The 1183 proxy will serve from its cache the missing blocks that are available 1184 in its cache in the same way a server would send all the appropriate 1185 Q-Block2 responses. If a body matching the cache key is not 1186 available in the cache, the proxy MUST request the entire body from 1187 the CoAP server using the information in the cache key. 1189 How long a CoAP endpoint (or proxy) keeps the body in its cache is 1190 implementation specific (e.g., it may be based on Max-Age). 1192 9. HTTP-Mapping Considerations 1194 As a reminder, the basic normative requirements on HTTP/CoAP mappings 1195 are defined in Section 10 of [RFC7252]. The implementation 1196 guidelines for HTTP/CoAP mappings are elaborated in [RFC8075]. 1198 The rules defined in Section 5 of [RFC7959] are to be followed. 1200 10. Examples with Non-confirmable Messages 1202 This section provides some sample flows to illustrate the use of 1203 Q-Block1 and Q-Block2 Options with NON. Examples with CON are 1204 provided in Appendix A. 1206 The examples in the following subsections assume MAX_PAYLOADS is set 1207 to 10 and NON_MAX_RETRANSMIT is set to 4. 1209 Figure 2 lists the conventions that are used in the following 1210 subsections. 1212 T: Token value 1213 O: Observe Option value 1214 M: Message ID 1215 RT: Request-Tag 1216 ET: ETag 1217 QB1: Q-Block1 Option values NUM/More/Size 1218 QB2: Q-Block2 Option values NUM/More/Size 1219 Size: Actual block size encoded in SZX 1220 \: Trimming long lines 1221 [[]]: Comments 1222 -->X: Message loss (request) 1223 X<--: Message loss (response) 1224 ...: Passage of time 1225 Payload N: Corresponds to the CoAP message that conveys 1226 a block number (N-1) of a given block-wise exchange. 1228 Figure 2: Notations Used in the Figures 1230 10.1. Q-Block1 Option 1232 10.1.1. A Simple Example 1234 Figure 3 depicts an example of a NON PUT request conveying Q-Block1 1235 Option. All the blocks are received by the server. 1237 CoAP CoAP 1238 Client Server 1239 | | 1240 +--------->| NON PUT /path M:0x81 T:0xc0 RT=9 QB1:0/1/1024 1241 +--------->| NON PUT /path M:0x82 T:0xc1 RT=9 QB1:1/1/1024 1242 +--------->| NON PUT /path M:0x83 T:0xc2 RT=9 QB1:2/1/1024 1243 +--------->| NON PUT /path M:0x84 T:0xc3 RT=9 QB1:3/0/1024 1244 |<---------+ NON 2.04 M:0xf1 T:0xc3 1245 | ... | 1247 Figure 3: Example of NON Request with Q-Block1 Option (Without Loss) 1249 10.1.2. Handling MAX_PAYLOADS Limits 1251 Figure 4 depicts an example of a NON PUT request conveying Q-Block1 1252 Option. The number of payloads exceeds MAX_PAYLOADS. All the blocks 1253 are received by the server. 1255 CoAP CoAP 1256 Client Server 1257 | | 1258 +--------->| NON PUT /path M:0x01 T:0xf1 RT=10 QB1:0/1/1024 1259 +--------->| NON PUT /path M:0x02 T:0xf2 RT=10 QB1:1/1/1024 1260 +--------->| [[Payloads 3 - 9 not detailed]] 1261 +--------->| NON PUT /path M:0x0a T:0xfa RT=10 QB1:9/1/1024 1262 [[MAX_PAYLOADS_SET has been received]] 1263 | [[MAX_PAYLOADS_SET receipt acknowledged by server]] 1264 |<---------+ NON 2.31 M:0x81 T:0xfa 1265 +--------->| NON PUT /path M:0x0b T:0xfb RT=10 QB1:10/0/1024 1266 |<---------+ NON 2.04 M:0x82 T:0xfb 1267 | ... | 1269 Figure 4: Example of MAX_PAYLOADS NON Request with Q-Block1 Option 1270 (Without Loss) 1272 10.1.3. Handling MAX_PAYLOADS with Recovery 1274 Consider now a scenario where a new body of data is to be sent by the 1275 client, but some blocks are dropped in transmission as illustrated in 1276 Figure 5. 1278 CoAP CoAP 1279 Client Server 1280 | | 1281 +--------->| NON PUT /path M:0x11 T:0xe1 RT=11 QB1:0/1/1024 1282 +--->X | NON PUT /path M:0x12 T:0xe2 RT=11 QB1:1/1/1024 1283 +--------->| [[Payloads 3 - 8 not detailed]] 1284 +--------->| NON PUT /path M:0x19 T:0xe9 RT=11 QB1:8/1/1024 1285 +--->X | NON PUT /path M:0x1a T:0xea RT=11 QB1:9/1/1024 1286 [[Some of MAX_PAYLOADS_SET have been received]] 1287 | ... | 1288 [[NON_TIMEOUT_RANDOM (client) delay expires]] 1289 | [[Client starts sending next MAX_PAYLOAD_SET]] 1290 +--->X | NON PUT /path M:0x1b T:0xeb RT=11 QB1:10/1/1024 1291 +--------->| NON PUT /path M:0x1c T:0xec RT=11 QB1:11/1/1024 1292 | | 1294 Figure 5: Example of MAX_PAYLOADS NON Request with Q-Block1 Option 1295 (With Loss) 1297 On seeing a payload from the next MAX_PAYLOAD_SET, the server 1298 realizes that some blocks are missing from the previous 1299 MAX_PAYLOADS_SET and asks for the missing blocks in one go 1300 (Figure 6). It does so by indicating which blocks from the previous 1301 MAX_PAYLOADS_SET have not been received in the data portion of the 1302 response (Section 5). The token used in the response should be the 1303 token that was used in the last received payload. The client can 1304 then derive the Request-Tag by matching the token with the sent 1305 request. 1307 CoAP CoAP 1308 Client Server 1309 | | 1310 |<---------+ NON 4.08 M:0x91 T:0xec [Missing 1,9] 1311 | [[Client responds with missing payloads]] 1312 +--------->| NON PUT /path M:0x1d T:0xed RT=11 QB1:1/1/1024 1313 +--------->| NON PUT /path M:0x1e T:0xee RT=11 QB1:9/1/1024 1314 | [[Client continues sending next MAX_PAYLOAD_SET]] 1315 +--------->| NON PUT /path M:0x1f T:0xef RT=11 QB1:12/0/1024 1316 | ... | 1317 [[NON_RECEIVE_TIMEOUT (server) delay expires]] 1318 | [[The server realizes a block is still missing and asks 1319 | for the missing one]] 1320 |<---------+ NON 4.08 M:0x92 T:0xef [Missing 10] 1321 +--------->| NON PUT /path M:0x20 T:0xf0 RT=11 QB1:10/1/1024 1322 |<---------+ NON 2.04 M:0x93 T:0xf0 1323 | ... | 1325 Figure 6: Example of NON Request with Q-Block1 Option (Blocks 1326 Recovery) 1328 10.1.4. Handling Recovery with Failure 1330 Figure 7 depicts an example of a NON PUT request conveying Q-Block1 1331 Option where recovery takes place, but eventually fails. 1333 CoAP CoAP 1334 Client Server 1335 | | 1336 +--------->| NON PUT /path M:0x91 T:0xd0 RT=12 QB1:0/1/1024 1337 +--->X | NON PUT /path M:0x92 T:0xd1 RT=12 QB1:1/1/1024 1338 +--------->| NON PUT /path M:0x93 T:0xd2 RT=12 QB1:2/0/1024 1339 | ... | 1340 [[NON_RECEIVE_TIMEOUT (server) delay expires]] 1341 | [[The server realizes a block is missing and asks 1342 | for the missing one. Retry #1]] 1343 |<---------+ NON 4.08 M:0x01 T:0xd2 [Missing 1] 1344 | ... | 1345 [[2 * NON_RECEIVE_TIMEOUT (server) delay expires]] 1346 | [[The server realizes a block is still missing and asks 1347 | for the missing one. Retry #2]] 1348 |<---------+ NON 4.08 M:0x02 T:0xd2 [Missing 1] 1349 | ... | 1350 [[4 * NON_RECEIVE_TIMEOUT (server) delay expires]] 1351 | [[The server realizes a block is still missing and asks 1352 | for the missing one. Retry #3]] 1353 |<---------+ NON 4.08 M:0x03 T:0xd2 [Missing 1] 1354 | ... | 1355 [[8 * NON_RECEIVE_TIMEOUT (server) delay expires]] 1356 | [[The server realizes a block is still missing and asks 1357 | for the missing one. Retry #4]] 1358 |<---------+ NON 4.08 M:0x04 T:0xd2 [Missing 1] 1359 | ... | 1360 [[16 * NON_RECEIVE_TIMEOUT (server) delay expires]] 1361 | [[NON_MAX_RETRANSMIT exceeded. Server stops requesting 1362 | for missing blocks and releases partial body]] 1363 | ... | 1365 Figure 7: Example of NON Request with Q-Block1 Option (With Eventual 1366 Failure) 1368 10.2. Q-Block2 Option 1370 These examples include the Observe Option to demonstrate how that 1371 option is used. Note that the Observe Option is not required for 1372 Q-Block2; the observe detail can thus be ignored. 1374 10.2.1. A Simple Example 1376 Figure 8 illustrates the example of Q-Block2 Option. The client 1377 sends a NON GET carrying Observe and Q-Block2 Options. The Q-Block2 1378 Option indicates a block size hint (1024 bytes). This request is 1379 replied to by the server using four (4) blocks that are transmitted 1380 to the client without any loss. Each of these blocks carries a 1381 Q-Block2 Option. The same process is repeated when an Observe is 1382 triggered, but no loss is experienced by any of the notification 1383 blocks. 1385 CoAP CoAP 1386 Client Server 1387 | | 1388 +--------->| NON GET /path M:0x01 T:0xc0 O:0 QB2:0/1/1024 1389 |<---------+ NON 2.05 M:0xf1 T:0xc0 O:1220 ET=19 QB2:0/1/1024 1390 |<---------+ NON 2.05 M:0xf2 T:0xc0 O:1220 ET=19 QB2:1/1/1024 1391 |<---------+ NON 2.05 M:0xf3 T:0xc0 O:1220 ET=19 QB2:2/1/1024 1392 |<---------+ NON 2.05 M:0xf4 T:0xc0 O:1220 ET=19 QB2:3/0/1024 1393 | ... | 1394 | [[Observe triggered]] 1395 |<---------+ NON 2.05 M:0xf5 T:0xc0 O:1221 ET=20 QB2:0/1/1024 1396 |<---------+ NON 2.05 M:0xf6 T:0xc0 O:1221 ET=20 QB2:1/1/1024 1397 |<---------+ NON 2.05 M:0xf7 T:0xc0 O:1221 ET=20 QB2:2/1/1024 1398 |<---------+ NON 2.05 M:0xf8 T:0xc0 O:1221 ET=20 QB2:3/0/1024 1399 | ... | 1401 Figure 8: Example of NON Notifications with Q-Block2 Option (Without 1402 Loss) 1404 10.2.2. Handling MAX_PAYLOADS Limits 1406 Figure 9 illustrates the same as Figure 8 but this time has eleven 1407 (11) payloads which exceeds MAX_PAYLOADS. There is no loss 1408 experienced. 1410 CoAP CoAP 1411 Client Server 1412 | | 1413 +--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024 1414 |<---------+ NON 2.05 M:0x81 T:0xf0 O:1234 ET=21 QB2:0/1/1024 1415 |<---------+ NON 2.05 M:0x82 T:0xf0 O:1234 ET=21 QB2:1/1/1024 1416 |<---------+ [[Payloads 3 - 9 not detailed]] 1417 |<---------+ NON 2.05 M:0x8a T:0xf0 O:1234 ET=21 QB2:9/1/1024 1418 [[MAX_PAYLOADS_SET has been received]] 1419 | [[MAX_PAYLOADS_SET acknowledged by client using 1420 | 'Continue' Q-Block2]] 1421 +--------->| NON GET /path M:0x02 T:0xf1 QB2:10/1/1024 1422 |<---------+ NON 2.05 M:0x8b T:0xf0 O:1234 ET=21 QB2:10/0/1024 1423 | ... | 1424 | [[Observe triggered]] 1425 |<---------+ NON 2.05 M:0x91 T:0xf0 O:1235 ET=22 QB2:0/1/1024 1426 |<---------+ NON 2.05 M:0x92 T:0xf0 O:1235 ET=22 QB2:1/1/1024 1427 |<---------+ [[Payloads 3 - 9 not detailed]] 1428 |<---------+ NON 2.05 M:0x9a T:0xf0 O:1235 ET=22 QB2:9/1/1024 1429 [[MAX_PAYLOADS_SET has been received]] 1430 | [[MAX_PAYLOADS_SET acknowledged by client using 1431 | 'Continue' Q-Block2]] 1432 +--------->| NON GET /path M:0x03 T:0xf2 QB2:10/1/1024 1433 |<---------+ NON 2.05 M:0x9b T:0xf0 O:1235 ET=22 QB2:10/0/1024 1434 [[Body has been received]] 1435 | ... | 1437 Figure 9: Example of NON Notifications with Q-Block2 Option (Without 1438 Loss) 1440 10.2.3. Handling MAX_PAYLOADS with Recovery 1442 Figure 10 shows the example of an Observe that is triggered but for 1443 which some notification blocks are lost. The client detects the 1444 missing blocks and requests their retransmission. It does so by 1445 indicating the blocks that are missing as one or more Q-Block2 1446 Options. 1448 CoAP CoAP 1449 Client Server 1450 | ... | 1451 | [[Observe triggered]] 1452 |<---------+ NON 2.05 M:0xa1 T:0xf0 O:1236 ET=23 QB2:0/1/1024 1453 | X<---+ NON 2.05 M:0xa2 T:0xf0 O:1236 ET=23 QB2:1/1/1024 1454 |<---------+ [[Payloads 3 - 9 not detailed]] 1455 | X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024 1456 [[Some of MAX_PAYLOADS_SET have been received]] 1457 | ... | 1458 [[NON_TIMEOUT_RANDOM (server) delay expires]] 1459 | [[Server sends next MAX_PAYLOAD_SET]] 1460 |<---------+ NON 2.05 M:0xab T:0xf0 O:1236 ET=23 QB2:10/0/1024 1461 | [[On seeing a payload from the next MAX_PAYLOAD_SET, 1462 | Client realizes blocks are missing and asks for the 1463 | missing ones in one go]] 1464 +--------->| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\ 1465 | | QB2:9/0/1024 1466 | X<---+ NON 2.05 M:0xac T:0xf3 ET=23 QB2:1/1/1024 1467 |<---------+ NON 2.05 M:0xad T:0xf3 ET=23 QB2:9/1/1024 1468 | ... | 1469 [[NON_RECEIVE_TIMEOUT (client) delay expires]] 1470 | [[Client realizes block is still missing and asks for 1471 | missing block]] 1472 +--------->| NON GET /path M:0x05 T:0xf4 QB2:1/0/1024 1473 |<---------+ NON 2.05 M:0xae T:0xf4 ET=23 QB2:1/1/1024 1474 [[Body has been received]] 1475 | ... | 1477 Figure 10: Example of NON Notifications with Q-Block2 Option (Blocks 1478 Recovery) 1480 10.2.4. Handling Recovery using M-bit Set 1482 Figure 11 shows the example of an Observe that is triggered but only 1483 the first two notification blocks reach the client. In order to 1484 retrieve the missing blocks, the client sends a request with a single 1485 Q-Block2 Option with the M bit set. 1487 CoAP CoAP 1488 Client Server 1489 | ... | 1490 | [[Observe triggered]] 1491 |<---------+ NON 2.05 M:0xb1 T:0xf0 O:1237 ET=24 QB2:0/1/1024 1492 |<---------+ NON 2.05 M:0xb2 T:0xf0 O:1237 ET=24 QB2:1/1/1024 1493 | X<---+ NON 2.05 M:0xb3 T:0xf0 O:1237 ET=24 QB2:2/1/1024 1494 | X<---+ [[Payloads 4 - 9 not detailed]] 1495 | X<---+ NON 2.05 M:0xb9 T:0xf0 O:1237 ET=24 QB2:9/1/1024 1496 [[Some of MAX_PAYLOADS_SET have been received]] 1497 | ... | 1498 [[NON_TIMEOUT_RANDOM (server) delay expires]] 1499 | [[Server sends next MAX_PAYLOAD_SET]] 1500 | X<---+ NON 2.05 M:0xba T:0xf0 O:1237 ET=24 QB2:10/0/1024 1501 | ... | 1502 [[NON_RECEIVE_TIMEOUT (client) delay expires]] 1503 | [[Client realizes blocks are missing and asks for the 1504 | missing ones in one go by setting the M bit]] 1505 +--------->| NON GET /path M:0x06 T:0xf5 QB2:2/1/1024 1506 |<---------+ NON 2.05 M:0xbb T:0xf5 ET=24 QB2:2/1/1024 1507 |<---------+ [[Payloads 3 - 9 not detailed]] 1508 |<---------+ NON 2.05 M:0xc2 T:0xf5 ET=24 QB2:9/1/1024 1509 [[MAX_PAYLOADS_SET has been received]] 1510 | [[MAX_PAYLOADS_SET acknowledged by client using 'Continue' 1511 | Q-Block2]] 1512 +--------->| NON GET /path M:0x87 T:0xf6 QB2:10/1/1024 1513 |<---------+ NON 2.05 M:0xc3 T:0xf0 O:1237 ET=24 QB2:10/0/1024 1514 [[Body has been received]] 1515 | ... | 1517 Figure 11: Example of NON Notifications with Q-Block2 Option (Blocks 1518 Recovery with M bit Set) 1520 10.3. Q-Block1 and Q-Block2 Options 1522 10.3.1. A Simple Example 1524 Figure 12 illustrates the example of a FETCH using both Q-Block1 and 1525 Q-Block2 Options along with an Observe Option. No loss is 1526 experienced. 1528 CoAP CoAP 1529 Client Server 1530 | | 1531 +--------->| NON FETCH /path M:0x10 T:0x90 O:0 RT=30 QB1:0/1/1024 1532 +--------->| NON FETCH /path M:0x11 T:0x91 O:0 RT=30 QB1:1/1/1024 1533 +--------->| NON FETCH /path M:0x12 T:0x93 O:0 RT=30 QB1:2/0/1024 1534 |<---------+ NON 2.05 M:0x60 T:0x93 O:1320 ET=90 QB2:0/1/1024 1535 |<---------+ NON 2.05 M:0x61 T:0x93 O:1320 ET=90 QB2:1/1/1024 1536 |<---------+ NON 2.05 M:0x62 T:0x93 O:1320 ET=90 QB2:2/1/1024 1537 |<---------+ NON 2.05 M:0x63 T:0x93 O:1320 ET=90 QB2:3/0/1024 1538 | ... | 1539 | [[Observe triggered]] 1540 |<---------+ NON 2.05 M:0x64 T:0x93 O:1321 ET=91 QB2:0/1/1024 1541 |<---------+ NON 2.05 M:0x65 T:0x93 O:1321 ET=91 QB2:1/1/1024 1542 |<---------+ NON 2.05 M:0x66 T:0x93 O:1321 ET=91 QB2:2/1/1024 1543 |<---------+ NON 2.05 M:0x67 T:0x93 O:1321 ET=91 QB2:3/0/1024 1544 | ... | 1546 Figure 12: Example of NON FETCH with Q-Block1 and Q-Block2 Options 1547 (Without Loss) 1549 10.3.2. Handling MAX_PAYLOADS Limits 1551 Figure 13 illustrates the same as Figure 12 but this time has eleven 1552 (11) payloads in both directions which exceeds MAX_PAYLOADS. There 1553 is no loss experienced. 1555 CoAP CoAP 1556 Client Server 1557 | | 1558 +--------->| NON FETCH /path M:0x30 T:0xa0 O:0 RT=10 QB1:0/1/1024 1559 +--------->| NON FETCH /path M:0x31 T:0xa1 O:0 RT=10 QB1:1/1/1024 1560 +--------->| [[Payloads 3 - 9 not detailed]] 1561 +--------->| NON FETCH /path M:0x39 T:0xa9 O:0 RT=10 QB1:9/1/1024 1562 [[MAX_PAYLOADS_SET has been received]] 1563 | [[MAX_PAYLOADS_SET acknowledged by server]] 1564 |<---------+ NON 2.31 M:0x80 T:0xa9 1565 +--------->| NON FETCH /path M:0x3a T:0xaa O:0 RT=10 QB1:10/0/1024 1566 |<---------+ NON 2.05 M:0x81 T:0xaa O:1334 ET=21 QB2:0/1/1024 1567 |<---------+ NON 2.05 M:0x82 T:0xaa O:1334 ET=21 QB2:1/1/1024 1568 |<---------+ [[Payloads 3 - 9 not detailed]] 1569 |<---------+ NON 2.05 M:0x8a T:0xaa O:1334 ET=21 QB2:9/1/1024 1570 [[MAX_PAYLOADS_SET has been received]] 1571 | [[MAX_PAYLOADS_SET acknowledged by client using 1572 | 'Continue' Q-Block2]] 1573 +--------->| NON FETCH /path M:0x3b T:0xab QB2:10/1/1024 1574 |<---------+ NON 2.05 M:0x8b T:0xaa O:1334 ET=21 QB2:10/0/1024 1575 | ... | 1576 | [[Observe triggered]] 1577 |<---------+ NON 2.05 M:0x8c T:0xaa O:1335 ET=22 QB2:0/1/1024 1578 |<---------+ NON 2.05 M:0x8d T:0xaa O:1335 ET=22 QB2:1/1/1024 1579 |<---------+ [[Payloads 3 - 9 not detailed]] 1580 |<---------+ NON 2.05 M:0x95 T:0xaa O:1335 ET=22 QB2:9/1/1024 1581 [[MAX_PAYLOADS_SET has been received]] 1582 | [[MAX_PAYLOADS_SET acknowledged by client using 1583 | 'Continue' Q-Block2]] 1584 +--------->| NON FETCH /path M:0x3c T:0xac QB2:10/1/1024 1585 |<---------+ NON 2.05 M:0x96 T:0xaa O:1335 ET=22 QB2:10/0/1024 1586 [[Body has been received]] 1587 | ... | 1589 Figure 13: Example of NON FETCH with Q-Block1 and Q-Block2 Options 1590 (Without Loss) 1592 Note that as 'Continue' was used, the server continues to use the 1593 same token (0xaa) since the 'Continue' is not being used as a request 1594 for a new set of packets, but rather is being used to instruct the 1595 server to continue its transmission (Section 7.2). 1597 10.3.3. Handling Recovery 1599 Consider now a scenario where some blocks are lost in transmission as 1600 illustrated in Figure 14. 1602 CoAP CoAP 1603 Client Server 1604 | | 1605 +--------->| NON FETCH /path M:0x50 T:0xc0 O:0 RT=31 QB1:0/1/1024 1606 +--->X | NON FETCH /path M:0x51 T:0xc1 O:0 RT=31 QB1:1/1/1024 1607 +--->X | NON FETCH /path M:0x52 T:0xc2 O:0 RT=31 QB1:2/1/1024 1608 +--------->| NON FETCH /path M:0x53 T:0xc3 O:0 RT=31 QB1:3/0/1024 1609 | ... | 1610 [[NON_RECEIVE_TIMEOUT (server) delay expires]] 1612 Figure 14: Example of NON FETCH with Q-Block1 and Q-Block2 Options 1613 (With Loss) 1615 The server realizes that some blocks are missing and asks for the 1616 missing blocks in one go (Figure 15). It does so by indicating which 1617 blocks have not been received in the data portion of the response. 1618 The token used in the response is the token that was used in the last 1619 received payload. The client can then derive the Request-Tag by 1620 matching the token with the sent request. 1622 CoAP CoAP 1623 Client Server 1624 | | 1625 |<---------+ NON 4.08 M:0xa0 T:0xc3 [Missing 1,2] 1626 | [[Client responds with missing payloads]] 1627 +--------->| NON FETCH /path M:0x54 T:0xc4 O:0 RT=31 QB1:1/1/1024 1628 +--------->| NON FETCH /path M:0x55 T:0xc5 O:0 RT=31 QB1:2/1/1024 1629 | [[Server received FETCH body, 1630 | starts transmitting response body]] 1631 |<---------+ NON 2.05 M:0xa1 T:0xc3 O:1236 ET=23 QB2:0/1/1024 1632 | X<---+ NON 2.05 M:0xa2 T:0xc3 O:1236 ET=23 QB2:1/1/1024 1633 |<---------+ NON 2.05 M:0xa3 T:0xc3 O:1236 ET=23 QB2:2/1/1024 1634 | X<---+ NON 2.05 M:0xa4 T:0xc3 O:1236 ET=23 QB2:3/0/1024 1635 | ... | 1636 [[NON_RECEIVE_TIMEOUT (client) delay expires]] 1637 | | 1639 Figure 15: Example of NON Request with Q-Block1 Option (Server 1640 Recovery) 1642 The client realizes that not all the payloads of the response have 1643 been returned. The client then asks for the missing blocks in one go 1644 (Figure 16). Note that, following Section 2.7 of [RFC7959], the 1645 FETCH request does not include the Q-Block1 or any payload. 1647 CoAP CoAP 1648 Client Server 1649 | | 1650 +--------->| NON FETCH /path M:0x56 T:0xc6 RT=31 QB2:1/0/1024\ 1651 | | QB2:3/0/1024 1652 | [[Server receives FETCH request for missing payloads, 1653 | starts transmitting missing blocks]] 1654 | X<---+ NON 2.05 M:0xa5 T:0xc6 ET=23 QB2:1/1/1024 1655 |<---------+ NON 2.05 M:0xa6 T:0xc6 ET=23 QB2:3/0/1024 1656 | ... | 1657 [[NON_RECEIVE_TIMEOUT (client) delay expires]] 1658 | [[Client realizes block is still missing and asks for 1659 | missing block]] 1660 +--------->| NON FETCH /path M:0x57 T:0xc7 RT=31 QB2:1/0/1024 1661 | [[Server receives FETCH request for missing payload, 1662 | starts transmitting missing block]] 1663 |<---------+ NON 2.05 M:0xa7 T:0xc7 ET=23 QB2:1/1/1024 1664 [[Body has been received]] 1665 | ... | 1666 | [[Observe triggered]] 1667 |<---------+ NON 2.05 M:0xa8 T:0xc3 O:1337 ET=24 QB2:0/1/1024 1668 | X<---+ NON 2.05 M:0xa9 T:0xc3 O:1337 ET=24 QB2:1/1/1024 1669 |<---------+ NON 2.05 M:0xaa T:0xc3 O:1337 ET=24 QB2:2/0/1024 1670 [[NON_RECEIVE_TIMEOUT (client) delay expires]] 1671 | [[Client realizes block is still missing and asks for 1672 | missing block]] 1673 +--------->| NON FETCH /path M:0x58 T:0xc8 RT=31 QB2:1/0/1024 1674 | [[Server receives FETCH request for missing payload, 1675 | starts transmitting missing block]] 1676 |<---------+ NON 2.05 M:0xa7 T:0xc8 ET=24 QB2:1/1/1024 1677 [[Body has been received]] 1678 | ... | 1680 Figure 16: Example of NON Request with Q-Block1 Option (Client 1681 Recovery) 1683 11. Security Considerations 1685 Security considerations discussed in Section 7 of [RFC7959] should be 1686 taken into account. 1688 Security considerations discussed in Sections 11.3 and 11.4 of 1689 [RFC7252] should be taken into account. 1691 OSCORE provides end-to-end protection of all information that is not 1692 required for proxy operations and requires that a security context is 1693 set up (Section 3.1 of [RFC8613]). It can be trusted that the source 1694 endpoint is legitimate even if NoSec security mode is used. However, 1695 an intermediary node can modify the unprotected outer Q-Block1 and/or 1696 Q-Block2 Options to cause a Q-Block transfer to fail or keep 1697 requesting all the blocks by setting the M bit and, thus, causing 1698 attack amplification. As discussed in Section 12.1 of [RFC8613], 1699 applications need to consider that certain message fields and 1700 messages types are not protected end-to-end and may be spoofed or 1701 manipulated. Therefore, it is NOT RECOMMENDED to use the NoSec 1702 security mode if either the Q-Block1 or Q-Block2 Options is used. 1704 If OSCORE is not used, it is also NOT RECOMMENDED to use the NoSec 1705 security mode if either the Q-Block1 or Q-Block2 Options is used. 1707 If NoSec is being used, Section D.5 of [RFC8613] discusses the 1708 security analysis and considerations for unprotected message fields 1709 even if OSCORE is not being used. 1711 Security considerations related to the use of Request-Tag are 1712 discussed in Section 5 of [I-D.ietf-core-echo-request-tag]. 1714 12. IANA Considerations 1716 RFC Editor Note: Please replace [RFCXXXX] with the RFC number to be 1717 assigned to this document. 1719 12.1. CoAP Option Numbers Registry 1721 IANA is requested to add the following entries to the "CoAP Option 1722 Numbers" sub-registry [Options] defined in [RFC7252] within the 1723 "Constrained RESTful Environments (CoRE) Parameters" registry: 1725 +--------+------------------+-----------+ 1726 | Number | Name | Reference | 1727 +========+==================+===========+ 1728 | TBA1 | Q-Block1 | [RFCXXXX] | 1729 | TBA2 | Q-Block2 | [RFCXXXX] | 1730 +--------+------------------+-----------+ 1732 Table 4: CoAP Q-Block1 and Q-Block2 Option Numbers 1734 This document suggests 19 (TBA1) and 31 (TBA2) as values to be 1735 assigned for the new option numbers. 1737 12.2. Media Type Registration 1739 This document requests IANA to register the "application/missing- 1740 blocks+cbor-seq" media type in the "Media Types" registry 1741 [IANA-MediaTypes]. This registration follows the procedures 1742 specified in [RFC6838]: 1744 Type name: application 1746 Subtype name: missing-blocks+cbor-seq 1748 Required parameters: N/A 1750 Optional parameters: N/A 1752 Encoding considerations: Must be encoded as a CBOR 1753 sequence [RFC8742], as defined in Section 4 of [RFCXXXX]. 1755 Security considerations: See Section 10 of [RFCXXXX]. 1757 Interoperability considerations: N/A 1759 Published specification: [RFCXXXX] 1761 Applications that use this media type: Data serialization and 1762 deserialization. In particular, the type is used by applications 1763 relying upon block-wise transfers, allowing a server to specify 1764 non-received blocks and request for their retransmission, as 1765 defined in Section 4 of [RFCXXXX]. 1767 Fragment identifier considerations: N/A 1769 Additional information: N/A 1771 Person & email address to contact for further information: IETF, 1772 iesg@ietf.org 1774 Intended usage: COMMON 1776 Restrictions on usage: none 1778 Author: See Authors' Addresses section. 1780 Change controller: IESG 1782 Provisional registration? No 1784 12.3. CoAP Content-Formats Registry 1786 This document requests IANA to register the following CoAP Content- 1787 Format for the "application/missing-blocks+cbor-seq" media type in 1788 the "CoAP Content-Formats" registry [Format], defined in [RFC7252], 1789 within the "Constrained RESTful Environments (CoRE) Parameters" 1790 registry: 1792 o Media Type: application/missing-blocks+cbor-seq 1793 o Encoding: - 1794 o Id: TBA3 1795 o Reference: [RFCXXXX] 1797 This document suggests 272 (TBA3) as a value to be assigned for the 1798 new content format number. 1800 13. References 1802 13.1. Normative References 1804 [I-D.ietf-core-echo-request-tag] 1805 Amsuess, C., Mattsson, J. P., and G. Selander, "CoAP: 1806 Echo, Request-Tag, and Token Processing", draft-ietf-core- 1807 echo-request-tag-12 (work in progress), February 2021. 1809 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1810 Requirement Levels", BCP 14, RFC 2119, 1811 DOI 10.17487/RFC2119, March 1997, 1812 . 1814 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1815 Specifications and Registration Procedures", BCP 13, 1816 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1817 . 1819 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1820 Application Protocol (CoAP)", RFC 7252, 1821 DOI 10.17487/RFC7252, June 2014, 1822 . 1824 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1825 Application Protocol (CoAP)", RFC 7641, 1826 DOI 10.17487/RFC7641, September 2015, 1827 . 1829 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1830 the Constrained Application Protocol (CoAP)", RFC 7959, 1831 DOI 10.17487/RFC7959, August 2016, 1832 . 1834 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 1835 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 1836 the Constrained Application Protocol (CoAP)", RFC 8075, 1837 DOI 10.17487/RFC8075, February 2017, 1838 . 1840 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 1841 FETCH Methods for the Constrained Application Protocol 1842 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 1843 . 1845 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1846 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1847 May 2017, . 1849 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1850 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 1851 Application Protocol) over TCP, TLS, and WebSockets", 1852 RFC 8323, DOI 10.17487/RFC8323, February 2018, 1853 . 1855 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1856 Definition Language (CDDL): A Notational Convention to 1857 Express Concise Binary Object Representation (CBOR) and 1858 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1859 June 2019, . 1861 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1862 "Object Security for Constrained RESTful Environments 1863 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1864 . 1866 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 1867 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 1868 . 1870 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1871 Representation (CBOR)", STD 94, RFC 8949, 1872 DOI 10.17487/RFC8949, December 2020, 1873 . 1875 13.2. Informative References 1877 [Format] "CoAP Content-Formats", . 1880 [I-D.bosh-dots-quick-blocks] 1881 Boucadair, M. and J. Shallow, "Distributed Denial-of- 1882 Service Open Threat Signaling (DOTS) Signal Channel 1883 Configuration Attributes for Faster Block Transmission", 1884 draft-bosh-dots-quick-blocks-01 (work in progress), 1885 January 2021. 1887 [I-D.ietf-dots-telemetry] 1888 Boucadair, M., Reddy, T., Doron, E., Chen, M., and J. 1889 Shallow, "Distributed Denial-of-Service Open Threat 1890 Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15 1891 (work in progress), December 2020. 1893 [IANA-MediaTypes] 1894 IANA, "Media Types", 1895 . 1897 [Options] "CoAP Option Numbers", . 1900 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 1901 "Increasing TCP's Initial Window", RFC 6928, 1902 DOI 10.17487/RFC6928, April 2013, 1903 . 1905 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 1906 Bose, "Constrained Application Protocol (CoAP) Option for 1907 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 1908 August 2016, . 1910 [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., 1911 Mortensen, A., and N. Teague, "Distributed Denial-of- 1912 Service Open Threat Signaling (DOTS) Signal Channel 1913 Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, 1914 . 1916 [RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and 1917 Stateless Clients in the Constrained Application Protocol 1918 (CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021, 1919 . 1921 Appendix A. Examples with Confirmable Messages 1923 The following examples assume NSTART has been increased to 3. 1925 The notations provided in Figure 2 are used in the following 1926 subsections. 1928 A.1. Q-Block1 Option 1930 Let's now consider the use of Q-Block1 Option with a CON request as 1931 shown in Figure 17. All the blocks are acknowledged (ACK). 1933 CoAP CoAP 1934 Client Server 1935 | | 1936 +--------->| CON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024 1937 +--------->| CON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024 1938 +--------->| CON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024 1939 [[NSTART(3) limit reached]] 1940 |<---------+ ACK 0.00 M:0x01 1941 +--------->| CON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024 1942 |<---------+ ACK 0.00 M:0x02 1943 |<---------+ ACK 0.00 M:0x03 1944 |<---------+ ACK 2.04 M:0x04 1945 | | 1947 Figure 17: Example of CON Request with Q-Block1 Option (Without Loss) 1949 Now, suppose that a new body of data is to be sent but with some 1950 blocks dropped in transmission as illustrated in Figure 18. The 1951 client will retry sending blocks for which no ACK was received. 1953 CoAP CoAP 1954 Client Server 1955 | | 1956 +--------->| CON PUT /path M:0x05 T:0xf4 RT=11 QB1:0/1/1024 1957 +--->X | CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 1958 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 1959 [[NSTART(3) limit reached]] 1960 |<---------+ ACK 0.00 M:0x05 1961 +--------->| CON PUT /path M:0x08 T:0xf7 RT=11 QB1:3/1/1024 1962 |<---------+ ACK 0.00 M:0x08 1963 | ... | 1964 [[ACK TIMEOUT (client) for M:0x06 delay expires]] 1965 | [[Client retransmits packet]] 1966 +--------->| CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 1967 [[ACK TIMEOUT (client) for M:0x07 delay expires]] 1968 | [[Client retransmits packet]] 1969 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 1970 |<---------+ ACK 0.00 M:0x06 1971 | ... | 1972 [[ACK TIMEOUT exponential backoff (client) delay expires]] 1973 | [[Client retransmits packet]] 1974 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 1975 | ... | 1976 [[Either body transmission failure (acknowledge retry timeout) 1977 or successfully transmitted.]] 1979 Figure 18: Example of CON Request with Q-Block1 Option (Blocks 1980 Recovery) 1982 It is up to the implementation as to whether the application process 1983 stops trying to send this particular body of data on reaching 1984 MAX_RETRANSMIT for any payload, or separately tries to initiate the 1985 new transmission of the payloads that have not been acknowledged 1986 under these adverse traffic conditions. 1988 If there is likely to be the possibility of transient network losses, 1989 then the use of NON should be considered. 1991 A.2. Q-Block2 Option 1993 An example of the use of Q-Block2 Option with Confirmable messages is 1994 shown in Figure 19. 1996 Client Server 1997 | | 1998 +--------->| CON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024 1999 |<---------+ ACK 2.05 M:0x01 T:0xf0 O:1234 ET=21 QB2:0/1/1024 2000 |<---------+ CON 2.05 M:0xe1 T:0xf0 O:1234 ET=21 QB2:1/1/1024 2001 |<---------+ CON 2.05 M:0xe2 T:0xf0 O:1234 ET=21 QB2:2/1/1024 2002 |<---------+ CON 2.05 M:0xe3 T:0xf0 O:1234 ET=21 QB2:3/0/1024 2003 |--------->+ ACK 0.00 M:0xe1 2004 |--------->+ ACK 0.00 M:0xe2 2005 |--------->+ ACK 0.00 M:0xe3 2006 | ... | 2007 | [[Observe triggered]] 2008 |<---------+ CON 2.05 M:0xe4 T:0xf0 O:1235 ET=22 QB2:0/1/1024 2009 |<---------+ CON 2.05 M:0xe5 T:0xf0 O:1235 ET=22 QB2:1/1/1024 2010 |<---------+ CON 2.05 M:0xe6 T:0xf0 O:1235 ET=22 QB2:2/1/1024 2011 [[NSTART(3) limit reached]] 2012 |--------->+ ACK 0.00 M:0xe4 2013 |<---------+ CON 2.05 M:0xe7 T:0xf0 O:1235 ET=22 QB2:3/0/1024 2014 |--------->+ ACK 0.00 M:0xe5 2015 |--------->+ ACK 0.00 M:0xe6 2016 |--------->+ ACK 0.00 M:0xe7 2017 | ... | 2018 | [[Observe triggered]] 2019 |<---------+ CON 2.05 M:0xe8 T:0xf0 O:1236 ET=23 QB2:0/1/1024 2020 | X<---+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 2021 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 2022 [[NSTART(3) limit reached]] 2023 |--------->+ ACK 0.00 M:0xe8 2024 |<---------+ CON 2.05 M:0xeb T:0xf0 O:1236 ET=23 QB2:3/0/1024 2025 |--------->+ ACK 0.00 M:0xeb 2026 | ... | 2027 [[ACK TIMEOUT (server) for M:0xe9 delay expires]] 2028 | [[Server retransmits packet]] 2029 |<---------+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 2030 [[ACK TIMEOUT (server) for M:0xea delay expires]] 2031 | [[Server retransmits packet]] 2032 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 2033 |--------->+ ACK 0.00 M:0xe9 2034 | ... | 2035 [[ACK TIMEOUT exponential backoff (server) delay expires]] 2036 | [[Server retransmits packet]] 2037 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 2038 | ... | 2039 [[Either body transmission failure (acknowledge retry timeout) 2040 or successfully transmitted.]] 2042 Figure 19: Example of CON Notifications with Q-Block2 Option 2044 It is up to the implementation as to whether the application process 2045 stops trying to send this particular body of data on reaching 2046 MAX_RETRANSMIT for any payload, or separately tries to initiate the 2047 new transmission of the payloads that have not been acknowledged 2048 under these adverse traffic conditions. 2050 If there is likely to be the possibility of transient network losses, 2051 then the use of NON should be considered. 2053 Appendix B. Examples with Reliable Transports 2055 The notations provided in Figure 2 are used in the following 2056 subsections. 2058 B.1. Q-Block1 Option 2060 Let's now consider the use of Q-Block1 Option with a reliable 2061 transport as shown in Figure 20. There is no acknowledgment of 2062 packets at the CoAP layer, just the final result. 2064 CoAP CoAP 2065 Client Server 2066 | | 2067 +--------->| PUT /path T:0xf0 RT=10 QB1:0/1/1024 2068 +--------->| PUT /path T:0xf1 RT=10 QB1:1/1/1024 2069 +--------->| PUT /path T:0xf2 RT=10 QB1:2/1/1024 2070 +--------->| PUT /path T:0xf3 RT=10 QB1:3/0/1024 2071 |<---------+ 2.04 2072 | | 2074 Figure 20: Example of Reliable Request with Q-Block1 Option 2076 If there is likely to be the possibility of transient network losses, 2077 then the use of unreliable transport with NON should be considered. 2079 B.2. Q-Block2 Option 2081 An example of the use of Q-Block2 Option with a reliable transport is 2082 shown in Figure 21. 2084 Client Server 2085 | | 2086 +--------->| GET /path T:0xf0 O:0 QB2:0/1/1024 2087 |<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:0/1/1024 2088 |<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:1/1/1024 2089 |<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:2/1/1024 2090 |<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:3/0/1024 2091 | ... | 2092 | [[Observe triggered]] 2093 |<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:0/1/1024 2094 |<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:1/1/1024 2095 |<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:2/1/1024 2096 |<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:3/0/1024 2097 | ... | 2099 Figure 21: Example of Notifications with Q-Block2 Option 2101 If there is likely to be the possibility of network transient losses, 2102 then the use of unreliable transport with NON should be considered. 2104 Acknowledgements 2106 Thanks to Achim Kraus, Jim Schaad, and Michael Richardson for their 2107 comments. 2109 Special thanks to Christian Amsuess, Carsten Bormann, and Marco 2110 Tiloca for their suggestions and several reviews, which improved this 2111 specification significantly. Thanks to Francesca Palombini for the 2112 AD review. 2114 Thanks to Pete Resnick for the Gen-ART review, Colin Perkins for the 2115 Tsvart review, and Emmanuel Baccelli for the Iotdir review. Thanks 2116 to Martin Duke, Eric Vyncke, Benjamin Kaduk, Roman Danyliw, John 2117 Scudder, and Lars Eggert for the IESG review. 2119 Some text from [RFC7959] is reused for readers convenience. 2121 Authors' Addresses 2123 Mohamed Boucadair 2124 Orange 2125 Rennes 35000 2126 France 2128 Email: mohamed.boucadair@orange.com 2129 Jon Shallow 2130 United Kingdom 2132 Email: supjps-ietf@jpshallow.com