idnits 2.17.1 draft-ietf-core-new-block-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 13, 2021) is 1200 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 1549, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-11 == Outdated reference: A later version (-03) exists of draft-bosh-dots-quick-blocks-00 == 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: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CORE M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track J. Shallow 5 Expires: July 17, 2021 January 13, 2021 7 Constrained Application Protocol (CoAP) Block-Wise Transfer Options for 8 Faster Transmission 9 draft-ietf-core-new-block-05 11 Abstract 13 This document specifies alternative Constrained Application Protocol 14 (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. 16 These options are similar to the CoAP Block1 and Block2 Options, not 17 a replacement for them, but do enable faster transmission rates for 18 large amounts of data with less packet interchanges as well as 19 supporting faster recovery should any of the blocks get lost in 20 transmission. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 17, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Alternative CoAP Block-Wise Transfer Options . . . . . . 3 58 1.2. CoAP Response Code (4.08) Usage . . . . . . . . . . . . . 5 59 1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 5 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. The Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 6 62 3.1. Properties of Q-Block1 and Q-Block2 Options . . . . . . . 6 63 3.2. Structure of Q-Block1 and Q-Block2 Options . . . . . . . 8 64 3.3. Using the Q-Block1 Option . . . . . . . . . . . . . . . . 9 65 3.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 12 66 3.5. Using Observe and Q-Block1 Options . . . . . . . . . . . 14 67 3.6. Using Observe and Q-Block2 Options . . . . . . . . . . . 15 68 3.7. Using Size1 and Size2 Options . . . . . . . . . . . . . . 15 69 3.8. Using Q-Block1 and Q-Block2 Options Together . . . . . . 15 70 4. The Use of 4.08 (Request Entity Incomplete) Response Code . . 15 71 5. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 17 72 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 17 73 6.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 17 74 6.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 18 75 7. Caching Considerations . . . . . . . . . . . . . . . . . . . 21 76 8. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 22 77 9. Examples with Non-confirmable Messages . . . . . . . . . . . 22 78 9.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 23 79 9.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 23 80 9.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 23 81 9.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . . 24 82 9.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 25 83 9.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 25 84 9.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 26 85 9.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . . 27 86 9.2.4. Handling Recovery using M-bit Set . . . . . . . . . . 28 87 9.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 29 88 9.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 29 89 9.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 30 90 9.3.3. Handling Recovery . . . . . . . . . . . . . . . . . . 31 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 92 10.1. New CoAP Options . . . . . . . . . . . . . . . . . . . . 33 93 10.2. New Media Type . . . . . . . . . . . . . . . . . . . . . 34 94 10.3. New Content Format . . . . . . . . . . . . . . . . . . . 35 95 11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 96 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 97 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 98 13.1. Normative References . . . . . . . . . . . . . . . . . . 36 99 13.2. Informative References . . . . . . . . . . . . . . . . . 38 100 Appendix A. Examples with Confirmable Messages . . . . . . . . . 39 101 A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 39 102 A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 40 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 105 1. Introduction 107 The Constrained Application Protocol (CoAP) [RFC7252], although 108 inspired by HTTP, was designed to use UDP instead of TCP. The 109 message layer of CoAP over UDP includes support for reliable 110 delivery, simple congestion control, and flow control. [RFC7959] 111 introduced the CoAP Block1 and Block2 Options to handle data records 112 that cannot fit in a single IP packet, so not having to rely on IP 113 fragmentation and was further updated by [RFC8323] for use over TCP, 114 TLS, and WebSockets. 116 The CoAP Block1 and Block2 Options work well in environments where 117 there are no or minimal packet losses. These options operate 118 synchronously where each individual block has to be requested and can 119 only ask for (or send) the next block when the request for the 120 previous block has completed. Packet, and hence block transmission 121 rate, is controlled by Round Trip Times (RTTs). 123 There is a requirement for these blocks of data to be transmitted at 124 higher rates under network conditions where there may be asymmetrical 125 transient packet loss (i.e., responses may get dropped). An example 126 is when a network is subject to a Distributed Denial of Service 127 (DDoS) attack and there is a need for DDoS mitigation agents relying 128 upon CoAP to communicate with each other (e.g., 129 [I-D.ietf-dots-telemetry]). As a reminder, [RFC7959] recommends the 130 use of Confirmable (CON) responses to handle potential packet loss. 131 However, such a recommendation does not work with a flooded pipe DDoS 132 situation. 134 1.1. Alternative CoAP Block-Wise Transfer Options 136 This document introduces the CoAP Q-Block1 and Q-Block2 Options. 137 These options are similar in operation to the CoAP Block1 and Block2 138 Options, respectively. They are not a replacement for them, but have 139 the following benefits: 141 o They can operate in environments where packet loss is highly 142 asymmetrical. 144 o They enable faster transmissions of sets of blocks of data with 145 less packet interchanges. 147 o They support faster recovery should any of the blocks get lost in 148 transmission. 150 o They support sending an entire body using Non-confirmable (NON) 151 without requiring a response from the peer. 153 There are the following disadvantages over using CoAP Block1 and 154 Block2 Options: 156 o Loss of lock-stepping so payloads are not always received in the 157 correct (block ascending) order. 159 o Additional congestion control measures need to be put in place for 160 NON (Section 6.2). 162 o To reduce the transmission times for CON transmission of large 163 bodies, NSTART needs to be increased from 1, but this affects 164 congestion control where other parameters need to be tuned 165 (Section 4.7 of [RFC7252]). Such tuning is out of scope of this 166 document. 168 Using NON messages, the faster transmissions occur as all the blocks 169 can be transmitted serially (as are IP fragmented packets) without 170 having to wait for a response or next request from the remote CoAP 171 peer. Recovery of missing blocks is faster in that multiple missing 172 blocks can be requested in a single CoAP packet. Even if there is 173 asymmetrical packet loss, a body can still be sent and received by 174 the peer whether the body comprises of a single or multiple payloads 175 assuming no recovery is required. 177 Note that similar performance benefits can be applied to Confirmable 178 messages if the value of NSTART is increased from 1 (Section 4.7 of 179 [RFC7252]). However, the use of Confirmable messages will not work 180 if there is asymmetrical packet loss. Some examples with Confirmable 181 messages are provided in Appendix A. 183 There is little, if any, benefit of using these options with CoAP 184 running over a reliable connection [RFC8323]. In this case, there is 185 no differentiation between Confirmable and NON as they are not used. 187 A CoAP endpoint can acknowledge all or a subset of the blocks. 188 Concretely, the receiving CoAP endpoint informs the CoAP sender 189 endpoint either successful receipt or reports on all blocks in the 190 body that have not yet been received. The CoAP sender endpoint will 191 then retransmit only the blocks that have been lost in transmission. 193 Q-Block1 and Q-Block2 Options can be used instead of Block1 and 194 Block2 Options when the different transmission properties are 195 required. If the new option is not supported by a peer, then 196 transmissions can fall back to using Block1 and Block2 Options, 197 respectively. 199 The deviations from Block1 and Block2 Options are specified in 200 Section 3. Pointers to appropriate [RFC7959] sections are provided. 202 The specification refers to the base CoAP methods defined in 203 Section 5.8 of [RFC7252] and the new CoAP methods, FETCH, PATCH, and 204 iPATCH introduced in [RFC8132]. 206 Q-Block1 and Q-Block2 Options are designed to work with Non- 207 confirmable requests and responses, in particular. 209 1.2. CoAP Response Code (4.08) Usage 211 This document adds a media type for the 4.08 (Request Entity 212 Incomplete) response defining an additional message format for 213 reporting on payloads using the Q-Block1 Option that are not received 214 by the server. 216 See Section 4 for more details. 218 1.3. Applicability Scope 220 The block-wise transfer specified in [RFC7959] covers the general 221 case, but falls short in situations where packet loss is highly 222 asymmetrical. The mechanism specified in this document provides 223 roughly similar features to the Block1/Block2 Options. It provides 224 additional properties that are tailored towards the intended use case 225 of Non-Confirmable transmission. Concretely, this mechanism 226 primarily targets applications such as DDoS Open Threat Signaling 227 (DOTS) that can't use Confirmable (CON) responses to handle potential 228 packet loss and that support application-specific mechanisms to 229 assess whether the remote peer is able to handle the messages sent by 230 a CoAP endpoint (e.g., DOTS heartbeats in Section 4.7 of [RFC8782]). 232 The mechanism includes guards to prevent a CoAP agent from 233 overloading the network by adopting an aggressive sending rate. 234 These guards MUST be followed in addition to the existing CoAP 235 congestion control as specified in Section 4.7 of [RFC7252]. See 236 Section 6 for more details. 238 This mechanism is not intended for general CoAP usage, and any use 239 outside the intended use case should be carefully weighed against the 240 loss of interoperability with generic CoAP applications. It is hoped 241 that the experience gained with this mechanism can feed future 242 extensions of the block-wise mechanism that will both be generally 243 applicable and serve this particular use case. 245 It is not recommended that these options are used in a NoSec security 246 mode (Section 9 of [RFC7252]) as the source endpoint needs to be 247 trusted. Using OSCORE [RFC8613] does provide a security context and, 248 hence, a trust of the source endpoint. However, using a NoSec 249 security mode may still be inadequate for reasons discussed in 250 Section 11. 252 2. Terminology 254 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 255 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 256 "OPTIONAL" in this document are to be interpreted as described in BCP 257 14 [RFC2119][RFC8174] when, and only when, they appear in all 258 capitals, as shown here. 260 Readers should be familiar with the terms and concepts defined in 261 [RFC7252]. 263 The terms "payload" and "body" are defined in [RFC7959]. The term 264 "payload" is thus used for the content of a single CoAP message 265 (i.e., a single block being transferred), while the term "body" is 266 used for the entire resource representation that is being transferred 267 in a block-wise fashion. 269 3. The Q-Block1 and Q-Block2 Options 271 3.1. Properties of Q-Block1 and Q-Block2 Options 273 The properties of Q-Block1 and Q-Block2 Options are shown in Table 1. 274 The formatting of this table follows the one used in Table 4 of 275 [RFC7252] (Section 5.10). The C, U, N, and R columns indicate the 276 properties Critical, UnSafe, NoCacheKey, and Repeatable defined in 277 Section 5.4 of [RFC7252]. Only Critical and UnSafe columns are 278 marked for the Q-Block1 Option. Critical, UnSafe, and Repeatable 279 columns are marked for the Q-Block2 Option. As these options are 280 UnSafe, NoCacheKey has no meaning and so is marked with a dash. 282 +--------+---+---+---+---+--------------+--------+--------+---------+ 283 | Number | C | U | N | R | Name | Format | Length | Default | 284 +========+===+===+===+===+==============+========+========+=========+ 285 | TBA1 | x | x | - | | Q-Block1 | uint | 0-3 | (none) | 286 | TBA2 | x | x | - | x | Q-Block2 | uint | 0-3 | (none) | 287 +--------+---+---+---+---+--------------+--------+--------+---------+ 289 Table 1: CoAP Q-Block1 and Q-Block2 Option Properties 291 The Q-Block1 and Q-Block2 Options can be present in both the request 292 and response messages. The Q-Block1 Option pertains to the request 293 payload and the Q-Block2 Option pertains to the response payload. 294 The Content-Format Option applies to the body, not to the payload 295 (i.e., it must be the same for all payloads of the same body). 297 Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH, 298 PATCH, and iPATCH requests and their responses. 300 Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and 301 iPATCH requests and their payload-bearing responses (2.01, 2.02, 302 2.03, 2.04, and 2.05) (Section 5.5 of [RFC7252]). 304 However, with methods needing both Q-Block1 for the request and 305 Q-Block2 for the response, and there is need for recovery following 306 payload loss, the numbers of packets needed to initiate and complete 307 the recovery can get very large as a function of the severity of the 308 experienced loss. 310 A CoAP endpoint (or proxy) MUST support either both or neither of the 311 Q-Block1 and Q-Block2 Options. 313 If Q-Block1 Option is present in a request or Q-Block2 Option in a 314 response (i.e., in that message to the payload of which it pertains), 315 it indicates a block-wise transfer and describes how this specific 316 block-wise payload forms part of the entire body being transferred. 317 If it is present in the opposite direction, it provides additional 318 control on how that payload will be formed or was processed. 320 To indicate support for Q-Block2 responses, the CoAP client MUST 321 include the Q-Block2 Option in a GET or similar request, the Q-Block2 322 Option in a PUT or similar request, or the Q-Block1 Option in a PUT 323 or similar so that the server knows that the client supports this 324 Q-Block2 functionality should it need to send back a body that spans 325 multiple payloads. Otherwise, the server would use the Block2 Option 326 (if supported) to send back a message body that is too large to fit 327 into a single IP packet [RFC7959]. 329 Implementation of the Q-Block1 and Q-Block2 Options is intended to be 330 optional. However, when it is present in a CoAP message, it MUST be 331 processed (or the message rejected). Therefore, Q-Block1 and 332 Q-Block2 Options are identified as Critical options. 334 With CoAP over UDP, the way a request message is rejected for 335 critical options depends on the message type. A Confirmable message 336 with an unrecognized critical option is rejected with a 4.02 (Bad 337 Option) response (Section 5.4.1 of [RFC7252]). A Non-confirmable 338 message with an unrecognized critical option is either rejected with 339 a Reset message or just silently ignored (Sections 5.4.1 and 4.3 of 340 [RFC7252]). To reliably get a rejection message, it is therefore 341 REQUIRED that clients use a Confirmable message for determining 342 support for Q-Block1 and Q-Block2 Options. 344 The Q-Block1 and Q-Block2 Options are unsafe to forward. That is, a 345 CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option 346 MUST reject the request or response that uses either option. 348 The Q-Block2 Option is repeatable when requesting retransmission of 349 missing blocks, but not otherwise. Except that case, any request 350 carrying multiple Q-Block1 (or Q-Block2) Options MUST be handled 351 following the procedure specified in Section 5.4.5 of [RFC7252]. 353 The Q-Block1 and Q-Block2 Options, like the Block1 and Block2 354 Options, are both a class E and a class U in terms of OSCORE 355 processing (Table 2). The Q-Block1 (or Q-Block2) Option MAY be an 356 Inner or Outer option (Section 4.1 of [RFC8613]). The Inner and 357 Outer values are therefore independent of each other. The Inner 358 option is encrypted and integrity protected between clients and 359 servers, and provides message body identification in case of end-to- 360 end fragmentation of requests. The Outer option is visible to 361 proxies and labels message bodies in case of hop-by-hop fragmentation 362 of requests. 364 +--------+-----------------+---+---+ 365 | Number | Name | E | U | 366 +========+=================+===+===+ 367 | TBA1 | Q-Block1 | x | x | 368 | TBA2 | Q-Block2 | x | x | 369 +--------+-----------------+---+---+ 370 Table 2: OSCORE Protection of Q-Block1 and Q-Block2 Options 372 3.2. Structure of Q-Block1 and Q-Block2 Options 374 The structure of Q-Block1 and Q-Block2 Options follows the structure 375 defined in Section 2.2 of [RFC7959]. 377 There is no default value for the Q-Block1 and Q-Block2 Options. 378 Absence of one of these options is equivalent to an option value of 0 379 with respect to the value of block number (NUM) and more bit (M) that 380 could be given in the option, i.e., it indicates that the current 381 block is the first and only block of the transfer (block number is 382 set to 0, M is unset). However, in contrast to the explicit value 0, 383 which would indicate a size of the block (SZX) of 0, and thus a size 384 value of 16 bytes, there is no specific explicit size implied by the 385 absence of the option -- the size is left unspecified. (As for any 386 uint, the explicit value 0 is efficiently indicated by a zero-length 387 option; this, therefore, is different in semantics from the absence 388 of the option). 390 3.3. Using the Q-Block1 Option 392 The Q-Block1 Option is used when the client wants to send a large 393 amount of data to the server using the POST, PUT, FETCH, PATCH, or 394 iPATCH methods where the data and headers do not fit into a single 395 packet. 397 When Q-Block1 Option is used, the client MUST include a Request-Tag 398 Option [I-D.ietf-core-echo-request-tag]. The Request-Tag value MUST 399 be the same for all of the requests for the body of data that is 400 being transferred. It is also used to identify a particular payload 401 of a body that needs to be retransmitted. The Request-Tag is opaque, 402 the server still treats it as opaque but the client SHOULD ensure 403 that it is unique for every different body of transmitted data. 405 Implementation Note: It is suggested that the client treats the 406 Request-Tag as an unsigned integer of 8 bytes in length. An 407 implementation may want to consider limiting this to 4 bytes to 408 reduce packet overhead size. The initial Request-Tag value should 409 be randomly generated and then subsequently incremented by the 410 client whenever a new body of data is being transmitted between 411 peers. 413 Section 3.7 discusses the use of Size1 Option. 415 For Confirmable transmission, the server continues to acknowledge 416 each packet, but a response is not required (whether separate or 417 piggybacked) until successful receipt of the body or, if some of the 418 payloads are sent as Non-confirmable and have not arrived, a 419 retransmit missing payloads response is needed. 421 Each individual payload of the body is treated as a new request 422 (Section 5). 424 The client MUST send the payloads with the block numbers increasing, 425 starting from zero, until the body is complete (subject to any 426 congestion control (Section 6)). Any missing payloads requested by 427 the server must in addition be separately transmitted with increasing 428 block numbers. 430 The following Response Codes are used: 432 2.01 (Created) 434 This Response Code indicates successful receipt of the entire body 435 and the resource was created. The token used SHOULD be from the 436 last received payload. The client should then release all of the 437 tokens used for this body. 439 2.02 (Deleted) 441 This Response Code indicates successful receipt of the entire body 442 and the resource was deleted when using POST (Section 5.8.2 443 [RFC7252]). The token used SHOULD be from the last received 444 payload. The client should then release all of the tokens used 445 for this body. 447 2.04 (Changed) 449 This Response Code indicates successful receipt of the entire body 450 and the resource was updated. The token used SHOULD be from the 451 last received payload. The client should then release all of the 452 tokens used for this body. 454 2.05 (Content) 456 This Response Code indicates successful receipt of the entire 457 FETCH request body (Section 2 of [RFC8132]) and the appropriate 458 representation of the resource has been returned. The token used 459 in the response MUST be the one in the FETCH request that has the 460 Q-Block1 with the M bit unset. If the FETCH request includes the 461 Observe Option, then the server MUST use the same token for 462 returning any Observe triggered responses. The client should then 463 release all of the tokens used for this body unless a resource is 464 being observed. 466 2.31 (Continue) 468 This Response Code can be used to indicate that all of the blocks 469 up to and including the Q-Block1 Option block NUM (all having the 470 M bit set) in the response have been successfully received. The 471 token used SHOULD be from the last received payload. 473 A response using this Response Code SHOULD NOT be generated for 474 every received Q-Block1 Option request. It SHOULD only be 475 generated when all the payload requests are Non-confirmable and 476 MAX_PAYLOADS (Section 6.2) payloads have been received by the 477 server. 479 It SHOULD NOT be generated for CON. 481 4.00 (Bad Request) 483 This Response Code MUST be returned if the request does not 484 include both a Request-Tag Option and a Size1 Option but does 485 include a Q-Block1 option. 487 4.02 (Bad Option) 489 Either this Response Code or a reset message MUST be returned if 490 the server does not support the Q-Block1 Option. 492 4.08 (Request Entity Incomplete) 494 This Response Code returned without Content-Type "application/ 495 missing-blocks+cbor-seq" (Section 10.3) is handled as in 496 Section 2.9.2 [RFC7959]. 498 This Response Code returned with Content-Type "application/ 499 missing-blocks+cbor-seq" indicates that some of the payloads are 500 missing and need to be resent. The client then retransmits the 501 missing payloads using the same Request-Tag, Size1 and Q-Block1 to 502 specify the block number, SZX, and M bit as appropriate. 504 The Request-Tag value to use is determined from the token in the 505 4.08 (Request Entity Incomplete) response and then finding the 506 matching client request which contains the Request-Tag that is 507 being used for this Q-Block1 body. 509 The token used in the response SHOULD be from the last received 510 payload. See Section 4 for further information. 512 4.13 (Request Entity Too Large) 514 This Response Code can be returned under similar conditions to 515 those discussed in Section 2.9.3 of [RFC7959]. 517 This Response Code can be returned if there is insufficient space 518 to create a response PDU with a block size of 16 bytes (SZX = 0) 519 to send back all the response options as appropriate. In this 520 case, the Size1 Option is not included. 522 If the server has not received all the payloads of a body, but one or 523 more NON payloads have been received, it SHOULD wait for up to 524 NON_RECEIVE_TIMEOUT (Section 6.2) before sending a 4.08 (Request 525 Entity Incomplete) response. Further considerations related to the 526 transmission timings of 4.08 (Request Entity Incomplete) and 2.31 527 (Continue) Response Codes are discussed in Section 6.2. 529 If a server receives payloads with different Request-Tags for the 530 same resource, it should continue to process all the bodies as it has 531 no way of determining which is the latest version, or which body, if 532 any, the client is terminating the transmission for. 534 If the client elects to stop the transmission of a complete body, it 535 SHOULD "forget" all tracked tokens associated with the body's 536 Request-Tag so that a reset message is generated for the invalid 537 token in the 4.08 (Request Entity Incomplete) response. The server 538 on receipt of the reset message SHOULD delete the partial body. 540 If the server receives a duplicate block with the same Request-Tag, 541 it SHOULD ignore the payload of the packet, but MUST still respond as 542 if the block was received for the first time. 544 A server SHOULD only maintain a partial body (missing payloads) for 545 up to NON_PARTIAL_TIMEOUT (Section 6.2). 547 3.4. Using the Q-Block2 Option 549 In a request for any block number, the M bit unset indicates the 550 request is just for that block. If the M bit is set, this has 551 different meanings based on the NUM value: 553 NUM is zero: This is a request for the entire body. 555 'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero: 557 This is used to confirm that the current set of MAX_PAYLOADS 558 payloads (the latest one having block number NUM-1) has been 559 successfully received and that, upon receipt of this request, the 560 server can continue to send the next set of payloads (the first 561 one having block number NUM). This is the 'Continue' Q-Block-2. 563 Any other value of NUM: This is a request for that block and for all 564 of the remaining blocks in the current MAX_PAYLOADS set. 566 If the request includes multiple Q-Block2 Options and these options 567 overlap (e.g., combination of M being set (this and later blocks) and 568 being unset (this individual block)) resulting in an individual block 569 being requested multiple times, the server MUST only send back one 570 instance of that block. This behavior is meant to prevent 571 amplification attacks. 573 The payloads sent back from the server as a response MUST all have 574 the same ETag (Section 5.10.6 of [RFC7252]) for the same body. The 575 server MUST NOT use the same ETag value for different representations 576 of a resource. 578 The ETag is opaque, the client still treats it as opaque but the 579 server SHOULD ensure that it is unique for every different body of 580 transmitted data. 582 Implementation Note: It is suggested that the server treats the 583 ETag as an unsigned integer of 8 bytes in length. An 584 implementation may want to consider limiting this to 4 bytes to 585 reduce packet overhead size. The initial ETag value should be 586 randomly generated and then subsequently incremented by the server 587 whenever a new body of data is being transmitted between peers. 589 Section 3.7 discusses the use of Size2 Option. 591 The client may elect to request any detected missing blocks or just 592 ignore the partial body. This decision is implementation specific. 594 The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 6.2) 595 after the last received payload for NON payloads before issuing a 596 GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or 597 more Q-Block2 Options that define the missing blocks with the M bit 598 unset. It is permissible to set the M bit to request this and 599 missing blocks from this MAX_PAYLOADS set. Further considerations 600 related to the transmission timing for missing requests are discussed 601 in Section 6.2. 603 The requested missing block numbers MUST have an increasing block 604 number in each additional Q-Block2 Option with no duplicates. The 605 server SHOULD respond with a 4.00 (Bad Request) to requests not 606 adhering to this behavior. 608 For Confirmable responses, the client continues to acknowledge each 609 packet. The server will detect failure to send a packet, but the 610 client can issue, after a MAX_TRANSMIT_SPAN delay, a separate GET, 611 POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as needed. 613 If the client receives a duplicate block with the same ETag, it 614 SHOULD silently ignore the packet. 616 A client SHOULD only maintain a partial body (missing payloads) for 617 up to NON_PARTIAL_TIMEOUT (Section 6.2) or as defined by the Max-Age 618 Option (or its default), whichever is the less. 620 The ETag Option should not be used in the request for missing blocks 621 as the server could respond with a 2.03 (Valid Response) with no 622 payload. It can be used in the request if the client wants to check 623 the freshness of the currently cached body response. 625 If the server detects part way through a body transfer that the 626 resource data has changed and the server is not maintaining a cached 627 copy of the old data, then the body response SHOULD be restarted with 628 a different ETag Option value. Any subsequent missing block requests 629 MUST be responded to using the latest ETag Option value. 631 If the server responds during a body update with a different ETag 632 Option value (as the resource representation has changed), then the 633 client should treat the partial body with the old ETag as no longer 634 being fresh. 636 If the server transmits a new body of data (e.g., a triggered 637 Observe) with a new ETag to the same client as an additional 638 response, the client should remove any partially received body held 639 for a previous ETag for that resource as it is unlikely the missing 640 blocks can be retrieved. 642 If there is insufficient space to create a response PDU with a block 643 size of 16 bytes (SZX = 0) to send back all the response options as 644 appropriate, a 4.13 (Request Entity Too Large) is returned without 645 the Size1 Option. 647 3.5. Using Observe and Q-Block1 Options 649 As the blocks of the body are sent without waiting for 650 acknowledgement of the individual blocks, the observe value [RFC7641] 651 MUST be the same for all the blocks of the same body. 653 If the server reports any missing payload, the client re-sends the 654 missing payload(s). Each re-sent payload is treated as a new request 655 and the Observe Option MUST be included in the request. 657 If the response (or associated response) uses Q-Block2 Option, and 658 one of the response payloads is missing, the request for the missing 659 payload(s) is treated as a new request. The request MUST comprise of 660 all of the request payloads and the Observe Option MUST NOT be 661 included in either the request or response. 663 3.6. Using Observe and Q-Block2 Options 665 As the blocks of the body are sent without waiting for 666 acknowledgement of the individual blocks, the Observe value [RFC7641] 667 MUST be the same for all the blocks of the same body. 669 If the client requests missing blocks, this is treated as a new 670 Request and the Observe Option MUST NOT be included in either the 671 request or response. If the ETag value in the response changes, then 672 the previously received partial body should be considered as not 673 fresh and the whole body re-requested. 675 3.7. Using Size1 and Size2 Options 677 Section 4 of [RFC7959] defines two CoAP options: Size1 for indicating 678 the size of the representation transferred in requests and Size2 for 679 indicating the size of the representation transferred in responses. 681 The Size1 or Size2 option values MUST exactly represent the size of 682 the data on the body so that any missing data can easily be 683 determined. 685 The Size1 Option MUST be used with the Q-Block1 Option when used in a 686 request. The Size2 Option MUST be used with the Q-Block2 Option when 687 used in a response. 689 If Size1 or Size2 Options are used, they MUST be used in all payloads 690 of the body and MUST preserve the same value in each of those 691 payloads. 693 3.8. Using Q-Block1 and Q-Block2 Options Together 695 The behavior is similar to the one defined in Section 3.3 of 696 [RFC7959] with Q-Block1 substituted for Block1 and Q-Block2 for 697 Block2. 699 4. The Use of 4.08 (Request Entity Incomplete) Response Code 701 4.08 (Request Entity Incomplete) Response Code has a new Content-Type 702 "application/missing-blocks+cbor-seq" used to indicate that the 703 server has not received all of the blocks of the request body that it 704 needs to proceed. 706 Likely causes are the client has not sent all blocks, some blocks 707 were dropped during transmission, or the client has sent them 708 sufficiently long ago that the server has already discarded them. 710 The data payload of the 4.08 (Request Entity Incomplete) response is 711 encoded as a CBOR Sequence [RFC8742]. It comprises of one or more 712 CBOR encoded missing block numbers. The missing block numbers MUST 713 be unique in each 4.08 (Request Entity Incomplete) response when 714 created by the server; the client SHOULD drop any duplicates in the 715 same 4.08 (Request Entity Incomplete) response. 717 The Content-Format Option (Section 5.10.3 of [RFC7252]) MUST be used 718 in the 4.08 (Request Entity Incomplete) response. It MUST be set to 719 "application/missing-blocks+cbor-seq" (Section 10.3). 721 The Concise Data Definition Language [RFC8610] for the data 722 describing these missing blocks is as follows: 724 ; This defines an array, the elements of which are to be used 725 ; in a CBOR Sequence: 726 payload = [+ missing-block-number] 727 ; A unique block number not received: 728 missing-block-number = uint 730 Figure 1: Structure of the Missing Blocks Payload 732 The token to use for the response SHOULD be the token that was used 733 in the last block number received so far with the same Request-Tag 734 value. Note that the use of any received token with the same 735 Request-Tag would work, but providing the one used in the last 736 received block number will aid any troubleshooting. The client will 737 use the token to determine what is the previously sent request to 738 obtain the Request-Tag value to be used. 740 If the size of the 4.08 (Request Entity Incomplete) response packet 741 is larger than that defined by Section 4.6 [RFC7252], then the number 742 of missing blocks MUST be limited so that the response can fit into a 743 single packet. If this is the case, then the server can send 744 subsequent 4.08 (Request Entity Incomplete) responses containing the 745 missing other blocks on receipt of a new request providing a missing 746 payload with the same Request-Tag. 748 The missing blocks MUST be reported in ascending order without any 749 duplicates. The client SHOULD silently drop 4.08 (Request Entity 750 Incomplete) responses not adhering with this behavior. 752 Implementation Note: Updating the payload without overflowing the 753 overall packet size as each block number can be of varying length 754 needs consideration. It is possible to use Indefinite-Length 755 Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit the 756 array count to 23 so that the initial byte with the array major 757 type and data length in the additional information can be updated 758 with the overall count once the payload count is confirmed. 759 Further restricting the count to MAX_PAYLOADS means that 760 congestion control is less likely to be invoked on the server. 762 The 4.08 (Request Entity Incomplete) with Content-Type "application/ 763 missing-blocks+cbor-seq" SHOULD NOT be used when using Confirmable 764 requests or a reliable connection [RFC8323] as the client will be 765 able to determine that there is a transmission failure of a 766 particular payload and hence that the server is missing that payload. 768 5. The Use of Tokens 770 Each new request MUST use a unique Token (Section 4 of 771 [I-D.ietf-core-echo-request-tag]). Additional responses may use the 772 same Token. 774 Implementation Note: To minimize on the number of tokens that have 775 to be tracked by clients, it is recommended that the bottom 32 776 bits is kept the same for the same body and the upper 32 bits 777 contains the individual payload number. 779 Servers continue to treat the token as a unique opaque entity. If 780 an individual payload has to be resent (e.g., requested upon 781 packet loss), then the retransmitted packet is treated as a new 782 request (i.e., the bottom 32 bits must change). 784 6. Congestion Control 786 The transmission of the payloads of a body either SHOULD all be 787 Confirmable or all be Non-confirmable. This is meant to simplify the 788 congestion control procedure. 790 6.1. Confirmable (CON) 792 Congestion control for CON requests and responses is specified in 793 Section 4.7 of [RFC7252]. For faster transmission rates, NSTART will 794 need to be increased from 1. However, the other CON congestion 795 control parameters will need to be tuned to cover this change. This 796 tuning is out of scope of this document as it is expected that all 797 requests and responses using Q-Block1 and Q-Block2 will be Non- 798 confirmable. 800 It is implementation specific as to whether there should be any 801 further requests for missing data as there will have been significant 802 transmission failure as individual payloads will have failed after 803 MAX_TRANSMIT_SPAN. 805 6.2. Non-confirmable (NON) 807 This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT, 808 NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and 809 NON_PARTIAL_TIMEOUT primarily for use with NON. 811 MAX_PAYLOADS should be configurable with a default value of 10. Both 812 CoAP endpoints SHOULD have the same value (otherwise there will be 813 transmission delays in one direction) and the value MAY be negotiated 814 between the endpoints to a common value by using a higher level 815 protocol (out of scope of this document). This is the maximum number 816 of payloads that can be transmitted at any one time. 818 Note: The default value of 10 is chosen for reasons similar to 819 those discussed in Section 5 of [RFC6928]. 821 NON_TIMEOUT is the maximum period of delay between sending sets of 822 MAX_PAYLOADS payloads for the same body. By default, NON_TIMEOUT has 823 the same value as ACK_TIMEOUT (Section 4.8 of [RFC7252]). 825 NON_RECEIVE_TIMEOUT is the maximum time to wait for a missing payload 826 before requesting retransmission. NON_RECEIVE_TIMEOUT has a value of 827 twice NON_TIMEOUT. 829 NON_MAX_RETRANSMIT is the maximum number of times a request for the 830 retransmission of missing payloads can occur without a response from 831 the remote peer. After this occurs, the peer SHOULD consider the 832 body stale and remove all references to it. By default, 833 NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT (Section 4.8 834 of [RFC7252]). 836 NON_PROBING_WAIT is used to limit the potential wait needed 837 calculated when using PROBING_WAIT. NON_PROBING_WAIT has the same 838 value as computed for EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). 840 NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. 841 NON_PARTIAL_TIMEOUT has the same value as computed for 842 EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). 844 +---------------------+---------------+ 845 | Parameter Name | Default Value | 846 +=====================+===============| 847 | MAX_PAYLOADS | 10 | 848 | NON_MAX_RETRANSMIT | 4 | 849 | NON_TIMEOUT | 2 s | 850 | NON_RECEIVE_TIMEOUT | 4 s | 851 | NON_PROBING_WAIT | 247 s | 852 | NON_PARTIAL_TIMEOUT | 247 s | 853 +---------------------+---------------+ 855 Table 3: Congestion Control Parameters 857 PROBING_RATE parameter in CoAP indicates the average data rate that 858 must not be exceeded by a CoAP endpoint in sending to a peer endpoint 859 that does not respond. The single body of blocks will be subjected 860 to PROBING_RATE (Section 4.7 of [RFC7252]), not the individual 861 packets. If the wait time between sending bodies that are not being 862 responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the 863 gap time is limited to NON_PROBING_WAIT. 865 Note: For the particular DOTS application, PROBING_RATE and other 866 transmission parameters are negotiated between peers. Even when 867 not negotiated, the DOTS application uses customized defaults as 868 discussed in Section 4.5.2 of [RFC8782]. Note that MAX_PAYLOADS, 869 NON_MAX_RETRANSMIT, and NON_TIMEOUT can be negotiated between DOTS 870 peers as per [I-D.bosh-dots-quick-blocks]. 872 Each NON 4.08 (Request Entity Incomplete) response is subject to 873 PROBING_RATE. 875 Each NON GET or FETCH request using Q-Block2 Option is subject to 876 PROBING_RATE. 878 As the sending of many payloads of a single body may itself cause 879 congestion, it is RECOMMENDED that after transmission of every set of 880 MAX_PAYLOADS payloads of a single body, a delay is introduced of 881 NON_TIMEOUT before sending the next set of payloads to manage 882 potential congestion issues. 884 If the CoAP peer reports at least one payload has not arrived for 885 each body for at least a 24 hour period and it is known that there 886 are no other network issues over that period, then the value of 887 MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1) and 888 the situation re-evaluated for another 24 hour period until there is 889 no report of missing payloads under normal operating conditions. The 890 newly derived value for MAX_PAYLOADS should be used for both ends of 891 this particular CoAP peer link. Note that the CoAP peer will not 892 know about the MAX_PAYLOADS change until it is reconfigured. As a 893 consequence of not being reconfigured, the peer may indicate that 894 there are some missing payloads prior to the actual payload being 895 transmitted as all of its MAX_PAYLOADS payloads have not arrived. 897 The sending of a set of missing payloads of a body is subject to 898 MAX_PAYLOADS set of payloads. 900 For Q-Block1 Option, if the server responds with a 2.31 (Continue) 901 Response Code for the latest payload sent, then the client can 902 continue to send the next set of payloads without any delay. If the 903 server responds with a 4.08 (Request Entity Incomplete) Response 904 Code, then the missing payloads SHOULD be retransmitted before going 905 into another NON_TIMEOUT delay prior to sending the next set of 906 payloads. 908 For the server receiving NON Q-Block1 requests, it SHOULD send back a 909 2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS 910 payloads to prevent the client unnecessarily delaying. Otherwise the 911 server SHOULD delay for NON_RECEIVE_TIMEOUT, before sending the 4.08 912 (Request Entity Incomplete) Response Code. The NON_RECEIVE_TIMEOUT 913 delay may be reduced for the first time that this 4.08 (Request 914 Entity Incomplete) is sent if either the last of the MAX_PAYLOADS 915 payloads or the final payload with the M bit unset arrives, but 916 SHOULD NOT be reduced to zero as packets may arrive in the wrong 917 order. 919 It is possible that the client may start transmitting the next set of 920 MAX_PAYLOADS payloads before the server times out on waiting for the 921 last of the previous MAX_PAYLOADS payloads. On receipt of the first 922 received payload from the new set of MAX_PAYLOADS payloads, the 923 server SHOULD send a 4.08 (Request Entity Incomplete) Response Code 924 indicating any missing payloads from any previous MAX_PAYLOADS 925 payloads. Upon receipt of the 4.08 (Request Entity Incomplete) 926 Response Code, the client SHOULD send the missing payloads before 927 continuing to send the remainder of the MAX_PAYLOADS payloads and 928 then go into another NON_TIMEOUT delay prior to sending the next set 929 of payloads. 931 For the client receiving NON Q-Block2 responses, it SHOULD send a 932 request for the next set of payloads on receipt of all of the 933 MAX_PAYLOADS payloads to prevent the server unnecessarily delaying. 934 Otherwise the client SHOULD delay for NON_RECEIVE_TIMEOUT, before 935 sending the request for the missing payloads. The 936 NON_RECEIVE_TIMEOUT delay may be reduced for the first time that this 937 request is sent if either the last of the MAX_PAYLOADS payloads or 938 the final payload with the M bit unset arrives, but SHOULD NOT be 939 reduced to zero as packets may arrive in the wrong order. 941 The request that the client sends to acknowledge the receipt of all 942 the current set of MAX_PAYLOADS payloads is the 'Continue' Q-Block2 943 Option ('NUM modulo MAX_PAYLOADS' is zero, NUM is not zero, and M bit 944 is set (Section 3.4)). The server SHOULD recognize this as a 945 continue request and just continue the transmission of the body 946 (including Observe Option, if appropriate for an unsolicited 947 response) rather than as a request for the remaining missing blocks. 949 It is possible that the server may start transmitting the next set of 950 MAX_PAYLOADS payloads before the client times out on waiting for the 951 last of the previous MAX_PAYLOADS payloads. Upon receipt of the 952 first payload from the new set of MAX_PAYLOADS payloads, the client 953 SHOULD send a request indicating any missing payloads from any 954 previous set of MAX_PAYLOADS payloads. Upon receipt of such request, 955 the server SHOULD send the missing payloads before continuing to send 956 the remainder of the MAX_PAYLOADS payloads and then go into another 957 NON_TIMEOUT delay prior to sending the next set of payloads. 959 The client does not need to acknowledge the receipt of the entire 960 body. 962 Note: If there is asymmetric traffic loss causing responses to 963 never get received, a delay of NON_TIMEOUT after every 964 transmission of MAX_PAYLOADS blocks will be observed. The 965 endpoint receiving the body is still likely to receive the entire 966 body. 968 7. Caching Considerations 970 Caching block based information is not straight forward in a proxy. 971 For Q-Block1 and Q-Block2 Options, for simplicity it is expected that 972 the proxy will reassemble the body (using any appropriate recovery 973 options for packet loss) before passing on the body to the 974 appropriate CoAP endpoint. This does not preclude an implementation 975 doing a more complex per payload caching, but how to do this is out 976 of the scope of this document. The onward transmission of the body 977 does not require the use of the Q-Block1 or Q-Block2 Options as these 978 options may not be supported in that link. This means that the proxy 979 must fully support the Q-Block1 and Q-Block2 Options. 981 How the body is cached in the CoAP client (for Q-Block1 982 transmissions) or the CoAP server (for Q-Block2 transmissions) is 983 implementation specific. 985 As the entire body is being cached in the proxy, the Q-Block1 and 986 Q-Block2 Options are removed as part of the block assembly and thus 987 do not reach the cache. 989 For Q-Block2 responses, the ETag Option value is associated with the 990 data (and onward transmitted to the CoAP client), but is not part of 991 the cache key. 993 For requests with Q-Block1 Option, the Request-Tag Option is 994 associated with the build up of the body from successive payloads, 995 but is not part of the cache key. For the onward transmission of the 996 body using CoAP, a new Request-Tag SHOULD be generated and used. 997 Ideally this new Request-Tag should replace the client's request 998 Request-Tag. 1000 It is possible that two or more CoAP clients are concurrently 1001 updating the same resource through a common proxy to the same CoAP 1002 server using Q-Block1 (or Block1) Option. If this is the case, the 1003 first client to complete building the body causes that body to start 1004 transmitting to the CoAP server with an appropriate Request-Tag 1005 value. When the next client completes building the body, any 1006 existing partial body transmission to the CoAP server is terminated 1007 and the new body representation transmission starts with a new 1008 Request-Tag value. Note that it cannot be assumed that the proxy 1009 will always receive a complete body from a client. 1011 A proxy that supports Q-Block2 Option MUST be prepared to receive a 1012 GET or similar request indicating one or more missing blocks. The 1013 proxy will serve from its cache the missing blocks that are available 1014 in its cache in the same way a server would send all the appropriate 1015 Q-Block2s. If the cache key matching body is not available in the 1016 cache, the proxy MUST request the entire body from the CoAP server 1017 using the information in the cache key. 1019 How long a CoAP endpoint (or proxy) keeps the body in its cache is 1020 implementation specific (e.g., it may be based on Max-Age). 1022 8. HTTP-Mapping Considerations 1024 As a reminder, the basic normative requirements on HTTP/CoAP mappings 1025 are defined in Section 10 of [RFC7252]. The implementation 1026 guidelines for HTTP/CoAP mappings are elaborated in [RFC8075]. 1028 The rules defined in Section 5 of [RFC7959] are to be followed. 1030 9. Examples with Non-confirmable Messages 1032 This section provides some sample flows to illustrate the use of 1033 Q-Block1 and Q-Block2 Options with NON. Examples with CON are 1034 provided in Appendix A. 1036 Figure 2 lists the conventions that are used in the following 1037 subsections. 1039 T: Token value 1040 O: Observe Option value 1041 M: Message ID 1042 RT: Request-Tag 1043 ET: ETag 1044 QB1: Q-Block1 Option values NUM/More/SZX 1045 QB2: Q-Block2 Option values NUM/More/SZX 1046 \: Trimming long lines 1047 [[]]: Comments 1048 -->X: Message loss (request) 1049 X<--: Message loss (response) 1050 ...: Passage of time 1052 Figure 2: Notations Used in the Figures 1054 9.1. Q-Block1 Option 1056 9.1.1. A Simple Example 1058 Figure 3 depicts an example of a NON PUT request conveying Q-Block1 1059 Option. All the blocks are received by the server. 1061 CoAP CoAP 1062 Client Server 1063 | | 1064 +--------->| NON PUT /path M:0x81 T:0xc0 RT=9 QB1:0/1/1024 1065 +--------->| NON PUT /path M:0x82 T:0xc1 RT=9 QB1:1/1/1024 1066 +--------->| NON PUT /path M:0x83 T:0xc2 RT=9 QB1:2/1/1024 1067 +--------->| NON PUT /path M:0x84 T:0xc3 RT=9 QB1:3/0/1024 1068 |<---------+ NON 2.04 M:0xf1 T:0xc3 1069 | ... | 1071 Figure 3: Example of NON Request with Q-Block1 Option (Without Loss) 1073 9.1.2. Handling MAX_PAYLOADS Limits 1075 Figure 4 depicts an example of a NON PUT request conveying Q-Block1 1076 Option. The number of payloads exceeds MAX_PAYLOADS. All the blocks 1077 are received by the server. 1079 CoAP CoAP 1080 Client Server 1081 | | 1082 +--------->| NON PUT /path M:0x01 T:0xf1 RT=10 QB1:0/1/1024 1083 +--------->| NON PUT /path M:0x02 T:0xf2 RT=10 QB1:1/1/1024 1084 +--------->| [[Payloads 3 - 9 not detailed]] 1085 +--------->| NON PUT /path M:0x0a T:0xfa RT=10 QB1:9/1/1024 1086 [[MAX_PAYLOADS has been reached]] 1087 | [[MAX_PAYLOADS blocks receipt acknowledged by server]] 1088 |<---------+ NON 2.31 M:0x81 T:0xfa 1089 +--------->| NON PUT /path M:0x0b T:0xfb RT=10 QB1:10/0/1024 1090 |<---------+ NON 2.04 M:0x82 T:0xfb 1091 | ... | 1093 Figure 4: Example of MAX_PAYLOADS NON Request with Q-Block1 Option 1094 (Without Loss) 1096 9.1.3. Handling MAX_PAYLOADS with Recovery 1098 Consider now a scenario where a new body of data is to be sent by the 1099 client, but some blocks are dropped in transmission as illustrated in 1100 Figure 5. 1102 CoAP CoAP 1103 Client Server 1104 | | 1105 +--------->| NON PUT /path M:0x11 T:0xe1 RT=11 QB1:0/1/1024 1106 +--->X | NON PUT /path M:0x12 T:0xe2 RT=11 QB1:1/1/1024 1107 +--------->| [[Payloads 3 - 8 not detailed]] 1108 +--------->| NON PUT /path M:0x19 T:0xe9 RT=11 QB1:8/1/1024 1109 +--->X | NON PUT /path M:0x1a T:0xea RT=11 QB1:9/1/1024 1110 [[MAX_PAYLOADS has been reached]] 1111 | ... | 1112 [[NON_TIMEOUT (client) delay expires]] 1113 | [[Client starts sending next set of payloads]] 1114 +--->X | NON PUT /path M:0x1b T:0xeb RT=11 QB1:10/1/1024 1115 +--------->| NON PUT /path M:0x1c T:0xec RT=11 QB1:11/1/1024 1116 | | 1118 Figure 5: Example of MAX_PAYLOADS NON Request with Q-Block1 Option 1119 (With Loss) 1121 On seeing a payload from the next set of payloads, the server 1122 realizes that some blocks are missing from the previous MAX_PAYLOADS 1123 payloads and asks for the missing blocks in one go (Figure 6). It 1124 does so by indicating which blocks have not been received in the data 1125 portion of the response. The token used in the response should be 1126 the token that was used in the last block number received payload. 1128 The client can then derive the Request-Tag by matching the token with 1129 the sent request. 1131 CoAP CoAP 1132 Client Server 1133 | | 1134 |<---------+ NON 4.08 M:0x91 T:0xec [Missing 1,9 [for RT=11]] 1135 | [[Client responds with missing payloads]] 1136 +--------->| NON PUT /path M:0x1d T:0xed RT=11 QB1:1/1/1024 1137 +--------->| NON PUT /path M:0x1e T:0xee RT=11 QB1:9/1/1024 1138 | [[Client continues sending next set of payloads]] 1139 +--------->| NON PUT /path M:0x1f T:0xef RT=11 QB1:12/0/1024 1140 | ... | 1141 [[NON_RECEIVE_TIMEOUT (server) delay expires]] 1142 | [[The server realizes a block is still missing and asks 1143 | for the missing one]] 1144 |<---------+ NON 4.08 M:0x92 T:0xef [Missing 10 [for RT=11]] 1145 +--------->| NON PUT /path M:0x20 T:0xf0 RT=11 QB1:10/1/1024 1146 |<---------+ NON 2.04 M:0x93 T:0xf0 1147 | ... | 1149 Figure 6: Example of NON Request with Q-Block1 Option (Blocks 1150 Recovery) 1152 Under high levels of traffic loss, the client can elect not to retry 1153 sending missing blocks of data by "forgetting" all the tracked tokens 1154 for this Request-Tag. Similarly, the server can elect to not to 1155 continue asking for missing blocks. Both these decisions are 1156 implementation specific. 1158 9.2. Q-Block2 Option 1160 9.2.1. A Simple Example 1162 Figure 7 illustrates the example of Q-Block2 Option. The client 1163 sends a NON GET carrying Observe and Q-Block2 Options. The Q-Block2 1164 Option indicates a block size hint (1024 bytes). This request is 1165 replied to by the server using four (4) blocks that are transmitted 1166 to the client without any loss. Each of these blocks carries a 1167 Q-Block2 Option. The same process is repeated when an Observe is 1168 triggered, but no loss is experienced by any of the notification 1169 blocks. 1171 CoAP CoAP 1172 Client Server 1173 | | 1174 +--------->| NON GET /path M:0x01 T:0xc0 O:0 QB2:0/1/1024 1175 |<---------+ NON 2.05 M:0xf1 T:0xc0 O:1220 ET=19 QB2:0/1/1024 1176 |<---------+ NON 2.05 M:0xf2 T:0xc0 O:1220 ET=19 QB2:1/1/1024 1177 |<---------+ NON 2.05 M:0xf3 T:0xc0 O:1220 ET=19 QB2:2/1/1024 1178 |<---------+ NON 2.05 M:0xf4 T:0xc0 O:1220 ET=19 QB2:3/0/1024 1179 | ... | 1180 | [[Observe triggered]] 1181 |<---------+ NON 2.05 M:0xf5 T:0xc0 O:1221 ET=20 QB2:0/1/1024 1182 |<---------+ NON 2.05 M:0xf6 T:0xc0 O:1221 ET=20 QB2:1/1/1024 1183 |<---------+ NON 2.05 M:0xf7 T:0xc0 O:1221 ET=20 QB2:2/1/1024 1184 |<---------+ NON 2.05 M:0xf8 T:0xc0 O:1221 ET=20 QB2:3/0/1024 1185 | ... | 1187 Figure 7: Example of NON Notifications with Q-Block2 Option (Without 1188 Loss) 1190 9.2.2. Handling MAX_PAYLOADS Limits 1192 Figure 8 illustrates the same as Figure 7 but this time has eleven 1193 (11) payloads which exceeds MAX_PAYLOADS. There is no loss 1194 experienced. 1196 CoAP CoAP 1197 Client Server 1198 | | 1199 +--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024 1200 |<---------+ NON 2.05 M:0x81 T:0xf0 O:1234 ET=21 QB2:0/1/1024 1201 |<---------+ NON 2.05 M:0x82 T:0xf0 O:1234 ET=21 QB2:1/1/1024 1202 |<---------+ [[Payloads 3 - 9 not detailed]] 1203 |<---------+ NON 2.05 M:0x8a T:0xf0 O:1234 ET=21 QB2:9/1/1024 1204 [[MAX_PAYLOADS has been reached]] 1205 | [[MAX_PAYLOADS blocks acknowledged by client using 1206 | 'Continue' Q-Block2]] 1207 +--------->| NON GET /path M:0x02 T:0xf1 QB2:10/1/1024 1208 |<---------+ NON 2.05 M:0x8b T:0xf0 O:1234 ET=21 QB2:10/0/1024 1209 | ... | 1210 | [[Observe triggered]] 1211 |<---------+ NON 2.05 M:0x91 T:0xf0 O:1235 ET=22 QB2:0/1/1024 1212 |<---------+ NON 2.05 M:0x92 T:0xf0 O:1235 ET=22 QB2:1/1/1024 1213 |<---------+ [[Payloads 3 - 9 not detailed]] 1214 |<---------+ NON 2.05 M:0x9a T:0xf0 O:1235 ET=22 QB2:9/1/1024 1215 [[MAX_PAYLOADS has been reached]] 1216 | [[MAX_PAYLOADS blocks acknowledged by client using 1217 | 'Continue' Q-Block2]] 1218 +--------->| NON GET /path M:0x03 T:0xf2 QB2:10/1/1024 1219 |<---------+ NON 2.05 M:0x9b T:0xf0 O:1235 ET=22 QB2:10/0/1024 1220 [[Body has been received]] 1221 | ... | 1223 Figure 8: Example of NON Notifications with Q-Block2 Option (Without 1224 Loss) 1226 9.2.3. Handling MAX_PAYLOADS with Recovery 1228 Figure 9 shows the example of an Observe that is triggered but for 1229 which some notification blocks are lost. The client detects the 1230 missing blocks and requests their retransmission. It does so by 1231 indicating the blocks that were successfully received. 1233 CoAP CoAP 1234 Client Server 1235 | ... | 1236 | [[Observe triggered]] 1237 |<---------+ NON 2.05 M:0xa1 T:0xf0 O:1236 ET=23 QB2:0/1/1024 1238 | X<---+ NON 2.05 M:0xa2 T:0xf0 O:1236 ET=23 QB2:1/1/1024 1239 |<---------+ [[Payloads 3 - 8 not detailed]] 1240 | X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024 1241 [[MAX_PAYLOADS has been reached]] 1242 | ... | 1243 [[NON_TIMEOUT (server) delay expires]] 1244 | [[Server sends next set of payloads]] 1245 |<---------+ NON 2.05 M:0xab T:0xf0 O:1236 ET=23 QB2:10/0/1024 1246 | ... | 1247 [[NON_RECEIVE_TIMEOUT (client) delay expires]] 1248 | [[Client realizes blocks are missing and asks for the 1249 | missing ones in one go]] 1250 +--------->| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\ 1251 | | QB2:9/0/1024 1252 | X<---+ NON 2.05 M:0xac T:0xf3 ET=23 QB2:1/1/1024 1253 |<---------+ NON 2.05 M:0xad T:0xf3 ET=23 QB2:9/1/1024 1254 | ... | 1255 [[NON_RECEIVE_TIMEOUT (client) delay expires]] 1256 | [[Client realizes block is still missing and asks for 1257 | missing block]] 1258 +--------->| NON GET /path M:0x05 T:0xf4 QB2:1/0/1024 1259 |<---------+ NON 2.05 M:0xae T:0xf4 ET=23 QB2:1/1/1024 1260 [[Body has been received]] 1261 | ... | 1263 Figure 9: Example of NON Notifications with Q-Block2 Option (Blocks 1264 Recovery) 1266 Under high levels of traffic loss, the client can elect not to retry 1267 getting missing blocks of data. This decision is implementation 1268 specific. 1270 9.2.4. Handling Recovery using M-bit Set 1272 Figure 10 shows the example of an Observe that is triggered but only 1273 the first two notification blocks reach the client. In order to 1274 retrieve the missing blocks, the client sends a request with a single 1275 Q-Block2 Option with the M bit set. 1277 CoAP CoAP 1278 Client Server 1279 | ... | 1280 | [[Observe triggered]] 1281 |<---------+ NON 2.05 M:0xb1 T:0xf0 O:1237 ET=24 QB2:0/1/1024 1282 |<---------+ NON 2.05 M:0xb2 T:0xf0 O:1237 ET=24 QB2:1/1/1024 1283 | X<---+ NON 2.05 M:0xb3 T:0xf0 O:1237 ET=24 QB2:2/1/1024 1284 | X<---+ [[Payloads 4 - 9 not detailed]] 1285 | X<---+ NON 2.05 M:0xb9 T:0xf0 O:1237 ET=24 QB2:9/1/1024 1286 [[MAX_PAYLOADS has been reached]] 1287 | ... | 1288 [[NON_TIMEOUT (server) delay expires]] 1289 | [[Server sends next set of payloads]] 1290 | X<---+ NON 2.05 M:0xba T:0xf0 O:1237 ET=24 QB2:10/0/1024 1291 | ... | 1292 [[NON_RECEIVE_TIMEOUT (client) delay expires]] 1293 | [[Client realizes blocks are missing and asks for the 1294 | missing ones in one go by setting the M bit]] 1295 +--------->| NON GET /path M:0x06 T:0xf5 QB2:2/1/1024 1296 |<---------+ NON 2.05 M:0xbb T:0xf5 ET=24 QB2:2/1/1024 1297 |<---------+ [[Payloads 3 - 9 not detailed]] 1298 |<---------+ NON 2.05 M:0xc2 T:0xf5 ET=24 QB2:9/1/1024 1299 [[MAX_PAYLOADS has been reached]] 1300 | [[MAX_PAYLOADS acknowledged by client using 'Continue' 1301 | Q-Block2]] 1302 +--------->| NON GET /path M:0x87 T:0xf6 QB2:10/1/1024 1303 |<---------+ NON 2.05 M:0xc3 T:0xf0 O:1237 ET=24 QB2:10/0/1024 1304 [[Body has been received]] 1305 | ... | 1307 Figure 10: Example of NON Notifications with Q-Block2 Option (Blocks 1308 Recovery with M bit Set) 1310 9.3. Q-Block1 and Q-Block2 Options 1312 9.3.1. A Simple Example 1314 Figure 11 illustrates the example of a FETCH using both Q-Block1 and 1315 Q-Block2 Options along with an Observe Option. No loss is 1316 experienced. 1318 CoAP CoAP 1319 Client Server 1320 | | 1321 +--------->| NON FETCH /path M:0x10 T:0x90 O:0 RT=30 QB1:0/1/1024 1322 +--------->| NON FETCH /path M:0x11 T:0x91 O:0 RT=30 QB1:1/1/1024 1323 +--------->| NON FETCH /path M:0x12 T:0x93 O:0 RT=30 QB1:2/0/1024 1324 |<---------+ NON 2.05 M:0x60 T:0x93 O:1320 ET=90 QB2:0/1/1024 1325 |<---------+ NON 2.05 M:0x61 T:0x93 O:1320 ET=90 QB2:1/1/1024 1326 |<---------+ NON 2.05 M:0x62 T:0x93 O:1320 ET=90 QB2:2/1/1024 1327 |<---------+ NON 2.05 M:0x63 T:0x93 O:1320 ET=90 QB2:3/0/1024 1328 | ... | 1329 | [[Observe triggered]] 1330 |<---------+ NON 2.05 M:0x64 T:0x93 O:1321 ET=91 QB2:0/1/1024 1331 |<---------+ NON 2.05 M:0x65 T:0x93 O:1321 ET=91 QB2:1/1/1024 1332 |<---------+ NON 2.05 M:0x66 T:0x93 O:1321 ET=91 QB2:2/1/1024 1333 |<---------+ NON 2.05 M:0x67 T:0x93 O:1321 ET=91 QB2:3/0/1024 1334 | ... | 1336 Figure 11: Example of NON FETCH with Q-Block1 and Q-Block2 Options 1337 (Without Loss) 1339 9.3.2. Handling MAX_PAYLOADS Limits 1341 Figure 12 illustrates the same as Figure 11 but this time has eleven 1342 (11) payloads in both directions which exceeds MAX_PAYLOADS. There 1343 is no loss experienced. 1345 CoAP CoAP 1346 Client Server 1347 | | 1348 +--------->| NON FETCH /path M:0x30 T:0xa0 O:0 RT=10 QB1:0/1/1024 1349 +--------->| NON FETCH /path M:0x31 T:0xa1 O:0 RT=10 QB1:1/1/1024 1350 +--------->| [[Payloads 3 - 9 not detailed]] 1351 +--------->| NON FETCH /path M:0x39 T:0xa9 O:0 RT=10 QB1:9/1/1024 1352 [[MAX_PAYLOADS has been reached]] 1353 | [[MAX_PAYLOADS blocks receipt acknowledged by server]] 1354 |<---------+ NON 2.31 M:0x80 T:0xa9 1355 +--------->| NON FETCH /path M:0x3a T:0xaa O:0 RT=10 QB1:10/0/1024 1356 |<---------+ NON 2.05 M:0x81 T:0xaa O:1334 ET=21 QB2:0/1/1024 1357 |<---------+ NON 2.05 M:0x82 T:0xaa O:1334 ET=21 QB2:1/1/1024 1358 |<---------+ [[Payloads 3 - 9 not detailed]] 1359 |<---------+ NON 2.05 M:0x8a T:0xaa O:1334 ET=21 QB2:9/1/1024 1360 [[MAX_PAYLOADS has been reached]] 1361 | [[MAX_PAYLOADS blocks acknowledged by client using 1362 | 'Continue' Q-Block2]] 1363 +--------->| NON FETCH /path M:0x3b T:0xab QB2:10/1/1024 1364 |<---------+ NON 2.05 M:0x8b T:0xaa O:1334 ET=21 QB2:10/0/1024 1365 | ... | 1366 | [[Observe triggered]] 1367 |<---------+ NON 2.05 M:0x8c T:0xaa O:1335 ET=22 QB2:0/1/1024 1368 |<---------+ NON 2.05 M:0x8d T:0xaa O:1335 ET=22 QB2:1/1/1024 1369 |<---------+ [[Payloads 3 - 9 not detailed]] 1370 |<---------+ NON 2.05 M:0x95 T:0xaa O:1335 ET=22 QB2:9/1/1024 1371 [[MAX_PAYLOADS has been reached]] 1372 | [[MAX_PAYLOADS blocks acknowledged by client using 1373 | 'Continue' Q-Block2]] 1374 +--------->| NON FETCH /path M:0x3c T:0xac QB2:10/1/1024 1375 |<---------+ NON 2.05 M:0x96 T:0xaa O:1335 ET=22 QB2:10/0/1024 1376 [[Body has been received]] 1377 | ... | 1379 Figure 12: Example of NON FETCH with Q-Block1 and Q-Block2 Options 1380 (Without Loss) 1382 9.3.3. Handling Recovery 1384 Consider now a scenario where there are some blocks are lost in 1385 transmission as illustrated in Figure 13. 1387 CoAP CoAP 1388 Client Server 1389 | | 1390 +--------->| NON FETCH /path M:0x50 T:0xc0 O:0 RT=31 QB1:0/1/1024 1391 +--->X | NON FETCH /path M:0x51 T:0xc1 O:0 RT=31 QB1:1/1/1024 1392 +--->X | NON FETCH /path M:0x52 T:0xc2 O:0 RT=31 QB1:2/1/1024 1393 +--------->| NON FETCH /path M:0x53 T:0xc3 O:0 RT=31 QB1:3/0/1024 1394 | ... | 1395 [[NON_RECEIVE_TIMEOUT (server) delay expires]] 1397 Figure 13: Example of NON FETCH with Q-Block1 and Q-Block2 Options 1398 (With Loss) 1400 The server realizes that some blocks are missing and asks for the 1401 missing blocks in one go (Figure 14). It does so by indicating which 1402 blocks have not been received in the data portion of the response. 1403 The token used in the response is be the token that was used in the 1404 last block number received payload. The client can then derive the 1405 Request-Tag by matching the token with the sent request. 1407 CoAP CoAP 1408 Client Server 1409 | | 1410 |<---------+ NON 4.08 M:0xa0 T:0xc3 [Missing 1,2 [for RT=31]] 1411 | [[Client responds with missing payloads]] 1412 +--------->| NON FETCH /path M:0x54 T:0xc4 O:0 RT=31 QB1:1/1/1024 1413 +--------->| NON FETCH /path M:0x55 T:0xc5 O:0 RT=31 QB1:2/1/1024 1414 | [[Server received FETCH body, 1415 | starts transmitting response body]] 1416 |<---------+ NON 2.05 M:0xa1 T:0xc3 O:1236 ET=23 QB2:0/1/1024 1417 | X<---+ NON 2.05 M:0xa2 T:0xc3 O:1236 ET=23 QB2:1/1/1024 1418 |<---------+ NON 2.05 M:0xa3 T:0xc3 O:1236 ET=23 QB2:2/1/1024 1419 | X<---+ NON 2.05 M:0xa4 T:0xc3 O:1236 ET=23 QB2:3/0/1024 1420 | ... | 1421 [[NON_RECEIVE_TIMEOUT (client) delay expires]] 1422 | | 1424 Figure 14: Example of NON Request with Q-Block1 Option (Server 1425 Recovery) 1427 The client realizes that not all the payloads of the response have 1428 been returned. The client then asks for the missing blocks in one go 1429 (Figure 15). However, because the original request is spread over 1430 multiple payloads using Q-Block1, the entire FETCH body has to be 1431 used to make the request for the missing payloads. 1433 CoAP CoAP 1434 Client Server 1435 | | 1436 +--------->| NON FETCH /path M:0x56 T:0xc6 RT=31 QB1:0/1/1024\ 1437 | | QB2:1/0/1024\ 1438 | | QB2:3/0/1024 1439 +--------->| NON FETCH /path M:0x57 T:0xc7 RT=31 QB1:1/1/1024\ 1440 | | QB2:1/0/1024\ 1441 | | QB2:3/0/1024 1442 +--------->| NON FETCH /path M:0x58 T:0xc8 RT=31 QB1:2/1/1024\ 1443 | | QB2:1/0/1024\ 1444 | | QB2:3/0/1024 1445 +--------->| NON FETCH /path M:0x59 T:0xc9 RT=31 QB1:3/0/1024\ 1446 | | QB2:1/0/1024\ 1447 | | QB2:3/0/1024 1448 | [[Server received FETCH request, 1449 | starts transmitting missing blocks]] 1450 | X<---+ NON 2.05 M:0xa5 T:0xc9 ET=23 QB2:1/1/1024 1451 |<---------+ NON 2.05 M:0xa6 T:0xc9 ET=23 QB2:3/0/1024 1452 | ... | 1453 [[NON_RECEIVE_TIMEOUT (client) delay expires]] 1454 | [[Client realizes block is still missing and asks for 1455 | missing block]] 1456 +--------->| NON FETCH /path M:0x5a T:0xca RT=31 QB1:0/1/1024\ 1457 | | QB2:1/0/1024 1458 +--------->| NON FETCH /path M:0x5b T:0xcb RT=31 QB1:1/1/1024\ 1459 | | QB2:1/0/1024 1460 +--------->| NON FETCH /path M:0x5c T:0xcc RT=31 QB1:2/1/1024\ 1461 | | QB2:1/0/1024 1462 +--------->| NON FETCH /path M:0x5d T:0xcd RT=31 QB1:3/0/1024\ 1463 | | QB2:1/0/1024 1464 | [[Server received FETCH request, 1465 | starts transmitting missing block]] 1466 |<---------+ NON 2.05 M:0xa7 T:0xcd ET=23 QB2:1/1/1024 1467 [[Body has been received]] 1468 | ... | 1470 Figure 15: Example of NON Request with Q-Block1 Option (Client 1471 Recovery) 1473 10. IANA Considerations 1475 10.1. New CoAP Options 1477 IANA is requested to add the following entries to the "CoAP Option 1478 Numbers" sub-registry [Options]: 1480 +--------+------------------+-----------+ 1481 | Number | Name | Reference | 1482 +========+==================+===========+ 1483 | TBA1 | Q-Block1 | [RFCXXXX] | 1484 | TBA2 | Q-Block2 | [RFCXXXX] | 1485 +--------+------------------+-----------+ 1487 Table 4: CoAP Q-Block1 and Q-Block2 Option Numbers 1489 This document suggests 19 (TBA1) and 51 (TBA2) as a values to be 1490 assigned for the new option numbers. 1492 10.2. New Media Type 1494 This document requests IANA to register the "application/missing- 1495 blocks+cbor-seq" media type in the "Media Types" registry 1496 [IANA-MediaTypes]: 1498 Type name: application 1500 Subtype name: missing-blocks+cbor-seq 1502 Required parameters: N/A 1504 Optional parameters: N/A 1506 Encoding considerations: binary 1508 Security considerations: See the Security Considerations Section of 1509 [This_Document]. 1511 Interoperability considerations: N/A 1513 Published specification: [This_Document] 1515 Applications that use this media type: Data serialization and 1516 deserialization. 1518 Fragment identifier considerations: N/A 1520 Additional information: 1522 Deprecated alias names for this type: N/A 1523 Magic number(s): N/A 1524 File extension(s): N/A 1525 Macintosh file type code(s): N/A 1527 Person & email address to contact for further information: IETF, 1528 iesg@ietf.org 1530 Intended usage: COMMON 1532 Restrictions on usage: none 1534 Author: See Authors' Addresses section. 1536 Change controller: IESG 1538 Provisional registration? No 1540 10.3. New Content Format 1542 This document requests IANA to register the CoAP Content-Format ID 1543 for the "application/missing-blocks+cbor-seq" media type in the "CoAP 1544 Content-Formats" registry [Format]: 1546 o Media Type: application/missing-blocks+cbor-seq 1547 o Encoding: - 1548 o Id: TBD3 1549 o Reference: [RFCXXXX] 1551 11. Security Considerations 1553 Security considerations discussed in Section 7 of [RFC7959] should be 1554 taken into account. 1556 Security considerations discussed in Sections 11.3 and 11.4 of 1557 [RFC7252] should be taken into account. 1559 OSCORE provides end-to-end protection of all information that is not 1560 required for proxy operations and requires that a security context is 1561 set up (Section 3.1 of [RFC8613]). It can be trusted that the source 1562 endpoint is legitimate even if NoSec security mode is used. However, 1563 an intermediary node can modify the unprotected outer Q-Block1 and/or 1564 Q-Block2 Options to cause a Q-Block transfer to fail or keep 1565 requesting all the blocks by setting the M bit and, thus, causing 1566 attack amplification. As discussed in Section 12.1 of [RFC8613], 1567 applications need to consider that certain message fields and 1568 messages types are not protected end-to-end and may be spoofed or 1569 manipulated. It is NOT RECOMMENDED that the NoSec security mode is 1570 used if the Q-Block1 and Q-Block2 Options are to be used. 1572 Security considerations related to the use of Request-Tag are 1573 discussed in Section 5 of [I-D.ietf-core-echo-request-tag]. 1575 12. Acknowledgements 1577 Thanks to Achim Kraus, Jim Schaad, and Michael Richardson for their 1578 comments. 1580 Special thanks to Christian Amsuess, Carsten Bormann, and Marco 1581 Tiloca for their suggestions and several reviews, which improved this 1582 specification significantly. 1584 Some text from [RFC7959] is reused for readers convenience. 1586 13. References 1588 13.1. Normative References 1590 [I-D.ietf-core-echo-request-tag] 1591 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 1592 Request-Tag, and Token Processing", draft-ietf-core-echo- 1593 request-tag-11 (work in progress), November 2020. 1595 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1596 Requirement Levels", BCP 14, RFC 2119, 1597 DOI 10.17487/RFC2119, March 1997, 1598 . 1600 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1601 Application Protocol (CoAP)", RFC 7252, 1602 DOI 10.17487/RFC7252, June 2014, 1603 . 1605 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1606 Application Protocol (CoAP)", RFC 7641, 1607 DOI 10.17487/RFC7641, September 2015, 1608 . 1610 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1611 the Constrained Application Protocol (CoAP)", RFC 7959, 1612 DOI 10.17487/RFC7959, August 2016, 1613 . 1615 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 1616 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 1617 the Constrained Application Protocol (CoAP)", RFC 8075, 1618 DOI 10.17487/RFC8075, February 2017, 1619 . 1621 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 1622 FETCH Methods for the Constrained Application Protocol 1623 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 1624 . 1626 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1627 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1628 May 2017, . 1630 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1631 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 1632 Application Protocol) over TCP, TLS, and WebSockets", 1633 RFC 8323, DOI 10.17487/RFC8323, February 2018, 1634 . 1636 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1637 "Object Security for Constrained RESTful Environments 1638 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1639 . 1641 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 1642 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 1643 . 1645 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1646 Representation (CBOR)", STD 94, RFC 8949, 1647 DOI 10.17487/RFC8949, December 2020, 1648 . 1650 13.2. Informative References 1652 [Format] , . 1655 [I-D.bosh-dots-quick-blocks] 1656 Boucadair, M. and J. Shallow, "Distributed Denial-of- 1657 Service Open Threat Signaling (DOTS) Signal Channel 1658 Configuration Attributes for Faster Block Transmission", 1659 draft-bosh-dots-quick-blocks-00 (work in progress), 1660 January 2021. 1662 [I-D.ietf-dots-telemetry] 1663 Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c., 1664 and J. Shallow, "Distributed Denial-of-Service Open Threat 1665 Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15 1666 (work in progress), December 2020. 1668 [IANA-MediaTypes] 1669 IANA, "Media Types", 1670 . 1672 [Options] , . 1675 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 1676 "Increasing TCP's Initial Window", RFC 6928, 1677 DOI 10.17487/RFC6928, April 2013, 1678 . 1680 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1681 Definition Language (CDDL): A Notational Convention to 1682 Express Concise Binary Object Representation (CBOR) and 1683 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1684 June 2019, . 1686 [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., 1687 Mortensen, A., and N. Teague, "Distributed Denial-of- 1688 Service Open Threat Signaling (DOTS) Signal Channel 1689 Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, 1690 . 1692 Appendix A. Examples with Confirmable Messages 1694 These examples assume NSTART has been increased to at least 4. 1696 The notations provided in Figure 2 are used in the following 1697 subsections. 1699 A.1. Q-Block1 Option 1701 Let's now consider the use Q-Block1 Option with a CON request as 1702 shown in Figure 16. All the blocks are acknowledged (ACK). 1704 CoAP CoAP 1705 Client Server 1706 | | 1707 +--------->| CON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024 1708 +--------->| CON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024 1709 +--------->| CON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024 1710 +--------->| CON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024 1711 |<---------+ ACK 0.00 M:0x01 1712 |<---------+ ACK 0.00 M:0x02 1713 |<---------+ ACK 0.00 M:0x03 1714 |<---------+ ACK 2.04 M:0x04 1715 | | 1717 Figure 16: Example of CON Request with Q-Block1 Option (Without Loss) 1719 Now, suppose that a new body of data is to be sent but with some 1720 blocks dropped in transmission as illustrated in Figure 17. The 1721 client will retry sending blocks for which no ACK was received. 1723 CoAP CoAP 1724 Client Server 1725 | | 1726 +--------->| CON PUT /path M:0x05 T:0xf4 RT=11 QB1:0/1/1024 1727 +--->X | CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 1728 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 1729 +--------->| CON PUT /path M:0x08 T:0xf7 RT=11 QB1:3/1/1024 1730 |<---------+ ACK 0.00 M:0x05 1731 |<---------+ ACK 0.00 M:0x08 1732 | ... | 1733 [[ACK_TIMEOUT (client) delay expires]] 1734 | [[Client retransmits associated packet]] 1735 +--------->| CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 1736 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 1737 |<---------+ ACK 0.00 M:0x06 1738 | ... | 1739 [[ACK_TIMEOUT exponential backoff (client) delay expires]] 1740 | [[Client retransmits associated packet]] 1741 +--->? | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 1742 | ... | 1743 [[Either body transmission failure (acknowledge retry timeout) 1744 or successfully transmitted.]] 1746 Figure 17: Example of CON Request with Q-Block1 Option (Blocks 1747 Recovery) 1749 It is up to the implementation as to whether the application process 1750 stops trying to send this particular body of data on reaching 1751 MAX_RETRANSMIT for any payload, or separately tries to initiate the 1752 new transmission of the payloads that have not been acknowledged 1753 under these adverse traffic conditions. 1755 If there is likely to be the possibility of network transient losses, 1756 then the use of NON should be considered. 1758 A.2. Q-Block2 Option 1760 An example of the use of Q-Block2 Option with Confirmable messages is 1761 shown in Figure 18. 1763 Client Server 1764 | | 1765 +--------->| CON GET /path M:0x01 T:0xf0 O:0 QB2:0/0/1024 1766 |<---------+ ACK 2.05 M:0x01 T:0xf0 O:1234 ET=21 QB2:0/1/1024 1767 |<---------+ ACK 2.05 M:0xe1 T:0xf0 O:1234 ET=21 QB2:1/1/1024 1768 |<---------+ ACK 2.05 M:0xe2 T:0xf0 O:1234 ET=21 QB2:2/1/1024 1769 |<---------+ ACK 2.05 M:0xe3 T:0xf0 O:1234 ET=21 QB2:3/0/1024 1770 | ... | 1771 | [[Observe triggered]] 1772 |<---------+ CON 2.05 M:0xe4 T:0xf0 O:1235 ET=22 QB2:0/1/1024 1773 |<---------+ CON 2.05 M:0xe5 T:0xf0 O:1235 ET=22 QB2:1/1/1024 1774 |<---------+ CON 2.05 M:0xe6 T:0xf0 O:1235 ET=22 QB2:2/1/1024 1775 |<---------+ CON 2.05 M:0xe7 T:0xf0 O:1235 ET=22 QB2:3/0/1024 1776 |--------->+ ACK 0.00 M:0xe4 1777 |--------->+ ACK 0.00 M:0xe5 1778 |--------->+ ACK 0.00 M:0xe6 1779 |--------->+ ACK 0.00 M:0xe7 1780 | ... | 1781 | [[Observe triggered]] 1782 |<---------+ CON 2.05 M:0xe8 T:0xf0 O:1236 ET=23 QB2:0/1/1024 1783 | X<---+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 1784 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 1785 |<---------+ CON 2.05 M:0xeb T:0xf0 O:1236 ET=23 QB2:3/0/1024 1786 |--------->+ ACK 0.00 M:0xe8 1787 |--------->+ ACK 0.00 M:0xeb 1788 | ... | 1789 [[ACK_TIMEOUT (server) delay expires (twice in this example)]] 1790 | [[Server retransmits associated packet]] 1791 |<---------+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 1792 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 1793 |--------->+ ACK 0.00 M:0xe9 1794 | ... | 1795 [[ACK_TIMEOUT exponential backoff (server) delay expires]] 1796 | [[Server retransmits associated packet]] 1797 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 1798 | ... | 1799 [[Either body transmission failure (acknowledge retry timeout) 1800 or successfully transmitted.]] 1802 Figure 18: Example of CON Notifications with Q-Block2 Option 1804 It is up to the implementation as to whether the application process 1805 stops trying to send this particular body of data on reaching 1806 MAX_RETRANSMIT for any payload, or separately tries to initiate the 1807 new transmission of the payloads that have not been acknowledged 1808 under these adverse traffic conditions. 1810 If there is likely to be the possibility of network transient losses, 1811 then the use of NON should be considered. 1813 Authors' Addresses 1815 Mohamed Boucadair 1816 Orange 1817 Rennes 35000 1818 France 1820 Email: mohamed.boucadair@orange.com 1822 Jon Shallow 1823 United Kingdom 1825 Email: supjps-ietf@jpshallow.com