idnits 2.17.1 draft-ietf-core-new-block-12.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 11, 2021) is 1071 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 1587, but not defined -- Looks like a reference, but probably isn't: '9' on line 1272 == Missing Reference: 'Missing 10' is mentioned on line 1282, but not defined -- Looks like a reference, but probably isn't: '2' on line 1587 == Missing Reference: 'RFCXXXX' is mentioned on line 1750, 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 12, 2021 May 11, 2021 7 Constrained Application Protocol (CoAP) Block-Wise Transfer Options for 8 Faster Transmission 9 draft-ietf-core-new-block-12 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 enabling faster transmission rates for large amounts 20 of data with fewer packet interchanges. Also, the Q-Block1 and 21 Q-Block2 Options support faster recovery should any of the blocks get 22 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 12, 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 . . . . . . . . . . . . . . . . 10 67 4.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 14 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 . . . . . . 17 71 4.8. Using Q-Block2 Option With Multicast . . . . . . . . . . 17 72 5. The Use of 4.08 (Request Entity Incomplete) Response Code . . 17 73 6. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 19 74 7. Congestion Control for Unreliable Transports . . . . . . . . 19 75 7.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 19 76 7.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 20 77 8. Caching Considerations . . . . . . . . . . . . . . . . . . . 24 78 9. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 25 79 10. Examples with Non-confirmable Messages . . . . . . . . . . . 25 80 10.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . 26 81 10.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 26 82 10.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 26 83 10.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 26 84 10.1.4. Handling Recovery with Failure . . . . . . . . . . . 28 85 10.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . 29 86 10.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 29 87 10.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 30 88 10.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 31 89 10.2.4. Handling Recovery using M-bit Set . . . . . . . . . 32 90 10.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . 33 91 10.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 33 92 10.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 34 93 10.3.3. Handling Recovery . . . . . . . . . . . . . . . . . 35 94 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37 95 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 96 12.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 38 97 12.2. Media Type Registration . . . . . . . . . . . . . . . . 38 98 12.3. CoAP Content-Formats Registry . . . . . . . . . . . . . 39 99 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 100 13.1. Normative References . . . . . . . . . . . . . . . . . . 40 101 13.2. Informative References . . . . . . . . . . . . . . . . . 41 102 Appendix A. Examples with Confirmable Messages . . . . . . . . . 42 103 A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 42 104 A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 44 105 Appendix B. Examples with Reliable Transports . . . . . . . . . 46 106 B.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 46 107 B.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 46 108 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 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 elect 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 at higher rates under network conditions 140 where there may be asymmetrical transient packet loss (e.g., 141 responses may get dropped). An example is when a network is subject 142 to a Distributed Denial of Service (DDoS) attack and there is a need 143 for 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 for an acknowledgement (but recovery is available 157 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, they have the same numeric 197 result. For example, if MAX_PAYLOADS is set to '10', a 198 MAX_PAYLOADS_SET could be blocks #0 to #9, #10 to #19, etc. 199 Depending on the data size, the MAX_PAYLOADS_SET may not comprise all 200 the MAX_PAYLOADS blocks. 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, the faster transmissions 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 an intermediate response 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, but falls short in situations where packet loss is highly 306 asymmetrical. The mechanism specified in this document provides 307 roughly similar features to the Block1/Block2 Options. It provides 308 additional properties that are tailored towards the intended use case 309 of Non-Confirmable transmission. Concretely, this mechanism 310 primarily targets applications such as DDoS Open Threat Signaling 311 (DOTS) that cannot use CON responses to handle potential packet loss 312 and that support application-specific mechanisms to assess whether 313 the remote peer is not overloaded and thus is able to process the 314 messages sent by a CoAP endpoint (e.g., DOTS heartbeats in 315 Section 4.7 of [RFC8782]). 317 The mechanism includes guards to prevent a CoAP agent from 318 overloading the network by adopting an aggressive sending rate. 319 These guards MUST be followed in addition to the existing CoAP 320 congestion control as specified in Section 4.7 of [RFC7252]. See 321 Section 7 for more details. 323 This mechanism is not intended for general CoAP usage, and any use 324 outside the intended use case should be carefully weighed against the 325 loss of interoperability with generic CoAP applications. It is hoped 326 that the experience gained with this mechanism can feed future 327 extensions of the block-wise mechanism that will both be generally 328 applicable and serve this particular use case. 330 It is not recommended that these options are used in a NoSec security 331 mode (Section 9 of [RFC7252]) as the source endpoint needs to be 332 trusted. Using OSCORE [RFC8613] does provide a security context and, 333 hence, a trust of the source endpoint that prepared the inner OSCORE 334 content. However, even with OSCORE, using a NoSec security mode with 335 these options may still be inadequate, for reasons discussed in 336 Section 11. 338 4. The Q-Block1 and Q-Block2 Options 340 4.1. Properties of Q-Block1 and Q-Block2 Options 342 The properties of the Q-Block1 and Q-Block2 Options are shown in 343 Table 1. The formatting of this table follows the one used in 344 Table 4 of [RFC7252] (Section 5.10). The C, U, N, and R columns 345 indicate the properties Critical, UnSafe, NoCacheKey, and Repeatable 346 defined in Section 5.4 of [RFC7252]. Only Critical and UnSafe 347 columns are marked for the Q-Block1 Option. Critical, UnSafe, and 348 Repeatable columns are marked for the Q-Block2 Option. As these 349 options are UnSafe, NoCacheKey has no meaning and so is marked with a 350 dash. 352 +--------+---+---+---+---+--------------+--------+--------+---------+ 353 | Number | C | U | N | R | Name | Format | Length | Default | 354 +========+===+===+===+===+==============+========+========+=========+ 355 | TBA1 | x | x | - | | Q-Block1 | uint | 0-3 | (none) | 356 | TBA2 | x | x | - | x | Q-Block2 | uint | 0-3 | (none) | 357 +--------+---+---+---+---+--------------+--------+--------+---------+ 359 Table 1: CoAP Q-Block1 and Q-Block2 Option Properties 361 The Q-Block1 and Q-Block2 Options can be present in both the request 362 and response messages. The Q-Block1 Option pertains to the request 363 payload and the Q-Block2 Option pertains to the response payload. 364 When the Content-Format Option is present together with the Q-Block1 365 or Q-Block2 Option, the option applies to the body not to the payload 366 (i.e., it must be the same for all payloads of the same body). 368 The Q-Block1 Option is useful with the payload-bearing, e.g., POST, 369 PUT, FETCH, PATCH, and iPATCH requests and their responses. 371 The Q-Block2 Option is useful, e.g., with GET, POST, PUT, FETCH, 372 PATCH, and iPATCH requests and their payload-bearing responses (2.01, 373 2.02, 2.04, and 2.05) (Section 5.5 of [RFC7252]). 375 A CoAP endpoint (or proxy) MUST support either both or neither of the 376 Q-Block1 and Q-Block2 Options. 378 If the Q-Block1 Option is present in a request or the Q-Block2 Option 379 is returned in a response, this indicates a block-wise transfer and 380 describes how this specific block-wise payload forms part of the 381 entire body being transferred. If it is present in the opposite 382 direction, it provides additional control on how that payload will be 383 formed or was processed. 385 To indicate support for Q-Block2 responses, the CoAP client MUST 386 include the Q-Block2 Option in a GET or similar request (FETCH, for 387 example), the Q-Block2 Option in a PUT or similar request (POST, for 388 example), or the Q-Block1 Option in a PUT or similar request so that 389 the server knows that the client supports this Q-Block functionality 390 should it need to send back a body that spans multiple payloads. 391 Otherwise, the server would use the Block2 Option (if supported) to 392 send back a message body that is too large to fit into a single IP 393 packet [RFC7959]. 395 How a client decides whether it needs to include a Q-Block1 or 396 Q-Block2 Option can be driven by a local configuration parameter, 397 triggered by an application (DOTS, for example), etc. Such 398 considerations are out of the scope of the document. 400 Implementation of the Q-Block1 and Q-Block2 Options is intended to be 401 optional. However, when it is present in a CoAP message, it MUST be 402 processed (or the message rejected). Therefore, Q-Block1 and 403 Q-Block2 Options are identified as Critical options. 405 With CoAP over UDP, the way a request message is rejected for 406 critical options depends on the message type. A Confirmable message 407 with an unrecognized critical option is rejected with a 4.02 (Bad 408 Option) response (Section 5.4.1 of [RFC7252]). A Non-confirmable 409 message with an unrecognized critical option is either rejected with 410 a Reset message or just silently ignored (Sections 5.4.1 and 4.3 of 411 [RFC7252]). To reliably get a rejection message, it is therefore 412 REQUIRED that clients use a Confirmable message for determining 413 support for Q-Block1 and Q-Block2 Options. This CON message can be 414 sent under base CoAP congestion control setup specified in 415 Section 4.7 of [RFC7252] (that is, NSTART does not need to be 416 increased (Section 7.1)). 418 The Q-Block1 and Q-Block2 Options are unsafe to forward. That is, a 419 CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option 420 MUST reject the request or response that uses either option. 422 The Q-Block2 Option is repeatable when requesting retransmission of 423 missing blocks, but not otherwise. Except that case, any request 424 carrying multiple Q-Block1 (or Q-Block2) Options MUST be handled 425 following the procedure specified in Section 5.4.5 of [RFC7252]. 427 The Q-Block1 and Q-Block2 Options, like the Block1 and Block2 428 Options, are of both class E and class U for OSCORE processing 429 (Table 2). The Q-Block1 (or Q-Block2) Option MAY be an Inner or 430 Outer option (Section 4.1 of [RFC8613]). The Inner and Outer values 431 are therefore independent of each other. The Inner option is 432 encrypted and integrity protected between clients and servers, and 433 provides message body identification in case of end-to-end 434 fragmentation of requests. The Outer option is visible to proxies 435 and labels message bodies in case of hop-by-hop fragmentation of 436 requests. 438 +--------+-----------------+---+---+ 439 | Number | Name | E | U | 440 +========+=================+===+===+ 441 | TBA1 | Q-Block1 | x | x | 442 | TBA2 | Q-Block2 | x | x | 443 +--------+-----------------+---+---+ 444 Table 2: OSCORE Protection of Q-Block1 and Q-Block2 Options 446 Note that if Q-Block1 or Q-Block2 Options are included in a packet as 447 Inner options, Block1 or Block2 Options MUST NOT be included as Inner 448 options. Similarly, there MUST NOT be a mix of Q-Block and Block for 449 the Outer options. Messages that do not adhere with this behavior 450 MUST be rejected with 4.02 (Bad Option). Q-Block and Block Options 451 can be mixed across Inner and Outer options as these are handled 452 independently of each other. For clarity, if OSCORE is not being 453 used, there MUST NOT be a mix of Q-Block and Block Options in the 454 same packet. 456 4.2. Structure of Q-Block1 and Q-Block2 Options 458 The structure of Q-Block1 and Q-Block2 Options follows the structure 459 defined in Section 2.2 of [RFC7959]. 461 There is no default value for the Q-Block1 and Q-Block2 Options. 462 Absence of one of these options is equivalent to an option value of 0 463 with respect to the value of block number (NUM) and more bit (M) that 464 could be given in the option, i.e., it indicates that the current 465 block is the first and only block of the transfer (block number is 466 set to 0, M is unset). However, in contrast to the explicit value 0, 467 which would indicate a size of the block (SZX) of 0, and thus a size 468 value of 16 bytes, there is no specific explicit size implied by the 469 absence of the option -- the size is left unspecified. (As for any 470 uint, the explicit value 0 is efficiently indicated by a zero-length 471 option; this, therefore, is different in semantics from the absence 472 of the option). 474 4.3. Using the Q-Block1 Option 476 The Q-Block1 Option is used when the client wants to send a large 477 amount of data to the server using the POST, PUT, FETCH, PATCH, or 478 iPATCH methods where the data and headers do not fit into a single 479 packet. 481 When Q-Block1 Option is used, the client MUST include a Request-Tag 482 Option [I-D.ietf-core-echo-request-tag]. The Request-Tag value MUST 483 be the same for all of the requests for the body of data that is 484 being transferred. The Request-Tag is opaque, but the client MUST 485 ensure that it is unique for every different body of transmitted 486 data. 488 Implementation Note: It is suggested that the client treats the 489 Request-Tag as an unsigned integer of 8 bytes in length. An 490 implementation may want to consider limiting this to 4 bytes to 491 reduce packet overhead size. The initial Request-Tag value should 492 be randomly generated and then subsequently incremented by the 493 client whenever a new body of data is being transmitted between 494 peers. 496 Section 4.6 discusses the use of Size1 Option. 498 For Confirmable transmission, the server continues to acknowledge 499 each packet, but a response is not required (whether separate or 500 piggybacked) until successful receipt of the body by the server. For 501 Non-confirmable transmission, no response is required until either 502 the successful receipt of the body by the server or a timer expires 503 with some of the payloads having not yet arrived. In the latter 504 case, a "retransmit missing payloads" response is needed. For 505 reliable transports (e.g., [RFC8323]), a response is not required 506 until successful receipt of the body by the server. 508 Each individual message that carries a block of the body is treated 509 as a new request (Section 6). 511 The client MUST send the payloads in order of increasing block 512 number, starting from zero, until the body is complete (subject to 513 any congestion control (Section 7)). Any missing payloads requested 514 by the server must in addition be separately transmitted with 515 increasing block numbers. 517 The following Response Codes are used: 519 2.01 (Created) 521 This Response Code indicates successful receipt of the entire body 522 and that the resource was created. The token to use MUST be one 523 of the tokens that were received in a request for this block-wise 524 exchange. However, it is desirable to provide the one used in the 525 last received request, since that will aid any troubleshooting. 526 The client should then release all of the tokens used for this 527 body. Note that the last received payload might not be the one 528 with the highest block number. 530 2.02 (Deleted) 532 This Response Code indicates successful receipt of the entire body 533 and that the resource was deleted when using POST (Section 5.8.2 534 [RFC7252]). The token to use MUST be one of the tokens that were 535 received in a request for this block-wise exchange. However, it 536 is desirable to provide the one used in the last received request. 537 The client should then release all of the tokens used for this 538 body. 540 2.04 (Changed) 542 This Response Code indicates successful receipt of the entire body 543 and that the resource was updated. The token to use MUST be one 544 of the tokens that were received in a request for this block-wise 545 exchange. However, it is desirable to provide the one used in the 546 last received request. The client should then release all of the 547 tokens used for this body. 549 2.05 (Content) 551 This Response Code indicates successful receipt of the entire 552 FETCH request body (Section 2 of [RFC8132]) and that the 553 appropriate representation of the resource is being returned. The 554 token to use MUST be one of the tokens that were received in a 555 request for this block-wise exchange. However, it is desirable to 556 provide the one used in the last received request. 558 If the FETCH request includes the Observe Option, then the server 559 MUST use the same token as used for the initial response for 560 returning any Observe triggered responses so that the client can 561 match them up. 563 The client should then release all of the tokens used for this 564 body unless a resource is being observed. 566 2.31 (Continue) 568 This Response Code can be used to indicate that all of the blocks 569 up to and including the Q-Block1 Option block NUM (all having the 570 M bit set) have been successfully received. The token to use MUST 571 be one of the tokens that were received in a request for this 572 block-wise exchange. However, it is desirable to provide the one 573 used in the last received request. 575 A response using this Response Code SHOULD NOT be generated for 576 every received Q-Block1 Option request (Section 7.2). It SHOULD 577 only be generated when all the payload requests are Non- 578 confirmable and a MAX_PAYLOADS_SET has been received by the 579 server. More details about the motivations for this optimization 580 are discussed in Section 7.2. 582 This Response Code SHOULD NOT be generated for CON. 584 4.00 (Bad Request) 586 This Response Code MUST be returned if the request does not 587 include a Request-Tag Option or a Size1 Option but does include a 588 Q-Block1 option. 590 4.02 (Bad Option) 592 This Response Code MUST be returned for a Confirmable request if 593 the server does not support the Q-Block Options. Note that a 594 reset message must be sent in case of Non-confirmable request. 596 4.08 (Request Entity Incomplete) 598 As a reminder, this Response Code returned without Content-Type 599 "application/missing-blocks+cbor-seq" (Section 12.3) is handled as 600 in Section 2.9.2 [RFC7959]. 602 This Response Code returned with Content-Type "application/ 603 missing-blocks+cbor-seq" indicates that some of the payloads are 604 missing and need to be resent. The client then retransmits the 605 individual missing payloads using the same Request-Tag, Size1, 606 and, Q-Block1 Option to specify the same NUM, SZX, and M bit as 607 sent initially in the original, but not received, packet. 609 The Request-Tag value to use is determined by taking the token in 610 the 4.08 (Request Entity Incomplete) response, locating the 611 matching client request, and then using its Request-Tag. 613 The token to use in the 4.08 (Request Entity Incomplete) response 614 MUST be one of the tokens that were received in a request for this 615 block-wise body exchange. However, it is desirable to provide the 616 one used in the last received request. See Section 5 for further 617 information. 619 If the server has not received all the blocks of a body, but one 620 or more NON payloads have been received, it SHOULD wait for 621 NON_RECEIVE_TIMEOUT (Section 7.2) before sending a 4.08 (Request 622 Entity Incomplete) response. 624 4.13 (Request Entity Too Large) 625 This Response Code can be returned under similar conditions to 626 those discussed in Section 2.9.3 of [RFC7959]. 628 This Response Code can be returned if there is insufficient space 629 to create a response PDU with a block size of 16 bytes (SZX = 0) 630 to send back all the response options as appropriate. In this 631 case, the Size1 Option is not included in the response. 633 Further considerations related to the transmission timings of 4.08 634 (Request Entity Incomplete) and 2.31 (Continue) Response Codes are 635 discussed in Section 7.2. 637 If a server receives payloads with different Request-Tags for the 638 same resource, it should continue to process all the bodies as it has 639 no way of determining which is the latest version, or which body, if 640 any, the client is terminating the transmission for. 642 If the client elects to stop the transmission of a complete body, and 643 absent any local policy, the client MUST "forget" all tracked tokens 644 associated with the body's Request-Tag so that a reset message is 645 generated for the invalid token in the 4.08 (Request Entity 646 Incomplete) response. The server on receipt of the reset message 647 SHOULD delete the partial body. 649 If the server receives a duplicate block with the same Request-Tag, 650 it MUST ignore the payload of the packet, but MUST still respond as 651 if the block was received for the first time. 653 A server SHOULD maintain a partial body (missing payloads) for 654 NON_PARTIAL_TIMEOUT (Section 7.2). 656 4.4. Using the Q-Block2 Option 658 In a request for any block number, the M bit unset indicates the 659 request is just for that block. If the M bit is set, this has 660 different meanings based on the NUM value: 662 NUM is zero: This is a request for the entire body. 664 'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero: This is 665 used to confirm that the current MAX_PAYLOADS_SET (the latest 666 block having block number NUM-1) has been successfully received 667 and that, upon receipt of this request, the server can continue to 668 send the next MAX_PAYLOADS_SET (the first block having block 669 number NUM). This is the 'Continue' Q-Block-2 and conceptually 670 has the same usage (i.e., continue sending the next set of data) 671 as the use of 2.31 (Continue) for Q-Block1. 673 Any other value of NUM: This is a request for that block and for all 674 of the remaining blocks in the current MAX_PAYLOADS_SET. 676 If the request includes multiple Q-Block2 Options and these options 677 overlap (e.g., combination of M being set (this and later blocks) and 678 being unset (this individual block)) resulting in an individual block 679 being requested multiple times, the server MUST only send back one 680 instance of that block. This behavior is meant to prevent 681 amplification attacks. 683 The payloads sent back from the server as a response MUST all have 684 the same ETag (Section 5.10.6 of [RFC7252]) for the same body. The 685 server MUST NOT use the same ETag value for different representations 686 of a resource. 688 The ETag is opaque, but the server MUST ensure that it is unique for 689 every different body of transmitted data. 691 Implementation Note: It is suggested that the server treats the 692 ETag as an unsigned integer of 8 bytes in length. An 693 implementation may want to consider limiting this to 4 bytes to 694 reduce packet overhead size. The initial ETag value should be 695 randomly generated and then subsequently incremented by the server 696 whenever a new body of data is being transmitted between peers. 698 Section 4.6 discusses the use of Size2 Option. 700 The client may elect to request any detected missing blocks or just 701 ignore the partial body. This decision is implementation specific. 703 For NON payloads, the client SHOULD wait NON_RECEIVE_TIMEOUT 704 (Section 7.2) after the last received payload before requesting 705 retransmission of any missing blocks. Retransmission is requested by 706 issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request that 707 contains one or more Q-Block2 Options that define the missing 708 block(s). Generally the M bit on the Q-Block2 Option(s) SHOULD be 709 unset, although the M bit MAY be set to request this and later blocks 710 from this MAX_PAYLOADS_SET, see Section 10.2.4 for an example of this 711 in operation. Further considerations related to the transmission 712 timing for missing requests are discussed in Section 7.2. 714 The missing block numbers requested by the client MUST have an 715 increasing block number in each additional Q-Block2 Option with no 716 duplicates. The server SHOULD respond with a 4.00 (Bad Request) to 717 requests not adhering to this behavior. Note that the ordering 718 constraint is meant to force the client to check for duplicates and 719 remove them. This also helps with troubleshooting. 721 For Confirmable responses, the client continues to acknowledge each 722 packet. Typically, the server acknowledges the initial request using 723 an ACK with the payload, and then sends the subsequent payloads as 724 CON responses. The server will detect failure to send a packet, but 725 the client can issue, after a MAX_TRANSMIT_SPAN delay, a separate 726 GET, POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as 727 needed. 729 If the client receives a duplicate block with the same ETag, it MUST 730 silently ignore the payload. 732 A client SHOULD maintain a partial body (missing payloads) for 733 NON_PARTIAL_TIMEOUT (Section 7.2) or as defined by the Max-Age Option 734 (or its default of 60 seconds (Section 5.6.1 of [RFC7252])), 735 whichever is the less. On release of the partial body, the client 736 should then release all of the tokens used for this body apart from 737 the token that is used to track a resource that is being observed. 739 The ETag Option should not be used in the request for missing blocks 740 as the server could respond with a 2.03 (Valid) response with no 741 payload. It can be used in the request if the client wants to check 742 the freshness of the locally cached body response. 744 The server SHOULD maintain a cached copy of the body when using the 745 Q-Block2 Option to facilitate retransmission of any missing payloads. 747 If the server detects part way through a body transfer that the 748 resource data has changed and the server is not maintaining a cached 749 copy of the old data, then the transmission is terminated. Any 750 subsequent missing block requests MUST be responded to using the 751 latest ETag and Size2 Option values with the updated data. 753 If the server responds during a body update with a different ETag 754 Option value (as the resource representation has changed), then the 755 client should treat the partial body with the old ETag as no longer 756 being fresh. The client may then request all of the new data by 757 specifying Q-Block2 with block number '0' and the M bit set. 759 If the server transmits a new body of data (e.g., a triggered Observe 760 notification) with a new ETag to the same client as an additional 761 response, the client should remove any partially received body held 762 for a previous ETag for that resource as it is unlikely the missing 763 blocks can be retrieved. 765 If there is insufficient space to create a response PDU with a block 766 size of 16 bytes (SZX = 0) to send back all the response options as 767 appropriate, a 4.13 (Request Entity Too Large) is returned without 768 the Size1 Option. 770 4.5. Using Observe Option 772 For a request that uses Q-Block1, the Observe value [RFC7641] MUST be 773 the same for all the payloads of the same body. This includes any 774 missing payloads that are retransmitted. 776 For a response that uses Q-Block2, the Observe value MUST be the same 777 for all the payloads of the same body. This is different from Block2 778 usage where the Observe value is only present in the first block 779 (Section 3.4 of [RFC7959]). This includes payloads transmitted 780 following receipt of the 'Continue' Q-Block2 Option (Section 4.4) by 781 the server. If a missing payload is requested by a client, then both 782 the request and response MUST NOT include the Observe Option. 784 4.6. Using Size1 and Size2 Options 786 Section 4 of [RFC7959] defines two CoAP options: Size1 for indicating 787 the size of the representation transferred in requests and Size2 for 788 indicating the size of the representation transferred in responses. 790 For Q-Block1 and Q-Block2 Options, the Size1 or Size2 Option values 791 MUST exactly represent the size of the data on the body so that any 792 missing data can easily be determined. 794 The Size1 Option MUST be used with the Q-Block1 Option when used in a 795 request and MUST be present in all payloads of the request, 796 preserving the same value. The Size2 Option MUST be used with the 797 Q-Block2 Option when used in a response and MUST be present in all 798 payloads of the response, preserving the same value. 800 4.7. Using Q-Block1 and Q-Block2 Options Together 802 The behavior is similar to the one defined in Section 3.3 of 803 [RFC7959] with Q-Block1 substituted for Block1 and Q-Block2 for 804 Block2. 806 4.8. Using Q-Block2 Option With Multicast 808 Servers MUST ignore multicast requests that contain the Q-Block2 809 Option. As a reminder, Block2 Option can be used as stated in 810 Section 2.8 of [RFC7959]. 812 5. The Use of 4.08 (Request Entity Incomplete) Response Code 814 4.08 (Request Entity Incomplete) Response Code has a new Content-Type 815 "application/missing-blocks+cbor-seq" used to indicate that the 816 server has not received all of the blocks of the request body that it 817 needs to proceed. Such messages must not be treated by the client as 818 a fatal error. 820 Likely causes are the client has not sent all blocks, some blocks 821 were dropped during transmission, or the client has sent them 822 sufficiently long ago that the server has already discarded them. 824 The data payload of the 4.08 (Request Entity Incomplete) response is 825 encoded as a CBOR Sequence [RFC8742]. It comprises one or more 826 missing block numbers encoded as CBOR unsigned integers [RFC8949]. 827 The missing block numbers MUST be unique in each 4.08 (Request Entity 828 Incomplete) response when created by the server; the client MUST 829 ignore any duplicates in the same 4.08 (Request Entity Incomplete) 830 response. 832 The Content-Format Option (Section 5.10.3 of [RFC7252]) MUST be used 833 in the 4.08 (Request Entity Incomplete) response. It MUST be set to 834 "application/missing-blocks+cbor-seq" (Section 12.3). 836 The Concise Data Definition Language [RFC8610] (and see Section 4.1 837 [RFC8742]) for the data describing these missing blocks is as 838 follows: 840 ; A notional array, the elements of which are to be used 841 ; in a CBOR Sequence: 842 payload = [+ missing-block-number] 843 ; A unique block number not received: 844 missing-block-number = uint 846 Figure 1: Structure of the Missing Blocks Payload 848 It is desirable that the token to use for the response is the token 849 that was used in the last block number received so far with the same 850 Request-Tag value. Note that the use of any received token with the 851 same Request-Tag would be acceptable, but providing the one used in 852 the last received payload will aid any troubleshooting. The client 853 will use the token to determine what was the previously sent request 854 to obtain the Request-Tag value that was used. 856 If the size of the 4.08 (Request Entity Incomplete) response packet 857 is larger than that defined by Section 4.6 [RFC7252], then the number 858 of reported missing blocks MUST be limited so that the response can 859 fit into a single packet. If this is the case, then the server can 860 send subsequent 4.08 (Request Entity Incomplete) responses containing 861 the missing other blocks on receipt of a new request providing a 862 missing payload with the same Request-Tag. 864 The missing blocks MUST be reported in ascending order without any 865 duplicates. The client SHOULD silently drop 4.08 (Request Entity 866 Incomplete) responses not adhering with this behavior. 868 Implementation Note: Consider limiting the number of missing 869 payloads to MAX_PAYLOADS to minimize congestion control being 870 needed. The CBOR sequence does not include any array wrapper. 872 The 4.08 (Request Entity Incomplete) with Content-Type "application/ 873 missing-blocks+cbor-seq" SHOULD NOT be used when using Confirmable 874 requests or a reliable connection [RFC8323] as the client will be 875 able to determine that there is a transmission failure of a 876 particular payload and hence that the server is missing that payload. 878 6. The Use of Tokens 880 Each new request generally uses a new Token (and sometimes must, see 881 Section 4 of [I-D.ietf-core-echo-request-tag]). Additional responses 882 to a request all use the token of the request they respond to. 884 Implementation Note: By using 8-byte tokens, it is possible to 885 easily minimize the number of tokens that have to be tracked by 886 clients, by keeping the bottom 32 bits the same for the same body 887 and the upper 32 bits containing the current body's request number 888 (incrementing every request, including every re-transmit). This 889 allows the client to be alleviated from keeping all the per- 890 request-state, e.g., in Section 3 of [RFC8974]. 892 7. Congestion Control for Unreliable Transports 894 The transmission of all the blocks of a single body over an 895 unreliable transport MUST either all be Confirmable or all be Non- 896 confirmable. This is meant to simplify the congestion control 897 procedure. 899 As a reminder, there is no need for CoAP-specific congestion control 900 for reliable transports [RFC8323]. 902 7.1. Confirmable (CON) 904 Congestion control for CON requests and responses is specified in 905 Section 4.7 of [RFC7252]. In order to benefit from faster 906 transmission rates, NSTART will need to be increased from 1. 907 However, the other CON congestion control parameters will need to be 908 tuned to cover this change. This tuning is not specified in this 909 document, given that the applicability scope of the current 910 specification assumes that all requests and responses using Q-Block1 911 and Q-Block2 will be Non-confirmable (Section 3.2) apart from the 912 initial Q-Block functionality negotiation. 914 Following the failure to transmit a packet due to packet loss after 915 MAX_TRANSMIT_SPAN time (Section 4.8.2 of [RFC7252]), it is 916 implementation specific as to whether there should be any further 917 requests for missing data. 919 7.2. Non-confirmable (NON) 921 This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT, 922 NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and 923 NON_PARTIAL_TIMEOUT primarily for use with NON (Table 3). 925 MAX_PAYLOADS should be configurable with a default value of 10. Both 926 CoAP endpoints SHOULD have the same value (otherwise there will be 927 transmission delays in one direction) and the value MAY be negotiated 928 between the endpoints to a common value by using a higher level 929 protocol (out of scope of this document). This is the maximum number 930 of payloads that can be transmitted at any one time. 932 Note: The default value of 10 is chosen for reasons similar to 933 those discussed in Section 5 of [RFC6928], especially given the 934 target application discussed in Section 3.2. 936 NON_TIMEOUT is the period of delay between sending MAX_PAYLOADS_SET 937 for the same body. By default, NON_TIMEOUT has the same value as 938 ACK_TIMEOUT (Section 4.8 of [RFC7252]). 940 NON_RECEIVE_TIMEOUT is the initial time to wait for a missing payload 941 before requesting retransmission for the first time. Every time the 942 missing payload is re-requested, the time to wait value doubles. The 943 time to wait is calculated as: 945 Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count - 1)) 947 NON_RECEIVE_TIMEOUT has a default value of twice NON_TIMEOUT. 948 NON_RECEIVE_TIMEOUT MUST always be greater than NON_TIMEOUT by at 949 least one second so that the sender of the payloads has the 950 opportunity to start sending the next MAX_PAYLOADS_SET before the 951 receiver times out. 953 NON_MAX_RETRANSMIT is the maximum number of times a request for the 954 retransmission of missing payloads can occur without a response from 955 the remote peer. After this occurs, the local endpoint SHOULD 956 consider the body stale, remove any body, and release Tokens and 957 Request-Tag on the client (or the ETag on the server). By default, 958 NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT (Section 4.8 959 of [RFC7252]). 961 NON_PROBING_WAIT is used to limit the potential wait needed when 962 using PROBING_RATE. By default, NON_PROBING_WAIT has the same value 963 as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). 965 NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. 966 By default, NON_PARTIAL_TIMEOUT has the same value as 967 EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). 969 +---------------------+---------------+ 970 | Parameter Name | Default Value | 971 +=====================+===============| 972 | MAX_PAYLOADS | 10 | 973 | NON_MAX_RETRANSMIT | 4 | 974 | NON_TIMEOUT | 2 s | 975 | NON_RECEIVE_TIMEOUT | 4 s | 976 | NON_PROBING_WAIT | 247 s | 977 | NON_PARTIAL_TIMEOUT | 247 s | 978 +---------------------+---------------+ 980 Table 3: Congestion Control Parameters 982 The PROBING_RATE parameter in CoAP indicates the average data rate 983 that must not be exceeded by a CoAP endpoint in sending to a peer 984 endpoint that does not respond. A single body will be subjected to 985 PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets. 986 If the wait time between sending bodies that are not being responded 987 to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time 988 is limited to NON_PROBING_WAIT. 990 Note: For the particular DOTS application, PROBING_RATE and other 991 transmission parameters are negotiated between peers. Even when 992 not negotiated, the DOTS application uses customized defaults as 993 discussed in Section 4.5.2 of [RFC8782]. Note that MAX_PAYLOADS, 994 NON_MAX_RETRANSMIT, NON_TIMEOUT, NON_PROBING_WAIT, and 995 NON_PARTIAL_TIMEOUT can be negotiated between DOTS peers, e.g., as 996 per [I-D.bosh-dots-quick-blocks]. 998 Each NON 4.08 (Request Entity Incomplete) response is subject to 999 PROBING_RATE. 1001 Each NON GET or FETCH request using a Q-Block2 Option is subject to 1002 PROBING_RATE. 1004 As the sending of many payloads of a single body may itself cause 1005 congestion, it is RECOMMENDED that after transmission of every 1006 MAX_PAYLOADS_SET of a single body, a delay is introduced of 1007 NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to manage 1008 potential congestion issues. 1010 If the CoAP peer reports that at least one payload has not arrived 1011 for each body for at least a 24-hour period and it is known that 1012 there are no other network issues over that period (e.g., DDoS 1013 attacks), then the value of MAX_PAYLOADS can be reduced by 1 at a 1014 time (to a minimum of 1) and the situation re-evaluated for another 1015 24-hour period until there is no report of missing payloads under 1016 normal operating conditions. Following a period of 24 hours where no 1017 packet recovery was required, the value of MAX_PAYLOADS can be 1018 increased by 1 (but without exceeding the default value) for a 1019 further 24-hour evaluation. The newly derived value for MAX_PAYLOADS 1020 should be used for both ends of this particular CoAP peer link. Note 1021 that the CoAP peer will not know about the MAX_PAYLOADS change until 1022 it is reconfigured. As a consequence of the two peers having 1023 different MAX_PAYLOADS values, a peer may continue indicating that 1024 there are some missing payloads as all of its MAX_PAYLOADS_SET may 1025 not have arrived. How the two peer values for MAX_PAYLOADS are 1026 synchronized is out of the scope. 1028 The sending of a set of missing blocks of a body is restricted to 1029 those in a MAX_PAYLOADS_SET at a time. In other words, a NON_TIMEOUT 1030 delay is still observed between each MAX_PAYLOAD_SET. 1032 For Q-Block1 Option, if the server responds with a 2.31 (Continue) 1033 Response Code for the latest payload sent, then the client can 1034 continue to send the next MAX_PAYLOADS_SET without any further delay. 1035 If the server responds with a 4.08 (Request Entity Incomplete) 1036 Response Code, then the missing payloads SHOULD be retransmitted 1037 before going into another NON_TIMEOUT delay prior to sending the next 1038 set of payloads. 1040 For the server receiving NON Q-Block1 requests, it SHOULD send back a 1041 2.31 (Continue) Response Code on receipt of all of the 1042 MAX_PAYLOADS_SET to prevent the client unnecessarily delaying. If 1043 not all of the MAX_PAYLOADS_SET were received, the server SHOULD 1044 delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the 1045 repeat request count for a payload) before sending the 4.08 (Request 1046 Entity Incomplete) Response Code for the missing payload(s). If all 1047 of the MAX_PAYLOADS_SET were received and a 2.31 (Continue) had been 1048 sent, but no more payloads were received for NON_RECEIVE_TIMEOUT 1049 (exponentially scaled), the server SHOULD send a 4.08 (Request Entity 1050 Incomplete) response detailing the missing payloads after the block 1051 number that was indicated in the sent 2.31 (Continue). If the repeat 1052 request count for the 4.08 (Request Entity Incomplete) exceeds 1053 NON_MAX_RETRANSMIT, the server SHOULD discard the partial body and 1054 stop requesting the missing payloads. 1056 It is likely that the client will start transmitting the next 1057 MAX_PAYLOADS_SET before the server times out on waiting for the last 1058 of the previous MAX_PAYLOADS_SET. On receipt of a payload from the 1059 next MAX_PAYLOADS_SET, the server SHOULD send a 4.08 (Request Entity 1060 Incomplete) Response Code indicating any missing payloads from any 1061 previous MAX_PAYLOADS_SET. Upon receipt of the 4.08 (Request Entity 1062 Incomplete) Response Code, the client SHOULD send the missing 1063 payloads before continuing to send the remainder of the 1064 MAX_PAYLOADS_SET and then go into another NON_TIMEOUT delay prior to 1065 sending the next MAX_PAYLOADS_SET. 1067 For the client receiving NON Q-Block2 responses, it SHOULD send a 1068 'Continue' Q-Block2 request (Section 4.4) for the next 1069 MAX_PAYLOADS_SET on receipt of all of the MAX_PAYLOADS_SET, to 1070 prevent the server unnecessarily delaying. Otherwise the client 1071 SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on 1072 the repeat request count for a payload), before sending the request 1073 for the missing payload(s). If the repeat request count for a 1074 missing payload exceeds NON_MAX_RETRANSMIT, the client SHOULD discard 1075 the partial body and stop requesting the missing payloads. 1077 The server SHOULD recognize the 'Continue' Q-Block2 request as a 1078 continue request and just continue the transmission of the body 1079 (including Observe Option, if appropriate for an unsolicited 1080 response) rather than as a request for the remaining missing blocks. 1082 It is likely that the server will start transmitting the next 1083 MAX_PAYLOADS_SET before the client times out on waiting for the last 1084 of the previous MAX_PAYLOADS_SET. Upon receipt of a payload from the 1085 new MAX_PAYLOADS_SET, the client SHOULD send a request indicating any 1086 missing payloads from any previous MAX_PAYLOADS_SET. Upon receipt of 1087 such request, the server SHOULD send the missing payloads before 1088 continuing to send the remainder of the MAX_PAYLOADS_SET and then go 1089 into another NON_TIMEOUT delay prior to sending the next 1090 MAX_PAYLOADS_SET. 1092 The client does not need to acknowledge the receipt of the entire 1093 body. 1095 Note: If there is asymmetric traffic loss causing responses to 1096 never get received, a delay of NON_TIMEOUT after every 1097 transmission of MAX_PAYLOADS_SET will be observed. The endpoint 1098 receiving the body is still likely to receive the entire body. 1100 8. Caching Considerations 1102 Caching block based information is not straight forward in a proxy. 1103 For Q-Block1 and Q-Block2 Options, for simplicity it is expected that 1104 the proxy will reassemble the body (using any appropriate recovery 1105 options for packet loss) before passing on the body to the 1106 appropriate CoAP endpoint. This does not preclude an implementation 1107 doing a more complex per payload caching, but how to do this is out 1108 of the scope of this document. The onward transmission of the body 1109 does not require the use of the Q-Block1 or Q-Block2 Options as these 1110 options may not be supported in that link. This means that the proxy 1111 must fully support the Q-Block1 and Q-Block2 Options. 1113 How the body is cached in the CoAP client (for Q-Block1 1114 transmissions) or the CoAP server (for Q-Block2 transmissions) is 1115 implementation specific. 1117 As the entire body is being cached in the proxy, the Q-Block1 and 1118 Q-Block2 Options are removed as part of the block assembly and thus 1119 do not reach the cache. 1121 For Q-Block2 responses, the ETag Option value is associated with the 1122 data (and onward transmitted to the CoAP client), but is not part of 1123 the cache key. 1125 For requests with Q-Block1 Option, the Request-Tag Option is 1126 associated with the build up of the body from successive payloads, 1127 but is not part of the cache key. For the onward transmission of the 1128 body using CoAP, a new Request-Tag SHOULD be generated and used. 1129 Ideally this new Request-Tag should replace the client's request 1130 Request-Tag. 1132 It is possible that two or more CoAP clients are concurrently 1133 updating the same resource through a common proxy to the same CoAP 1134 server using Q-Block1 (or Block1) Option. If this is the case, the 1135 first client to complete building the body causes that body to start 1136 transmitting to the CoAP server with an appropriate Request-Tag 1137 value. When the next client completes building the body, any 1138 existing partial body transmission to the CoAP server is terminated 1139 and the new body representation transmission starts with a new 1140 Request-Tag value. Note that it cannot be assumed that the proxy 1141 will always receive a complete body from a client. 1143 A proxy that supports Q-Block2 Option MUST be prepared to receive a 1144 GET or similar request indicating one or more missing blocks. The 1145 proxy will serve from its cache the missing blocks that are available 1146 in its cache in the same way a server would send all the appropriate 1147 Q-Block2 responses. If a body matching the cache key is not 1148 available in the cache, the proxy MUST request the entire body from 1149 the CoAP server using the information in the cache key. 1151 How long a CoAP endpoint (or proxy) keeps the body in its cache is 1152 implementation specific (e.g., it may be based on Max-Age). 1154 9. HTTP-Mapping Considerations 1156 As a reminder, the basic normative requirements on HTTP/CoAP mappings 1157 are defined in Section 10 of [RFC7252]. The implementation 1158 guidelines for HTTP/CoAP mappings are elaborated in [RFC8075]. 1160 The rules defined in Section 5 of [RFC7959] are to be followed. 1162 10. Examples with Non-confirmable Messages 1164 This section provides some sample flows to illustrate the use of 1165 Q-Block1 and Q-Block2 Options with NON. Examples with CON are 1166 provided in Appendix A. 1168 The examples in the following subsections assume MAX_PAYLOADS is set 1169 to 10 and NON_MAX_RETRANSMIT is set to 4. 1171 Figure 2 lists the conventions that are used in the following 1172 subsections. 1174 T: Token value 1175 O: Observe Option value 1176 M: Message ID 1177 RT: Request-Tag 1178 ET: ETag 1179 QB1: Q-Block1 Option values NUM/More/Size 1180 QB2: Q-Block2 Option values NUM/More/Size 1181 Size: Actual block size encoded in SZX 1182 \: Trimming long lines 1183 [[]]: Comments 1184 -->X: Message loss (request) 1185 X<--: Message loss (response) 1186 ...: Passage of time 1187 Payload N: Corresponds to the CoAP message that conveys 1188 a block number (N-1) of a given block-wise exchange. 1190 Figure 2: Notations Used in the Figures 1192 10.1. Q-Block1 Option 1194 10.1.1. A Simple Example 1196 Figure 3 depicts an example of a NON PUT request conveying Q-Block1 1197 Option. All the blocks are received by the server. 1199 CoAP CoAP 1200 Client Server 1201 | | 1202 +--------->| NON PUT /path M:0x81 T:0xc0 RT=9 QB1:0/1/1024 1203 +--------->| NON PUT /path M:0x82 T:0xc1 RT=9 QB1:1/1/1024 1204 +--------->| NON PUT /path M:0x83 T:0xc2 RT=9 QB1:2/1/1024 1205 +--------->| NON PUT /path M:0x84 T:0xc3 RT=9 QB1:3/0/1024 1206 |<---------+ NON 2.04 M:0xf1 T:0xc3 1207 | ... | 1209 Figure 3: Example of NON Request with Q-Block1 Option (Without Loss) 1211 10.1.2. Handling MAX_PAYLOADS Limits 1213 Figure 4 depicts an example of a NON PUT request conveying Q-Block1 1214 Option. The number of payloads exceeds MAX_PAYLOADS. All the blocks 1215 are received by the server. 1217 CoAP CoAP 1218 Client Server 1219 | | 1220 +--------->| NON PUT /path M:0x01 T:0xf1 RT=10 QB1:0/1/1024 1221 +--------->| NON PUT /path M:0x02 T:0xf2 RT=10 QB1:1/1/1024 1222 +--------->| [[Payloads 3 - 9 not detailed]] 1223 +--------->| NON PUT /path M:0x0a T:0xfa RT=10 QB1:9/1/1024 1224 [[MAX_PAYLOADS_SET has been received]] 1225 | [[MAX_PAYLOADS_SET receipt acknowledged by server]] 1226 |<---------+ NON 2.31 M:0x81 T:0xfa 1227 +--------->| NON PUT /path M:0x0b T:0xfb RT=10 QB1:10/0/1024 1228 |<---------+ NON 2.04 M:0x82 T:0xfb 1229 | ... | 1231 Figure 4: Example of MAX_PAYLOADS NON Request with Q-Block1 Option 1232 (Without Loss) 1234 10.1.3. Handling MAX_PAYLOADS with Recovery 1236 Consider now a scenario where a new body of data is to be sent by the 1237 client, but some blocks are dropped in transmission as illustrated in 1238 Figure 5. 1240 CoAP CoAP 1241 Client Server 1242 | | 1243 +--------->| NON PUT /path M:0x11 T:0xe1 RT=11 QB1:0/1/1024 1244 +--->X | NON PUT /path M:0x12 T:0xe2 RT=11 QB1:1/1/1024 1245 +--------->| [[Payloads 3 - 8 not detailed]] 1246 +--------->| NON PUT /path M:0x19 T:0xe9 RT=11 QB1:8/1/1024 1247 +--->X | NON PUT /path M:0x1a T:0xea RT=11 QB1:9/1/1024 1248 [[Some of MAX_PAYLOADS_SET have been received]] 1249 | ... | 1250 [[NON_TIMEOUT (client) delay expires]] 1251 | [[Client starts sending next MAX_PAYLOAD_SET]] 1252 +--->X | NON PUT /path M:0x1b T:0xeb RT=11 QB1:10/1/1024 1253 +--------->| NON PUT /path M:0x1c T:0xec RT=11 QB1:11/1/1024 1254 | | 1256 Figure 5: Example of MAX_PAYLOADS NON Request with Q-Block1 Option 1257 (With Loss) 1259 On seeing a payload from the next MAX_PAYLOAD_SET, the server 1260 realizes that some blocks are missing from the previous 1261 MAX_PAYLOADS_SET and asks for the missing blocks in one go 1262 (Figure 6). It does so by indicating which blocks from the previous 1263 MAX_PAYLOADS_SET have not been received in the data portion of the 1264 response (Section 5). The token used in the response should be the 1265 token that was used in the last received payload. The client can 1266 then derive the Request-Tag by matching the token with the sent 1267 request. 1269 CoAP CoAP 1270 Client Server 1271 | | 1272 |<---------+ NON 4.08 M:0x91 T:0xec [Missing 1,9] 1273 | [[Client responds with missing payloads]] 1274 +--------->| NON PUT /path M:0x1d T:0xed RT=11 QB1:1/1/1024 1275 +--------->| NON PUT /path M:0x1e T:0xee RT=11 QB1:9/1/1024 1276 | [[Client continues sending next MAX_PAYLOAD_SET]] 1277 +--------->| NON PUT /path M:0x1f T:0xef RT=11 QB1:12/0/1024 1278 | ... | 1279 [[NON_RECEIVE_TIMEOUT (server) delay expires]] 1280 | [[The server realizes a block is still missing and asks 1281 | for the missing one]] 1282 |<---------+ NON 4.08 M:0x92 T:0xef [Missing 10] 1283 +--------->| NON PUT /path M:0x20 T:0xf0 RT=11 QB1:10/1/1024 1284 |<---------+ NON 2.04 M:0x93 T:0xf0 1285 | ... | 1287 Figure 6: Example of NON Request with Q-Block1 Option (Blocks 1288 Recovery) 1290 10.1.4. Handling Recovery with Failure 1292 Figure 7 depicts an example of a NON PUT request conveying Q-Block1 1293 Option where recovery takes place, but eventually fails. 1295 CoAP CoAP 1296 Client Server 1297 | | 1298 +--------->| NON PUT /path M:0x91 T:0xd0 RT=12 QB1:0/1/1024 1299 +--->X | NON PUT /path M:0x92 T:0xd1 RT=12 QB1:1/1/1024 1300 +--------->| NON PUT /path M:0x93 T:0xd2 RT=12 QB1:2/0/1024 1301 | ... | 1302 [[NON_RECEIVE_TIMEOUT (server) delay expires]] 1303 | [[The server realizes a block is missing and asks 1304 | for the missing one. Retry #1]] 1305 |<---------+ NON 4.08 M:0x01 T:0xd2 [Missing 1] 1306 | ... | 1307 [[2 * NON_RECEIVE_TIMEOUT (server) delay expires]] 1308 | [[The server realizes a block is still missing and asks 1309 | for the missing one. Retry #2]] 1310 |<---------+ NON 4.08 M:0x02 T:0xd2 [Missing 1] 1311 | ... | 1312 [[4 * NON_RECEIVE_TIMEOUT (server) delay expires]] 1313 | [[The server realizes a block is still missing and asks 1314 | for the missing one. Retry #3]] 1315 |<---------+ NON 4.08 M:0x03 T:0xd2 [Missing 1] 1316 | ... | 1317 [[8 * NON_RECEIVE_TIMEOUT (server) delay expires]] 1318 | [[The server realizes a block is still missing and asks 1319 | for the missing one. Retry #4]] 1320 |<---------+ NON 4.08 M:0x04 T:0xd2 [Missing 1] 1321 | ... | 1322 [[16 * NON_RECEIVE_TIMEOUT (server) delay expires]] 1323 | [[NON_MAX_RETRANSMIT exceeded. Server stops requesting 1324 | for missing blocks and releases partial body]] 1325 | ... | 1327 Figure 7: Example of NON Request with Q-Block1 Option (With Eventual 1328 Failure) 1330 10.2. Q-Block2 Option 1332 These examples include the Observe Option to demonstrate how that 1333 option is used. Note that the Observe Option is not required for 1334 Q-Block2; the observe detail can thus be ignored. 1336 10.2.1. A Simple Example 1338 Figure 8 illustrates the example of Q-Block2 Option. The client 1339 sends a NON GET carrying Observe and Q-Block2 Options. The Q-Block2 1340 Option indicates a block size hint (1024 bytes). This request is 1341 replied to by the server using four (4) blocks that are transmitted 1342 to the client without any loss. Each of these blocks carries a 1343 Q-Block2 Option. The same process is repeated when an Observe is 1344 triggered, but no loss is experienced by any of the notification 1345 blocks. 1347 CoAP CoAP 1348 Client Server 1349 | | 1350 +--------->| NON GET /path M:0x01 T:0xc0 O:0 QB2:0/1/1024 1351 |<---------+ NON 2.05 M:0xf1 T:0xc0 O:1220 ET=19 QB2:0/1/1024 1352 |<---------+ NON 2.05 M:0xf2 T:0xc0 O:1220 ET=19 QB2:1/1/1024 1353 |<---------+ NON 2.05 M:0xf3 T:0xc0 O:1220 ET=19 QB2:2/1/1024 1354 |<---------+ NON 2.05 M:0xf4 T:0xc0 O:1220 ET=19 QB2:3/0/1024 1355 | ... | 1356 | [[Observe triggered]] 1357 |<---------+ NON 2.05 M:0xf5 T:0xc0 O:1221 ET=20 QB2:0/1/1024 1358 |<---------+ NON 2.05 M:0xf6 T:0xc0 O:1221 ET=20 QB2:1/1/1024 1359 |<---------+ NON 2.05 M:0xf7 T:0xc0 O:1221 ET=20 QB2:2/1/1024 1360 |<---------+ NON 2.05 M:0xf8 T:0xc0 O:1221 ET=20 QB2:3/0/1024 1361 | ... | 1363 Figure 8: Example of NON Notifications with Q-Block2 Option (Without 1364 Loss) 1366 10.2.2. Handling MAX_PAYLOADS Limits 1368 Figure 9 illustrates the same as Figure 8 but this time has eleven 1369 (11) payloads which exceeds MAX_PAYLOADS. There is no loss 1370 experienced. 1372 CoAP CoAP 1373 Client Server 1374 | | 1375 +--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024 1376 |<---------+ NON 2.05 M:0x81 T:0xf0 O:1234 ET=21 QB2:0/1/1024 1377 |<---------+ NON 2.05 M:0x82 T:0xf0 O:1234 ET=21 QB2:1/1/1024 1378 |<---------+ [[Payloads 3 - 9 not detailed]] 1379 |<---------+ NON 2.05 M:0x8a T:0xf0 O:1234 ET=21 QB2:9/1/1024 1380 [[MAX_PAYLOADS_SET has been received]] 1381 | [[MAX_PAYLOADS_SET acknowledged by client using 1382 | 'Continue' Q-Block2]] 1383 +--------->| NON GET /path M:0x02 T:0xf1 QB2:10/1/1024 1384 |<---------+ NON 2.05 M:0x8b T:0xf0 O:1234 ET=21 QB2:10/0/1024 1385 | ... | 1386 | [[Observe triggered]] 1387 |<---------+ NON 2.05 M:0x91 T:0xf0 O:1235 ET=22 QB2:0/1/1024 1388 |<---------+ NON 2.05 M:0x92 T:0xf0 O:1235 ET=22 QB2:1/1/1024 1389 |<---------+ [[Payloads 3 - 9 not detailed]] 1390 |<---------+ NON 2.05 M:0x9a T:0xf0 O:1235 ET=22 QB2:9/1/1024 1391 [[MAX_PAYLOADS_SET has been received]] 1392 | [[MAX_PAYLOADS_SET acknowledged by client using 1393 | 'Continue' Q-Block2]] 1394 +--------->| NON GET /path M:0x03 T:0xf2 QB2:10/1/1024 1395 |<---------+ NON 2.05 M:0x9b T:0xf0 O:1235 ET=22 QB2:10/0/1024 1396 [[Body has been received]] 1397 | ... | 1399 Figure 9: Example of NON Notifications with Q-Block2 Option (Without 1400 Loss) 1402 10.2.3. Handling MAX_PAYLOADS with Recovery 1404 Figure 10 shows the example of an Observe that is triggered but for 1405 which some notification blocks are lost. The client detects the 1406 missing blocks and requests their retransmission. It does so by 1407 indicating the blocks that are missing as one or more Q-Block2 1408 Options. 1410 CoAP CoAP 1411 Client Server 1412 | ... | 1413 | [[Observe triggered]] 1414 |<---------+ NON 2.05 M:0xa1 T:0xf0 O:1236 ET=23 QB2:0/1/1024 1415 | X<---+ NON 2.05 M:0xa2 T:0xf0 O:1236 ET=23 QB2:1/1/1024 1416 |<---------+ [[Payloads 3 - 9 not detailed]] 1417 | X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024 1418 [[Some of MAX_PAYLOADS_SET have been received]] 1419 | ... | 1420 [[NON_TIMEOUT (server) delay expires]] 1421 | [[Server sends next MAX_PAYLOAD_SET]] 1422 |<---------+ NON 2.05 M:0xab T:0xf0 O:1236 ET=23 QB2:10/0/1024 1423 | [[On seeing a payload from the next MAX_PAYLOAD_SET, 1424 | Client realizes blocks are missing and asks for the 1425 | missing ones in one go]] 1426 +--------->| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\ 1427 | | QB2:9/0/1024 1428 | X<---+ NON 2.05 M:0xac T:0xf3 ET=23 QB2:1/1/1024 1429 |<---------+ NON 2.05 M:0xad T:0xf3 ET=23 QB2:9/1/1024 1430 | ... | 1431 [[NON_RECEIVE_TIMEOUT (client) delay expires]] 1432 | [[Client realizes block is still missing and asks for 1433 | missing block]] 1434 +--------->| NON GET /path M:0x05 T:0xf4 QB2:1/0/1024 1435 |<---------+ NON 2.05 M:0xae T:0xf4 ET=23 QB2:1/1/1024 1436 [[Body has been received]] 1437 | ... | 1439 Figure 10: Example of NON Notifications with Q-Block2 Option (Blocks 1440 Recovery) 1442 10.2.4. Handling Recovery using M-bit Set 1444 Figure 11 shows the example of an Observe that is triggered but only 1445 the first two notification blocks reach the client. In order to 1446 retrieve the missing blocks, the client sends a request with a single 1447 Q-Block2 Option with the M bit set. 1449 CoAP CoAP 1450 Client Server 1451 | ... | 1452 | [[Observe triggered]] 1453 |<---------+ NON 2.05 M:0xb1 T:0xf0 O:1237 ET=24 QB2:0/1/1024 1454 |<---------+ NON 2.05 M:0xb2 T:0xf0 O:1237 ET=24 QB2:1/1/1024 1455 | X<---+ NON 2.05 M:0xb3 T:0xf0 O:1237 ET=24 QB2:2/1/1024 1456 | X<---+ [[Payloads 4 - 9 not detailed]] 1457 | X<---+ NON 2.05 M:0xb9 T:0xf0 O:1237 ET=24 QB2:9/1/1024 1458 [[Some of MAX_PAYLOADS_SET have been received]] 1459 | ... | 1460 [[NON_TIMEOUT (server) delay expires]] 1461 | [[Server sends next MAX_PAYLOAD_SET]] 1462 | X<---+ NON 2.05 M:0xba T:0xf0 O:1237 ET=24 QB2:10/0/1024 1463 | ... | 1464 [[NON_RECEIVE_TIMEOUT (client) delay expires]] 1465 | [[Client realizes blocks are missing and asks for the 1466 | missing ones in one go by setting the M bit]] 1467 +--------->| NON GET /path M:0x06 T:0xf5 QB2:2/1/1024 1468 |<---------+ NON 2.05 M:0xbb T:0xf5 ET=24 QB2:2/1/1024 1469 |<---------+ [[Payloads 3 - 9 not detailed]] 1470 |<---------+ NON 2.05 M:0xc2 T:0xf5 ET=24 QB2:9/1/1024 1471 [[MAX_PAYLOADS_SET has been received]] 1472 | [[MAX_PAYLOADS_SET acknowledged by client using 'Continue' 1473 | Q-Block2]] 1474 +--------->| NON GET /path M:0x87 T:0xf6 QB2:10/1/1024 1475 |<---------+ NON 2.05 M:0xc3 T:0xf0 O:1237 ET=24 QB2:10/0/1024 1476 [[Body has been received]] 1477 | ... | 1479 Figure 11: Example of NON Notifications with Q-Block2 Option (Blocks 1480 Recovery with M bit Set) 1482 10.3. Q-Block1 and Q-Block2 Options 1484 10.3.1. A Simple Example 1486 Figure 12 illustrates the example of a FETCH using both Q-Block1 and 1487 Q-Block2 Options along with an Observe Option. No loss is 1488 experienced. 1490 CoAP CoAP 1491 Client Server 1492 | | 1493 +--------->| NON FETCH /path M:0x10 T:0x90 O:0 RT=30 QB1:0/1/1024 1494 +--------->| NON FETCH /path M:0x11 T:0x91 O:0 RT=30 QB1:1/1/1024 1495 +--------->| NON FETCH /path M:0x12 T:0x93 O:0 RT=30 QB1:2/0/1024 1496 |<---------+ NON 2.05 M:0x60 T:0x93 O:1320 ET=90 QB2:0/1/1024 1497 |<---------+ NON 2.05 M:0x61 T:0x93 O:1320 ET=90 QB2:1/1/1024 1498 |<---------+ NON 2.05 M:0x62 T:0x93 O:1320 ET=90 QB2:2/1/1024 1499 |<---------+ NON 2.05 M:0x63 T:0x93 O:1320 ET=90 QB2:3/0/1024 1500 | ... | 1501 | [[Observe triggered]] 1502 |<---------+ NON 2.05 M:0x64 T:0x93 O:1321 ET=91 QB2:0/1/1024 1503 |<---------+ NON 2.05 M:0x65 T:0x93 O:1321 ET=91 QB2:1/1/1024 1504 |<---------+ NON 2.05 M:0x66 T:0x93 O:1321 ET=91 QB2:2/1/1024 1505 |<---------+ NON 2.05 M:0x67 T:0x93 O:1321 ET=91 QB2:3/0/1024 1506 | ... | 1508 Figure 12: Example of NON FETCH with Q-Block1 and Q-Block2 Options 1509 (Without Loss) 1511 10.3.2. Handling MAX_PAYLOADS Limits 1513 Figure 13 illustrates the same as Figure 12 but this time has eleven 1514 (11) payloads in both directions which exceeds MAX_PAYLOADS. There 1515 is no loss experienced. 1517 CoAP CoAP 1518 Client Server 1519 | | 1520 +--------->| NON FETCH /path M:0x30 T:0xa0 O:0 RT=10 QB1:0/1/1024 1521 +--------->| NON FETCH /path M:0x31 T:0xa1 O:0 RT=10 QB1:1/1/1024 1522 +--------->| [[Payloads 3 - 9 not detailed]] 1523 +--------->| NON FETCH /path M:0x39 T:0xa9 O:0 RT=10 QB1:9/1/1024 1524 [[MAX_PAYLOADS_SET has been received]] 1525 | [[MAX_PAYLOADS_SET acknowledged by server]] 1526 |<---------+ NON 2.31 M:0x80 T:0xa9 1527 +--------->| NON FETCH /path M:0x3a T:0xaa O:0 RT=10 QB1:10/0/1024 1528 |<---------+ NON 2.05 M:0x81 T:0xaa O:1334 ET=21 QB2:0/1/1024 1529 |<---------+ NON 2.05 M:0x82 T:0xaa O:1334 ET=21 QB2:1/1/1024 1530 |<---------+ [[Payloads 3 - 9 not detailed]] 1531 |<---------+ NON 2.05 M:0x8a T:0xaa O:1334 ET=21 QB2:9/1/1024 1532 [[MAX_PAYLOADS_SET has been received]] 1533 | [[MAX_PAYLOADS_SET acknowledged by client using 1534 | 'Continue' Q-Block2]] 1535 +--------->| NON FETCH /path M:0x3b T:0xab QB2:10/1/1024 1536 |<---------+ NON 2.05 M:0x8b T:0xaa O:1334 ET=21 QB2:10/0/1024 1537 | ... | 1538 | [[Observe triggered]] 1539 |<---------+ NON 2.05 M:0x8c T:0xaa O:1335 ET=22 QB2:0/1/1024 1540 |<---------+ NON 2.05 M:0x8d T:0xaa O:1335 ET=22 QB2:1/1/1024 1541 |<---------+ [[Payloads 3 - 9 not detailed]] 1542 |<---------+ NON 2.05 M:0x95 T:0xaa O:1335 ET=22 QB2:9/1/1024 1543 [[MAX_PAYLOADS_SET has been received]] 1544 | [[MAX_PAYLOADS_SET acknowledged by client using 1545 | 'Continue' Q-Block2]] 1546 +--------->| NON FETCH /path M:0x3c T:0xac QB2:10/1/1024 1547 |<---------+ NON 2.05 M:0x96 T:0xaa O:1335 ET=22 QB2:10/0/1024 1548 [[Body has been received]] 1549 | ... | 1551 Figure 13: Example of NON FETCH with Q-Block1 and Q-Block2 Options 1552 (Without Loss) 1554 Note that as 'Continue' was used, the server continues to use the 1555 same token (0xaa) since the 'Continue' is not being used as a request 1556 for a new set of packets, but rather is being used to instruct the 1557 server to continue its transmission (Section 7.2). 1559 10.3.3. Handling Recovery 1561 Consider now a scenario where some blocks are lost in transmission as 1562 illustrated in Figure 14. 1564 CoAP CoAP 1565 Client Server 1566 | | 1567 +--------->| NON FETCH /path M:0x50 T:0xc0 O:0 RT=31 QB1:0/1/1024 1568 +--->X | NON FETCH /path M:0x51 T:0xc1 O:0 RT=31 QB1:1/1/1024 1569 +--->X | NON FETCH /path M:0x52 T:0xc2 O:0 RT=31 QB1:2/1/1024 1570 +--------->| NON FETCH /path M:0x53 T:0xc3 O:0 RT=31 QB1:3/0/1024 1571 | ... | 1572 [[NON_RECEIVE_TIMEOUT (server) delay expires]] 1574 Figure 14: Example of NON FETCH with Q-Block1 and Q-Block2 Options 1575 (With Loss) 1577 The server realizes that some blocks are missing and asks for the 1578 missing blocks in one go (Figure 15). It does so by indicating which 1579 blocks have not been received in the data portion of the response. 1580 The token used in the response is the token that was used in the last 1581 received payload. The client can then derive the Request-Tag by 1582 matching the token with the sent request. 1584 CoAP CoAP 1585 Client Server 1586 | | 1587 |<---------+ NON 4.08 M:0xa0 T:0xc3 [Missing 1,2] 1588 | [[Client responds with missing payloads]] 1589 +--------->| NON FETCH /path M:0x54 T:0xc4 O:0 RT=31 QB1:1/1/1024 1590 +--------->| NON FETCH /path M:0x55 T:0xc5 O:0 RT=31 QB1:2/1/1024 1591 | [[Server received FETCH body, 1592 | starts transmitting response body]] 1593 |<---------+ NON 2.05 M:0xa1 T:0xc3 O:1236 ET=23 QB2:0/1/1024 1594 | X<---+ NON 2.05 M:0xa2 T:0xc3 O:1236 ET=23 QB2:1/1/1024 1595 |<---------+ NON 2.05 M:0xa3 T:0xc3 O:1236 ET=23 QB2:2/1/1024 1596 | X<---+ NON 2.05 M:0xa4 T:0xc3 O:1236 ET=23 QB2:3/0/1024 1597 | ... | 1598 [[NON_RECEIVE_TIMEOUT (client) delay expires]] 1599 | | 1601 Figure 15: Example of NON Request with Q-Block1 Option (Server 1602 Recovery) 1604 The client realizes that not all the payloads of the response have 1605 been returned. The client then asks for the missing blocks in one go 1606 (Figure 16). Note that, following Section 2.7 of [RFC7959], the 1607 FETCH request does not include the Q-Block1 or any payload. 1609 CoAP CoAP 1610 Client Server 1611 | | 1612 +--------->| NON FETCH /path M:0x56 T:0xc6 RT=31 QB2:1/0/1024\ 1613 | | QB2:3/0/1024 1614 | [[Server receives FETCH request for missing payloads, 1615 | starts transmitting missing blocks]] 1616 | X<---+ NON 2.05 M:0xa5 T:0xc6 ET=23 QB2:1/1/1024 1617 |<---------+ NON 2.05 M:0xa6 T:0xc6 ET=23 QB2:3/0/1024 1618 | ... | 1619 [[NON_RECEIVE_TIMEOUT (client) delay expires]] 1620 | [[Client realizes block is still missing and asks for 1621 | missing block]] 1622 +--------->| NON FETCH /path M:0x57 T:0xc7 RT=31 QB2:1/0/1024 1623 | [[Server receives FETCH request for missing payload, 1624 | starts transmitting missing block]] 1625 |<---------+ NON 2.05 M:0xa7 T:0xc7 ET=23 QB2:1/1/1024 1626 [[Body has been received]] 1627 | ... | 1628 | [[Observe triggered]] 1629 |<---------+ NON 2.05 M:0xa8 T:0xc3 O:1337 ET=24 QB2:0/1/1024 1630 | X<---+ NON 2.05 M:0xa9 T:0xc3 O:1337 ET=24 QB2:1/1/1024 1631 |<---------+ NON 2.05 M:0xaa T:0xc3 O:1337 ET=24 QB2:2/0/1024 1632 [[NON_RECEIVE_TIMEOUT (client) delay expires]] 1633 | [[Client realizes block is still missing and asks for 1634 | missing block]] 1635 +--------->| NON FETCH /path M:0x58 T:0xc8 RT=31 QB2:1/0/1024 1636 | [[Server receives FETCH request for missing payload, 1637 | starts transmitting missing block]] 1638 |<---------+ NON 2.05 M:0xa7 T:0xc8 ET=24 QB2:1/1/1024 1639 [[Body has been received]] 1640 | ... | 1642 Figure 16: Example of NON Request with Q-Block1 Option (Client 1643 Recovery) 1645 11. Security Considerations 1647 Security considerations discussed in Section 7 of [RFC7959] should be 1648 taken into account. 1650 Security considerations discussed in Sections 11.3 and 11.4 of 1651 [RFC7252] should be taken into account. 1653 OSCORE provides end-to-end protection of all information that is not 1654 required for proxy operations and requires that a security context is 1655 set up (Section 3.1 of [RFC8613]). It can be trusted that the source 1656 endpoint is legitimate even if NoSec security mode is used. However, 1657 an intermediary node can modify the unprotected outer Q-Block1 and/or 1658 Q-Block2 Options to cause a Q-Block transfer to fail or keep 1659 requesting all the blocks by setting the M bit and, thus, causing 1660 attack amplification. As discussed in Section 12.1 of [RFC8613], 1661 applications need to consider that certain message fields and 1662 messages types are not protected end-to-end and may be spoofed or 1663 manipulated. Therefore, it is NOT RECOMMENDED to use the NoSec 1664 security mode if either the Q-Block1 or Q-Block2 Options is used. 1666 Security considerations related to the use of Request-Tag are 1667 discussed in Section 5 of [I-D.ietf-core-echo-request-tag]. 1669 12. IANA Considerations 1671 RFC Editor Note: Please replace [RFCXXXX] with the RFC number to be 1672 assigned to this document. 1674 12.1. CoAP Option Numbers Registry 1676 IANA is requested to add the following entries to the "CoAP Option 1677 Numbers" sub-registry [Options] defined in [RFC7252] within the 1678 "Constrained RESTful Environments (CoRE) Parameters" registry: 1680 +--------+------------------+-----------+ 1681 | Number | Name | Reference | 1682 +========+==================+===========+ 1683 | TBA1 | Q-Block1 | [RFCXXXX] | 1684 | TBA2 | Q-Block2 | [RFCXXXX] | 1685 +--------+------------------+-----------+ 1687 Table 4: CoAP Q-Block1 and Q-Block2 Option Numbers 1689 This document suggests 19 (TBA1) and 31 (TBA2) as values to be 1690 assigned for the new option numbers. 1692 12.2. Media Type Registration 1694 This document requests IANA to register the "application/missing- 1695 blocks+cbor-seq" media type in the "Media Types" registry 1696 [IANA-MediaTypes]. This registration follows the procedures 1697 specified in [RFC6838]: 1699 Type name: application 1701 Subtype name: missing-blocks+cbor-seq 1703 Required parameters: N/A 1705 Optional parameters: N/A 1707 Encoding considerations: Must be encoded as a CBOR 1708 sequence [RFC8742], as defined in Section 4 of [RFCXXXX]. 1710 Security considerations: See Section 10 of [RFCXXXX]. 1712 Interoperability considerations: N/A 1714 Published specification: [RFCXXXX] 1716 Applications that use this media type: Data serialization and 1717 deserialization. In particular, the type is used by applications 1718 relying upon block-wise transfers, allowing a server to specify 1719 non-received blocks and request for their retransmission, as 1720 defined in Section 4 of [RFCXXXX]. 1722 Fragment identifier considerations: N/A 1724 Additional information: N/A 1726 Person & email address to contact for further information: IETF, 1727 iesg@ietf.org 1729 Intended usage: COMMON 1731 Restrictions on usage: none 1733 Author: See Authors' Addresses section. 1735 Change controller: IESG 1737 Provisional registration? No 1739 12.3. CoAP Content-Formats Registry 1741 This document requests IANA to register the following CoAP Content- 1742 Format for the "application/missing-blocks+cbor-seq" media type in 1743 the "CoAP Content-Formats" registry [Format], defined in [RFC7252], 1744 within the "Constrained RESTful Environments (CoRE) Parameters" 1745 registry: 1747 o Media Type: application/missing-blocks+cbor-seq 1748 o Encoding: - 1749 o Id: TBA3 1750 o Reference: [RFCXXXX] 1752 This document suggests 272 (TBA3) as a value to be assigned for the 1753 new content format number. 1755 13. References 1757 13.1. Normative References 1759 [I-D.ietf-core-echo-request-tag] 1760 Amsuess, C., Mattsson, J. P., and G. Selander, "CoAP: 1761 Echo, Request-Tag, and Token Processing", draft-ietf-core- 1762 echo-request-tag-12 (work in progress), February 2021. 1764 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1765 Requirement Levels", BCP 14, RFC 2119, 1766 DOI 10.17487/RFC2119, March 1997, 1767 . 1769 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1770 Specifications and Registration Procedures", BCP 13, 1771 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1772 . 1774 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1775 Application Protocol (CoAP)", RFC 7252, 1776 DOI 10.17487/RFC7252, June 2014, 1777 . 1779 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1780 Application Protocol (CoAP)", RFC 7641, 1781 DOI 10.17487/RFC7641, September 2015, 1782 . 1784 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1785 the Constrained Application Protocol (CoAP)", RFC 7959, 1786 DOI 10.17487/RFC7959, August 2016, 1787 . 1789 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 1790 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 1791 the Constrained Application Protocol (CoAP)", RFC 8075, 1792 DOI 10.17487/RFC8075, February 2017, 1793 . 1795 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 1796 FETCH Methods for the Constrained Application Protocol 1797 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 1798 . 1800 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1801 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1802 May 2017, . 1804 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1805 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 1806 Application Protocol) over TCP, TLS, and WebSockets", 1807 RFC 8323, DOI 10.17487/RFC8323, February 2018, 1808 . 1810 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1811 "Object Security for Constrained RESTful Environments 1812 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1813 . 1815 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 1816 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 1817 . 1819 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1820 Representation (CBOR)", STD 94, RFC 8949, 1821 DOI 10.17487/RFC8949, December 2020, 1822 . 1824 13.2. Informative References 1826 [Format] "CoAP Content-Formats", . 1829 [I-D.bosh-dots-quick-blocks] 1830 Boucadair, M. and J. Shallow, "Distributed Denial-of- 1831 Service Open Threat Signaling (DOTS) Signal Channel 1832 Configuration Attributes for Faster Block Transmission", 1833 draft-bosh-dots-quick-blocks-01 (work in progress), 1834 January 2021. 1836 [I-D.ietf-dots-telemetry] 1837 Boucadair, M., Reddy, T., Doron, E., Chen, M., and J. 1838 Shallow, "Distributed Denial-of-Service Open Threat 1839 Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15 1840 (work in progress), December 2020. 1842 [IANA-MediaTypes] 1843 IANA, "Media Types", 1844 . 1846 [Options] "CoAP Option Numbers", . 1849 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 1850 "Increasing TCP's Initial Window", RFC 6928, 1851 DOI 10.17487/RFC6928, April 2013, 1852 . 1854 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 1855 Bose, "Constrained Application Protocol (CoAP) Option for 1856 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 1857 August 2016, . 1859 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1860 Definition Language (CDDL): A Notational Convention to 1861 Express Concise Binary Object Representation (CBOR) and 1862 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1863 June 2019, . 1865 [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., 1866 Mortensen, A., and N. Teague, "Distributed Denial-of- 1867 Service Open Threat Signaling (DOTS) Signal Channel 1868 Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, 1869 . 1871 [RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and 1872 Stateless Clients in the Constrained Application Protocol 1873 (CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021, 1874 . 1876 Appendix A. Examples with Confirmable Messages 1878 The following examples assume NSTART has been increased to 3. 1880 The notations provided in Figure 2 are used in the following 1881 subsections. 1883 A.1. Q-Block1 Option 1885 Let's now consider the use of Q-Block1 Option with a CON request as 1886 shown in Figure 17. All the blocks are acknowledged (ACK). 1888 CoAP CoAP 1889 Client Server 1890 | | 1891 +--------->| CON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024 1892 +--------->| CON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024 1893 +--------->| CON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024 1894 [[NSTART(3) limit reached]] 1895 |<---------+ ACK 0.00 M:0x01 1896 +--------->| CON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024 1897 |<---------+ ACK 0.00 M:0x02 1898 |<---------+ ACK 0.00 M:0x03 1899 |<---------+ ACK 2.04 M:0x04 1900 | | 1902 Figure 17: Example of CON Request with Q-Block1 Option (Without Loss) 1904 Now, suppose that a new body of data is to be sent but with some 1905 blocks dropped in transmission as illustrated in Figure 18. The 1906 client will retry sending blocks for which no ACK was received. 1908 CoAP CoAP 1909 Client Server 1910 | | 1911 +--------->| CON PUT /path M:0x05 T:0xf4 RT=11 QB1:0/1/1024 1912 +--->X | CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 1913 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 1914 [[NSTART(3) limit reached]] 1915 |<---------+ ACK 0.00 M:0x05 1916 +--------->| CON PUT /path M:0x08 T:0xf7 RT=11 QB1:3/1/1024 1917 |<---------+ ACK 0.00 M:0x08 1918 | ... | 1919 [[ACK_TIMEOUT (client) for M:0x06 delay expires]] 1920 | [[Client retransmits packet]] 1921 +--------->| CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 1922 [[ACK_TIMEOUT (client) for M:0x07 delay expires]] 1923 | [[Client retransmits packet]] 1924 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 1925 |<---------+ ACK 0.00 M:0x06 1926 | ... | 1927 [[ACK_TIMEOUT exponential backoff (client) delay expires]] 1928 | [[Client retransmits packet]] 1929 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 1930 | ... | 1931 [[Either body transmission failure (acknowledge retry timeout) 1932 or successfully transmitted.]] 1934 Figure 18: Example of CON Request with Q-Block1 Option (Blocks 1935 Recovery) 1937 It is up to the implementation as to whether the application process 1938 stops trying to send this particular body of data on reaching 1939 MAX_RETRANSMIT for any payload, or separately tries to initiate the 1940 new transmission of the payloads that have not been acknowledged 1941 under these adverse traffic conditions. 1943 If there is likely to be the possibility of transient network losses, 1944 then the use of NON should be considered. 1946 A.2. Q-Block2 Option 1948 An example of the use of Q-Block2 Option with Confirmable messages is 1949 shown in Figure 19. 1951 Client Server 1952 | | 1953 +--------->| CON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024 1954 |<---------+ ACK 2.05 M:0x01 T:0xf0 O:1234 ET=21 QB2:0/1/1024 1955 |<---------+ CON 2.05 M:0xe1 T:0xf0 O:1234 ET=21 QB2:1/1/1024 1956 |<---------+ CON 2.05 M:0xe2 T:0xf0 O:1234 ET=21 QB2:2/1/1024 1957 |<---------+ CON 2.05 M:0xe3 T:0xf0 O:1234 ET=21 QB2:3/0/1024 1958 |--------->+ ACK 0.00 M:0xe1 1959 |--------->+ ACK 0.00 M:0xe2 1960 |--------->+ ACK 0.00 M:0xe3 1961 | ... | 1962 | [[Observe triggered]] 1963 |<---------+ CON 2.05 M:0xe4 T:0xf0 O:1235 ET=22 QB2:0/1/1024 1964 |<---------+ CON 2.05 M:0xe5 T:0xf0 O:1235 ET=22 QB2:1/1/1024 1965 |<---------+ CON 2.05 M:0xe6 T:0xf0 O:1235 ET=22 QB2:2/1/1024 1966 [[NSTART(3) limit reached]] 1967 |--------->+ ACK 0.00 M:0xe4 1968 |<---------+ CON 2.05 M:0xe7 T:0xf0 O:1235 ET=22 QB2:3/0/1024 1969 |--------->+ ACK 0.00 M:0xe5 1970 |--------->+ ACK 0.00 M:0xe6 1971 |--------->+ ACK 0.00 M:0xe7 1972 | ... | 1973 | [[Observe triggered]] 1974 |<---------+ CON 2.05 M:0xe8 T:0xf0 O:1236 ET=23 QB2:0/1/1024 1975 | X<---+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 1976 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 1977 [[NSTART(3) limit reached]] 1978 |--------->+ ACK 0.00 M:0xe8 1979 |<---------+ CON 2.05 M:0xeb T:0xf0 O:1236 ET=23 QB2:3/0/1024 1980 |--------->+ ACK 0.00 M:0xeb 1981 | ... | 1982 [[ACK_TIMEOUT (server) for M:0xe9 delay expires]] 1983 | [[Server retransmits packet]] 1984 |<---------+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 1985 [[ACK_TIMEOUT (server) for M:0xea delay expires]] 1986 | [[Server retransmits packet]] 1987 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 1988 |--------->+ ACK 0.00 M:0xe9 1989 | ... | 1990 [[ACK_TIMEOUT exponential backoff (server) delay expires]] 1991 | [[Server retransmits packet]] 1992 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 1993 | ... | 1994 [[Either body transmission failure (acknowledge retry timeout) 1995 or successfully transmitted.]] 1997 Figure 19: Example of CON Notifications with Q-Block2 Option 1999 It is up to the implementation as to whether the application process 2000 stops trying to send this particular body of data on reaching 2001 MAX_RETRANSMIT for any payload, or separately tries to initiate the 2002 new transmission of the payloads that have not been acknowledged 2003 under these adverse traffic conditions. 2005 If there is likely to be the possibility of transient network losses, 2006 then the use of NON should be considered. 2008 Appendix B. Examples with Reliable Transports 2010 The notations provided in Figure 2 are used in the following 2011 subsections. 2013 B.1. Q-Block1 Option 2015 Let's now consider the use of Q-Block1 Option with a reliable 2016 transport as shown in Figure 20. There is no acknowledgment of 2017 packets at the CoAP layer, just the final result. 2019 CoAP CoAP 2020 Client Server 2021 | | 2022 +--------->| PUT /path T:0xf0 RT=10 QB1:0/1/1024 2023 +--------->| PUT /path T:0xf1 RT=10 QB1:1/1/1024 2024 +--------->| PUT /path T:0xf2 RT=10 QB1:2/1/1024 2025 +--------->| PUT /path T:0xf3 RT=10 QB1:3/0/1024 2026 |<---------+ 2.04 2027 | | 2029 Figure 20: Example of Reliable Request with Q-Block1 Option 2031 If there is likely to be the possibility of transient network losses, 2032 then the use of unreliable transport with NON should be considered. 2034 B.2. Q-Block2 Option 2036 An example of the use of Q-Block2 Option with a reliable transport is 2037 shown in Figure 21. 2039 Client Server 2040 | | 2041 +--------->| GET /path T:0xf0 O:0 QB2:0/1/1024 2042 |<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:0/1/1024 2043 |<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:1/1/1024 2044 |<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:2/1/1024 2045 |<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:3/0/1024 2046 | ... | 2047 | [[Observe triggered]] 2048 |<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:0/1/1024 2049 |<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:1/1/1024 2050 |<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:2/1/1024 2051 |<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:3/0/1024 2052 | ... | 2054 Figure 21: Example of Notifications with Q-Block2 Option 2056 If there is likely to be the possibility of network transient losses, 2057 then the use of unreliable transport with NON should be considered. 2059 Acknowledgements 2061 Thanks to Achim Kraus, Jim Schaad, and Michael Richardson for their 2062 comments. 2064 Special thanks to Christian Amsuess, Carsten Bormann, and Marco 2065 Tiloca for their suggestions and several reviews, which improved this 2066 specification significantly. Thanks to Francesca Palombini for the 2067 AD review. 2069 Thanks to Pete Resnick for the Gen-ART review, Colin Perkins for the 2070 Tsvart review, and Emmanuel Baccelli for the Iotdir review. Thanks 2071 to Martin Duke, Eric Vyncke, Benjamin Kaduk, Roman Danyliw, and John 2072 Scudder for the IESG review. 2074 Some text from [RFC7959] is reused for readers convenience. 2076 Authors' Addresses 2078 Mohamed Boucadair 2079 Orange 2080 Rennes 35000 2081 France 2083 Email: mohamed.boucadair@orange.com 2084 Jon Shallow 2085 United Kingdom 2087 Email: supjps-ietf@jpshallow.com