idnits 2.17.1 draft-ietf-core-new-block-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 9 characters 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 (January 6, 2021) is 1206 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 1154, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-11 == 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 (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CORE M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track J. Shallow 5 Expires: July 10, 2021 January 6, 2021 7 Constrained Application Protocol (CoAP) Block-Wise Transfer Options for 8 Faster Transmission 9 draft-ietf-core-new-block-04 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 10, 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 . . . . . . . . . . . . . . . . 8 65 3.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 11 66 3.5. Using Observe and Q-Block2 Options . . . . . . . . . . . 13 67 3.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 13 68 3.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 13 69 4. The Use of 4.08 (Request Entity Incomplete) Response Code . . 13 70 5. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 15 71 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 15 72 6.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 15 73 6.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 15 74 7. Caching Considerations . . . . . . . . . . . . . . . . . . . 18 75 8. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 20 76 9. Examples of Selective Block Recovery . . . . . . . . . . . . 20 77 9.1. Q-Block1 Option: Non-Confirmable Example . . . . . . . . 20 78 9.2. Q-Block2 Option: Non-Confirmable Example . . . . . . . . 21 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 80 10.1. New CoAP Options . . . . . . . . . . . . . . . . . . . . 24 81 10.2. New Media Type . . . . . . . . . . . . . . . . . . . . . 24 82 10.3. New Content Format . . . . . . . . . . . . . . . . . . . 25 83 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 84 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 85 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 86 13.1. Normative References . . . . . . . . . . . . . . . . . . 26 87 13.2. Informative References . . . . . . . . . . . . . . . . . 28 88 Appendix A. Examples with Confirmable Messages . . . . . . . . . 29 89 A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 29 90 A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 30 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 93 1. Introduction 95 The Constrained Application Protocol (CoAP) [RFC7252], although 96 inspired by HTTP, was designed to use UDP instead of TCP. The 97 message layer of CoAP over UDP includes support for reliable 98 delivery, simple congestion control, and flow control. [RFC7959] 99 introduced the CoAP Block1 and Block2 Options to handle data records 100 that cannot fit in a single IP packet, so not having to rely on IP 101 fragmentation and was further updated by [RFC8323] for use over TCP, 102 TLS, and WebSockets. 104 The CoAP Block1 and Block2 Options work well in environments where 105 there are no or minimal packet losses. These options operate 106 synchronously where each individual block has to be requested and can 107 only ask for (or send) the next block when the request for the 108 previous block has completed. Packet, and hence block transmission 109 rate, is controlled by Round Trip Times (RTTs). 111 There is a requirement for these blocks of data to be transmitted at 112 higher rates under network conditions where there may be asymmetrical 113 transient packet loss (i.e., responses may get dropped). An example 114 is when a network is subject to a Distributed Denial of Service 115 (DDoS) attack and there is a need for DDoS mitigation agents relying 116 upon CoAP to communicate with each other (e.g., 117 [I-D.ietf-dots-telemetry]). As a reminder, [RFC7959] recommends the 118 use of Confirmable (CON) responses to handle potential packet loss. 119 However, such a recommendation does not work with a flooded pipe DDoS 120 situation. 122 1.1. Alternative CoAP Block-Wise Transfer Options 124 This document introduces the CoAP Q-Block1 and Q-Block2 Options. 125 These options are similar in operation to the CoAP Block1 and Block2 126 Options, respectively. They are not a replacement for them, but have 127 the following benefits: 129 o They can operate in environments where packet loss is highly 130 asymmetrical. 132 o They enable faster transmissions of sets of blocks of data with 133 less packet interchanges. 135 o They support faster recovery should any of the blocks get lost in 136 transmission. 138 o They support sending an entire body using Non-confirmable (NON) 139 without requiring a response from the peer. 141 There are the following disadvantages over using CoAP Block1 and 142 Block2 Options: 144 o Loss of lock-stepping so payloads are not always received in the 145 correct (block ascending) order. 147 o Additional congestion control measures need to be put in place for 148 NON (Section 6.2). 150 o To reduce the transmission times for CON transmission of large 151 bodies, NSTART needs to be increased from 1, but this affects 152 congestion control where other parameters need to be tuned 153 (Section 4.7 of [RFC7252]). Such tuning is out of scope of this 154 document. 156 Using NON messages, the faster transmissions occur as all the blocks 157 can be transmitted serially (as are IP fragmented packets) without 158 having to wait for a response or next request from the remote CoAP 159 peer. Recovery of missing blocks is faster in that multiple missing 160 blocks can be requested in a single CoAP packet. Even if there is 161 asymmetrical packet loss, a body can still be sent and received by 162 the peer whether the body comprises of a single or multiple payloads 163 assuming no recovery is required. 165 Note that similar performance benefits can be applied to Confirmable 166 messages if the value of NSTART is increased from 1 (Section 4.7 of 167 [RFC7252]). However, the use of Confirmable messages will not work 168 if there is asymmetrical packet loss. Some examples with Confirmable 169 messages are provided in Appendix A. 171 There is little, if any, benefit of using these options with CoAP 172 running over a reliable connection [RFC8323]. In this case, there is 173 no differentiation between Confirmable and NON as they are not used. 175 A CoAP endpoint can acknowledge all or a subset of the blocks. 176 Concretely, the receiving CoAP endpoint informs the CoAP sender 177 endpoint either successful receipt or reports on all blocks in the 178 body that have not yet been received. The CoAP sender endpoint will 179 then retransmit only the blocks that have been lost in transmission. 181 Q-Block1 and Q-Block2 Options can be used instead of Block1 and 182 Block2 Options when the different transmission properties are 183 required. If the new option is not supported by a peer, then 184 transmissions can fall back to using Block1 and Block2 Options, 185 respectively. 187 The deviations from Block1 and Block2 Options are specified in 188 Section 3. Pointers to appropriate [RFC7959] sections are provided. 190 The specification refers to the base CoAP methods defined in 191 Section 5.8 of [RFC7252] and the new CoAP methods, FETCH, PATCH, and 192 iPATCH introduced in [RFC8132]. 194 Q-Block1 and Q-Block2 Options are designed to work with Non- 195 confirmable requests and responses, in particular. 197 1.2. CoAP Response Code (4.08) Usage 199 This document adds a media type for the 4.08 (Request Entity 200 Incomplete) response defining an additional message format for 201 reporting on payloads using the Q-Block1 Option that are not received 202 by the server. 204 See Section 4 for more details. 206 1.3. Applicability Scope 208 The block-wise transfer specified in [RFC7959] covers the general 209 case, but falls short in situations where packet loss is highly 210 asymmetrical. The mechanism specified in this document provides 211 roughly similar features to the Block1/Block2 Options. It provides 212 additional properties that are tailored towards the intended use case 213 of Non-Confirmable transmission. Concretely, this mechanism 214 primarily targets applications such as DDoS Open Threat Signaling 215 (DOTS) that can't use Confirmable (CON) responses to handle potential 216 packet loss and that support application-specific mechanisms to 217 assess whether the remote peer is able to handle the messages sent by 218 a CoAP endpoint (e.g., DOTS heartbeats in Section 4.7 of [RFC8782]). 220 The mechanism includes guards to prevent a CoAP agent from 221 overloading the network by adopting an aggressive sending rate. 222 These guards MUST be followed in addition to the existing CoAP 223 congestion control as specified in Section 4.7 of [RFC7252]. See 224 Section 6 for more details. 226 This mechanism is not intended for general CoAP usage, and any use 227 outside the intended use case should be carefully weighed against the 228 loss of interoperability with generic CoAP applications. It is hoped 229 that the experience gained with this mechanism can feed future 230 extensions of the block-wise mechanism that will both be generally 231 applicable and serve this particular use case. 233 It is not recommended that these options are used in a NoSec security 234 mode (Section 9 of [RFC7252]) as the source endpoint needs to be 235 trusted. Using OSCORE [RFC8613] does provide a security context and, 236 hence, a trust of the source endpoint. However, using a NoSec 237 security mode may still be inadequate for reasons discussed in 238 Section 11. 240 2. Terminology 242 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 243 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 244 "OPTIONAL" in this document are to be interpreted as described in BCP 245 14 [RFC2119][RFC8174] when, and only when, they appear in all 246 capitals, as shown here. 248 Readers should be familiar with the terms and concepts defined in 249 [RFC7252]. 251 The terms "payload" and "body" are defined in [RFC7959]. The term 252 "payload" is thus used for the content of a single CoAP message 253 (i.e., a single block being transferred), while the term "body" is 254 used for the entire resource representation that is being transferred 255 in a block-wise fashion. 257 3. The Q-Block1 and Q-Block2 Options 259 3.1. Properties of Q-Block1 and Q-Block2 Options 261 The properties of Q-Block1 and Q-Block2 Options are shown in Table 1. 262 The formatting of this table follows the one used in Table 4 of 263 [RFC7252] (Section 5.10). The C, U, N, and R columns indicate the 264 properties Critical, UnSafe, NoCacheKey, and Repeatable defined in 265 Section 5.4 of [RFC7252]. Only Critical and UnSafe columns are 266 marked for the Q-Block1 Option. Critical, UnSafe, and Repeatable 267 columns are marked for the Q-Block2 Option. As these options are 268 UnSafe, NoCacheKey has no meaning and so is marked with a dash. 270 +--------+---+---+---+---+--------------+--------+--------+---------+ 271 | Number | C | U | N | R | Name | Format | Length | Default | 272 +========+===+===+===+===+==============+========+========+=========+ 273 | TBA1 | x | x | - | | Q-Block1 | uint | 0-3 | (none) | 274 | TBA2 | x | x | - | x | Q-Block2 | uint | 0-3 | (none) | 275 +--------+---+---+---+---+--------------+--------+--------+---------+ 277 Table 1: CoAP Q-Block1 and Q-Block2 Option Properties 279 The Q-Block1 and Q-Block2 Options can be present in both the request 280 and response messages. The Q-Block1 Option pertains to the request 281 payload and the Q-Block2 Option pertains to the response payload. 282 The Content-Format Option applies to the body, not to the payload 283 (i.e., it must be the same for all payloads of the same body). 285 Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH, 286 PATCH, and iPATCH requests and their responses (2.01 and 2.04). 288 Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and 289 iPATCH requests and their payload-bearing responses (2.01, 2.03, 290 2.04, and 2.05) (Section 5.5 of [RFC7252]). 292 A CoAP endpoint (or proxy) MUST support either both or neither of the 293 Q-Block1 and Q-Block2 Options. 295 To indicate support for Q-Block2 responses, the CoAP client MUST 296 include the Q-Block2 Option in a GET or similar request, the Q-Block2 297 Option in a PUT or similar request, or the Q-Block1 Option in a PUT 298 or similar so that the server knows that the client supports this 299 Q-Block2 functionality should it need to send back a body that spans 300 multiple payloads. Otherwise, the server would use the Block2 Option 301 (if supported) to send back a message body that is too large to fit 302 into a single IP packet [RFC7959]. 304 If Q-Block1 Option is present in a request or Q-Block2 Option in a 305 response (i.e., in that message to the payload of which it pertains), 306 it indicates a block-wise transfer and describes how this specific 307 block-wise payload forms part of the entire body being transferred. 308 If it is present in the opposite direction, it provides additional 309 control on how that payload will be formed or was processed. 311 Implementation of the Q-Block1 and Q-Block2 Options is intended to be 312 optional. However, when it is present in a CoAP message, it MUST be 313 processed (or the message rejected). Therefore, Q-Block1 and 314 Q-Block2 Options are identified as Critical options. 316 The Q-Block1 and Q-Block2 Options are unsafe to forward. That is, a 317 CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option 318 MUST reject the request or response that uses either option. 320 The Q-Block2 Option is repeatable when requesting retransmission of 321 missing blocks, but not otherwise. Except that case, any request 322 carrying multiple Q-Block1 (or Q-Block2) Options MUST be handled 323 following the procedure specified in Section 5.4.5 of [RFC7252]. 325 The Q-Block1 and Q-Block2 Options, like the Block1 and Block2 326 Options, are both a class E and a class U in terms of OSCORE 327 processing (Table 2). The Q-Block1 (or Q-Block2) Option MAY be an 328 Inner or Outer option (see Section 4.1 of [RFC8613]). The Inner and 329 Outer values are therefore independent of each other. The Inner 330 option is encrypted and integrity protected between clients and 331 servers, and provides message body identification in case of end-to- 332 end fragmentation of requests. The Outer option is visible to 333 proxies and labels message bodies in case of hop-by-hop fragmentation 334 of requests. 336 +--------+-----------------+---+---+ 337 | Number | Name | E | U | 338 +========+=================+===+===+ 339 | TBA1 | Q-Block1 | x | x | 340 | TBA2 | Q-Block2 | x | x | 341 +--------+-----------------+---+---+ 342 Table 2: OSCORE Protection of Q-Block1 and Q-Block2 Options 344 3.2. Structure of Q-Block1 and Q-Block2 Options 346 The structure of Q-Block1 and Q-Block2 Options follows the structure 347 defined in Section 2.2 of [RFC7959]. 349 There is no default value for the Q-Block1 and Q-Block2 Options. 350 Absence of one of these options is equivalent to an option value of 0 351 with respect to the value of block number (NUM) and more bit (M) that 352 could be given in the option, i.e., it indicates that the current 353 block is the first and only block of the transfer (block number is 354 set to 0, M is unset). However, in contrast to the explicit value 0, 355 which would indicate a size of the block (SZX) of 0, and thus a size 356 value of 16 bytes, there is no specific explicit size implied by the 357 absence of the option -- the size is left unspecified. (As for any 358 uint, the explicit value 0 is efficiently indicated by a zero-length 359 option; this, therefore, is different in semantics from the absence 360 of the option). 362 3.3. Using the Q-Block1 Option 364 The Q-Block1 Option is used when the client wants to send a large 365 amount of data to the server using the POST, PUT, FETCH, PATCH, or 366 iPATCH methods where the data and headers do not fit into a single 367 packet. 369 When Q-Block1 Option is used, the client MUST include a Request-Tag 370 Option [I-D.ietf-core-echo-request-tag]. The Request-Tag value MUST 371 be the same for all of the requests for the body of data that is 372 being transferred. It is also used to identify a particular payload 373 of a body that needs to be retransmitted. The Request-Tag is opaque, 374 the server still treats it as opaque but the client SHOULD ensure 375 that it is unique for every different body of transmitted data. 377 Implementation Note: It is suggested that the client treats the 378 Request-Tag as an unsigned integer of 8 bytes in length. An 379 implementation may want to consider limiting this to 4 bytes to 380 reduce packet overhead size. The initial Request-Tag value should 381 be randomly generated and then subsequently incremented by the 382 client whenever a new body of data is being transmitted between 383 peers. 385 Section 3.6 discusses the use of Size1 Option. 387 For Confirmable transmission, the server continues to acknowledge 388 each packet, but a response is not required (whether separate or 389 piggybacked) until successful receipt of the body or, if some of the 390 payloads are sent as Non-confirmable and have not arrived, a 391 retransmit missing payloads response is needed. 393 Each individual payload of the body is treated as a new request (see 394 Section 5). 396 The client MUST send the payloads with the block numbers increasing, 397 starting from zero, until the body is complete (subject to any 398 congestion control (Section 6)). Any missing payloads requested by 399 the server must in addition be separately transmitted with increasing 400 block numbers. 402 The following Response Codes are used: 404 2.01 (Created) 406 This Response Code indicates successful receipt of the entire body 407 and the resource was created. 409 2.04 (Changed) 411 This Response Code indicates successful receipt of the entire body 412 and the resource was updated. 414 2.31 (Continue) 416 This Response Code can be used to indicate that all of the blocks 417 up to and including the Q-Block1 Option block NUM (all having the 418 M bit set) in the response have been successfully received. 420 A response using this Response Code SHOULD NOT be generated for 421 every received Q-Block1 Option request. It SHOULD only be 422 generated when all the payload requests are Non-confirmable and 423 MAX_PAYLOADS payloads have been received by the server 424 (Section 6.2). 426 It SHOULD NOT be generated for CON. 428 4.00 (Bad Request) 429 This Response Code MUST be returned if the request does not 430 include both a Request-Tag Option and a Size1 Option but does 431 include a Q-Block1 option. 433 4.02 (Bad Option) 435 Either this Response Code or a reset message MUST be returned if 436 the server does not support the Q-Block1 Option. 438 4.08 (Request Entity Incomplete) 440 This Response Code returned without Content-Type "application/ 441 missing-blocks+cbor-seq" (Section 10.3) is handled as in 442 Section 2.9.2 [RFC7959]. 444 This Response Code returned with Content-Type "application/ 445 missing-blocks+cbor-seq" indicates that some of the payloads are 446 missing and need to be resent. The client then retransmits the 447 missing payloads using the same Request-Tag, Size1 and Q-Block1 to 448 specify the block number, SZX, and M bit as appropriate. 450 The Request-Tag value to use is determined from the token in the 451 4.08 (Request Entity Incomplete) response and then finding the 452 matching client request which contains the Request-Tag that is 453 being used for this Q-Block1 body. 455 4.13 (Request Entity Too Large) 457 This Response Code can be returned under similar conditions to 458 those discussed in Section 2.9.3 of [RFC7959]. 460 This Response Code can be returned if there is insufficient space 461 to create a response PDU with a block size of 16 bytes (SZX = 0) 462 to send back all the response options as appropriate. In this 463 case, the Size1 Option is not included. 465 If the server has not received all the payloads of a body, but one or 466 more NON payloads have been received, it SHOULD wait for up to 467 NON_RECEIVE_TIMEOUT (Section 6.2) before sending a 4.08 (Request 468 Entity Incomplete) response. Further considerations related to the 469 transmission timings of 4.08 (Request Entity Incomplete) and 2.31 470 (Continue) Response Codes are discussed in Section 6.2. 472 If a server receives payloads with different Request-Tags for the 473 same resource, it should continue to process all the bodies as it has 474 no way of determining which is the latest version, or which body, if 475 any, the client is terminating the transmission for. 477 If the client elects to stop the transmission of a complete body, it 478 SHOULD "forget" all tracked tokens associated with the body's 479 Request-Tag so that a reset message is generated for the invalid 480 token in the 4.08 (Request Entity Incomplete) response. The server 481 on receipt of the reset message SHOULD delete the partial body. 483 If the server receives a duplicate block with the same Request-Tag, 484 it SHOULD ignore the payload of the packet, but MUST still respond as 485 if the block was received for the first time. 487 A server SHOULD only maintain a partial body (missing payloads) for 488 up to NON_PARTIAL_TIMEOUT (Section 6.2). 490 3.4. Using the Q-Block2 Option 492 In a request for any block number, the M bit unset indicates the 493 request is just for that block. If the M bit is set, this indicates 494 that this is a request for that block and for all of the remaining 495 blocks within the body. If the request includes multiple Q-Block2 496 Options and these options overlap (e.g., combination of M being set 497 (this and all the later blocks) and being unset (this individual 498 block)) resulting in an individual block being requested multiple 499 times, the server MUST only send back one instance of that block. 500 This behavior is meant to prevent amplification attacks. 502 The payloads sent back from the server as a response MUST all have 503 the same ETag (Section 5.10.6 of [RFC7252]) for the same body. The 504 server MUST NOT use the same ETag value for different representations 505 of a resource. 507 The ETag is opaque, the client still treats it as opaque but the 508 server SHOULD ensure that it is unique for every different body of 509 transmitted data. 511 Implementation Note: It is suggested that the server treats the 512 ETag as an unsigned integer of 8 bytes in length. An 513 implementation may want to consider limiting this to 4 bytes to 514 reduce packet overhead size. The initial ETag value should be 515 randomly generated and then subsequently incremented by the server 516 whenever a new body of data is being transmitted between peers. 518 Section 3.6 discusses the use of Size2 Option. 520 The client may elect to request any detected missing blocks or just 521 ignore the partial body. This decision is implementation specific. 523 The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 6.2) 524 after the last received payload for NON payloads before issuing a 525 GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or 526 more Q-Block2 Options that define the missing blocks with the M bit 527 unset. Further considerations related to the transmission timing for 528 missing requests are discussed in Section 6.2. 530 The requested missing block numbers MUST have an increasing block 531 number in each additional Q-Block2 Option with no duplicates. The 532 server SHOULD respond with a 4.00 (Bad Request) to requests not 533 adhering to this behavior. 535 For Confirmable responses, the client continues to acknowledge each 536 packet. The server will detect failure to send a packet, but the 537 client can issue, after a MAX_TRANSMIT_SPAN delay, a separate GET, 538 POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as needed. 540 If the client receives a duplicate block with the same ETag, it 541 SHOULD silently ignore the packet. 543 A client SHOULD only maintain a partial body (missing payloads) for 544 up to NON_PARTIAL_TIMEOUT (Section 6.2) or as defined by the Max-Age 545 Option (or its default), whichever is the less. 547 The ETag Option should not be used in the request for missing blocks 548 as the server could respond with a 2.03 (Valid Response) with no 549 payload. It can be used in the request if the client wants to check 550 the freshness of the currently cached body response. 552 If the server detects part way through a body transfer that the 553 resource data has changed and the server is not maintaining a cached 554 copy of the old data, then the body response SHOULD be restarted with 555 a different ETag Option value. Any subsequent missing block requests 556 MUST be responded to using the latest ETag Option value. 558 If the server responds during a body update with a different ETag 559 Option value (as the resource representation has changed), then the 560 client should treat the partial body with the old ETag as no longer 561 being fresh. 563 If the server transmits a new body of data (e.g., a triggered 564 Observe) with a new ETag to the same client as an additional 565 response, the client should remove any partially received body held 566 for a previous ETag for that resource as it is unlikely the missing 567 blocks can be retrieved. 569 If there is insufficient space to create a response PDU with a block 570 size of 16 bytes (SZX = 0) to send back all the response options as 571 appropriate, a 4.13 (Request Entity Too Large) is returned without 572 the Size1 Option. 574 3.5. Using Observe and Q-Block2 Options 576 As the blocks of the body are sent without waiting for 577 acknowledgement of the individual blocks, the Observe value [RFC7641] 578 MUST be the same for all the blocks of the same body. 580 If the client requests missing blocks, this is treated as a new 581 Request and the Observe Option MUST NOT be included. If the ETag 582 value in the response changes, then the previously received partial 583 body should be considered as not fresh and the whole body re- 584 requested. 586 3.6. Using Size1 and Size2 Options 588 Section 4 of [RFC7959] defines two CoAP options: Size1 for indicating 589 the size of the representation transferred in requests and Size2 for 590 indicating the size of the representation transferred in responses. 592 The Size1 or Size2 option values MUST exactly represent the size of 593 the data on the body so that any missing data can easily be 594 determined. 596 The Size1 Option MUST be used with the Q-Block1 Option when used in a 597 request. The Size2 Option MUST be used with the Q-Block2 Option when 598 used in a response. 600 If Size1 or Size2 Options are used, they MUST be used in all payloads 601 of the body and MUST preserve the same value in each of those 602 payloads. 604 3.7. Using Q-Block1 and Q-Block2 Options Together 606 The behavior is similar to the one defined in Section 3.3 of 607 [RFC7959] with Q-Block1 substituted for Block1 and Q-Block2 for 608 Block2. 610 4. The Use of 4.08 (Request Entity Incomplete) Response Code 612 4.08 (Request Entity Incomplete) Response Code has a new Content-Type 613 "application/missing-blocks+cbor-seq" used to indicate that the 614 server has not received all of the blocks of the request body that it 615 needs to proceed. 617 Likely causes are the client has not sent all blocks, some blocks 618 were dropped during transmission, or the client has sent them 619 sufficiently long ago that the server has already discarded them. 621 The data payload of the 4.08 (Request Entity Incomplete) response is 622 encoded as a CBOR Sequence [RFC8742]. There are one or more missing 623 CBOR encoded missing block numbers. The missing block numbers MUST 624 be unique in each 4.08 (Request Entity Incomplete) response when 625 created by the server; the client SHOULD drop any duplicates in the 626 same 4.08 (Request Entity Incomplete) response. 628 The Content-Format Option (Section 5.10.3 of [RFC7252]) MUST be used 629 in the 4.08 (Request Entity Incomplete) response. It MUST be set to 630 "application/missing-blocks+cbor-seq" (see Section 10.3). 632 The Concise Data Definition Language [RFC8610] for the data 633 describing these missing blocks is as follows: 635 ; This defines an array, the elements of which are to be used 636 ; in a CBOR Sequence: 637 payload = [+ missing-block-number] 638 ; A unique block number not received: 639 missing-block-number = uint 641 Figure 1: Structure of the Missing Blocks Payload 643 The token to use for the response SHOULD be the token that was used 644 in the highest block number received payload. The Q-Block1 Option 645 from the same packet SHOULD be included. 647 If the size of the 4.08 (Request Entity Incomplete) response packet 648 is larger than that defined by Section 4.6 [RFC7252], then the number 649 of missing blocks MUST be limited so that the response can fit into a 650 single packet. If this is the case, then the server can send 651 subsequent 4.08 (Request Entity Incomplete) responses containing the 652 missing blocks on receipt of a new request providing a missing 653 payload with the same Request-Tag. 655 The missing blocks MUST be reported in ascending order without any 656 duplicates. The client SHOULD silently drop 4.08 (Request Entity 657 Incomplete) responses not adhering with this behavior. 659 Implementation Note: Updating the payload without overflowing the 660 overall packet size as each block number can be of varying length 661 needs consideration. It is possible to use Indefinite-Length 662 Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit the 663 array count to 23 so that the initial byte with the array major 664 type and data length in the additional information can be updated 665 with the overall count once the payload count is confirmed. 666 Further restricting the count to MAX_PAYLOADS means that 667 congestion control is less likely to be invoked on the server. 669 The 4.08 (Request Entity Incomplete) with Content-Type "application/ 670 missing-blocks+cbor-seq" SHOULD NOT be used when using Confirmable 671 requests or a reliable connection [RFC8323] as the client will be 672 able to determine that there is a transmission failure of a 673 particular payload and hence that the server is missing that payload. 675 5. The Use of Tokens 677 Each new request MUST use a unique Token (Section 4 of 678 [I-D.ietf-core-echo-request-tag]). Additional responses may use the 679 same Token. 681 Implementation Note: To minimize on the number of tokens that have 682 to be tracked by clients, it is recommended that the bottom 32 683 bits is kept the same for the same body and the upper 32 bits 684 contains the individual payload number. 686 Servers continue to treat the token as a unique opaque entity. If 687 an individual payload has to be resent (e.g., requested upon 688 packet loss), then the retransmitted packet is treated as a new 689 request (i.e., the bottom 32 bits must change). 691 6. Congestion Control 693 The transmission of the payloads of a body either SHOULD all be 694 Confirmable or all be Non-confirmable. This is meant to simplify the 695 congestion control procedure. 697 6.1. Confirmable (CON) 699 Congestion control for CON requests and responses is specified in 700 Section 4.7 of [RFC7252]. For faster transmission rates, NSTART will 701 need to be increased from 1. However, the other CON congestion 702 control parameters will need to be tuned to cover this change. This 703 tuning is out of scope of this document as it is expected that all 704 requests and responses using Q-Block1 and Q-Block2 will be Non- 705 confirmable. 707 It is implementation specific as to whether there should be any 708 further requests for missing data as there will have been significant 709 transmission failure as individual payloads will have failed after 710 MAX_TRANSMIT_SPAN. 712 6.2. Non-confirmable (NON) 714 This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT, 715 NON_RECEIVE_TIMEOUT, NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT 716 primarily for use with NON. 718 MAX_PAYLOADS should be configurable with a default value of 10. Both 719 CoAP endpoints SHOULD have the same value (otherwise there will be 720 transmission delays in one direction) and the value MAY be negotiated 721 between the endpoints to a common value by using a higher level 722 protocol (out of scope of this document). This is the maximum number 723 of payloads that can be transmitted at any one time. 725 Note: The default value of 10 is chosen for reasons similar to 726 those discussed in Section 5 of [RFC6928]. 728 NON_TIMEOUT is the maximum period of delay between sending sets of 729 MAX_PAYLOADS payloads for the same body. NON_TIMEOUT has the same 730 value as ACK_TIMEOUT (Section 4.8 of [RFC7252]). 732 NON_RECEIVE_TIMEOUT is the maximum time to wait for a missing payload 733 before requesting retransmission. NON_RECEIVE_TIMEOUT has a value of 734 twice NON_TIMEOUT. 736 NON_PROBING_WAIT is used to limit the potential wait needed 737 calculated when using PROBING_WAIT. NON_PROBING_WAIT has the same 738 value as computed for EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). 740 NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. 741 NON_PARTIAL_TIMEOUT has the same value as computed for 742 EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). 744 +---------------------+---------------+ 745 | Parameter Name | Default Value | 746 +=====================+===============| 747 | MAX_PAYLOADS | 10 | 748 | NON_TIMEOUT | 2 s | 749 | NON_RECEIVE_TIMEOUT | 4 s | 750 | NON_PROBING_WAIT | 247 s | 751 | NON_PARTIAL_TIMEOUT | 247 s | 752 +---------------------+---------------+ 754 Table 3: Derived Protocol Parameters 756 PROBING_RATE parameter in CoAP indicates the average data rate that 757 must not be exceeded by a CoAP endpoint in sending to a peer endpoint 758 that does not respond. The single body of blocks will be subjected 759 to PROBING_RATE (Section 4.7 of [RFC7252]), not the individual 760 packets. If the wait time between sending bodies that are not being 761 responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the 762 gap time is limited to NON_PROBING_WAIT. 764 Note: For the particular DOTS application, PROBING_RATE and other 765 transmission parameters are negotiated between peers. Even when 766 not negotiated, the DOTS application uses customized defaults as 767 discussed in Section 4.5.2 of [RFC8782]. 769 Each NON 4.08 (Request Entity Incomplete) response is subject to 770 PROBING_RATE. 772 Each NON GET or FETCH request using Q-Block2 Option is subject to 773 PROBING_RATE. 775 As the sending of many payloads of a single body may itself cause 776 congestion, it is RECOMMENDED that after transmission of every set of 777 MAX_PAYLOADS payloads of a single body, a delay is introduced of 778 NON_TIMEOUT before sending the next set of payloads to manage 779 potential congestion issues. 781 If the CoAP peer reports at least one payload has not arrived for 782 each body for at least a 24 hour period and it is known that there 783 are no other network issues over that period, then the value of 784 MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1) and 785 the situation re-evaluated for another 24 hour period until there is 786 no report of missing payloads under normal operating conditions. 787 Note that the CoAP peer will not know about the MAX_PAYLOADS change 788 until it is reconfigured. As a consequence, the peer may indicate 789 that there are some missing payloads prior to the actual payload 790 being transmitted as all of its MAX_PAYLOADS payloads have not 791 arrived. 793 The sending of a set of missing payloads of a body is subject to 794 MAX_PAYLOADS set of payloads. 796 For Q-Block1 Option, if the server responds with a 2.31 (Continue) 797 Response Code for the latest payload sent, then the client can 798 continue to send the next set of payloads without any delay. If the 799 server responds with a 4.08 (Request Entity Incomplete) Response 800 Code, then the missing payloads SHOULD be retransmitted before going 801 into another NON_TIMEOUT delay prior to sending the next set of 802 payloads. 804 For the server receiving NON Q-Block1 requests, it SHOULD send back a 805 2.31 (Continue) or 4.08 (Request Entity Incomplete) Response Code on 806 receipt of the last of the MAX_PAYLOADS payloads to prevent the 807 client unnecessarily delaying. If the last of the MAX_PAYLOADS 808 payloads does not arrive (or the final payload where the M bit is not 809 set does not arrive), then the server SHOULD delay for 810 NON_RECEIVE_TIMEOUT before sending the 4.08 (Request Entity 811 Incomplete) Response Code. 813 It is possible that the client may start transmitting the next set of 814 MAX_PAYLOADS payloads before the server times out on waiting for the 815 last of the previous MAX_PAYLOADS payloads. On receipt of the first 816 payload from the new set of MAX_PAYLOADS payloads, the server SHOULD 817 send a 4.08 (Request Entity Incomplete) Response Code indicating any 818 missing payloads from any previous MAX_PAYLOADS payloads. Upon 819 receipt of the 4.08 (Request Entity Incomplete) Response Code, the 820 client SHOULD send the missing payloads before continuing to send the 821 remainder of the MAX_PAYLOADS payloads and then go into another 822 NON_TIMEOUT delay prior to sending the next set of payloads. 824 For the client receiving NON Q-Block2 responses, it SHOULD send a 825 request for the next set of payloads or a request for the missing 826 payloads upon receipt of the last of the MAX_PAYLOADS payloads to 827 prevent the server unnecessarily delaying the transmission of the 828 body. If the last of the MAX_PAYLOADS payloads does not arrive (or 829 the final payload where the M bit is not set does not arrive), then 830 the client SHOULD delay for NON_RECEIVE_TIMEOUT before sending the 831 request for the missing payloads. 833 The request that the client sends to acknowledge the receipt of all 834 the current set of MAX_PAYLOADS payloads SHOULD contain a special 835 case Q-Block2 Option with NUM set to the first block of the next set 836 of MAX_PAYLOADS payloads and the M bit set to 1. The server SHOULD 837 recognize this special case as a continue request and just continue 838 the transmission of the body (including Observe Option, if 839 appropriate for an unsolicited response) rather than as a request for 840 missing blocks. 842 The client does not need to acknowledge the receipt of the entire 843 body. 845 Note: If there is asymmetric traffic loss causing responses to 846 never get received, a delay of NON_TIMEOUT after every 847 transmission of MAX_PAYLOADS blocks will be observed. The 848 endpoint receiving the body is still likely to receive the entire 849 body. 851 7. Caching Considerations 853 Caching block based information is not straight forward in a proxy. 854 For Q-Block1 and Q-Block2 Options, for simplicity it is expected that 855 the proxy will reassemble the body (using any appropriate recovery 856 options for packet loss) before passing on the body to the 857 appropriate CoAP endpoint. This does not preclude an implementation 858 doing a more complex per payload caching, but how to do this is out 859 of the scope of this document. The onward transmission of the body 860 does not require the use of the Q-Block1 or Q-Block2 Options as these 861 options may not be supported in that link. This means that the proxy 862 must fully support the Q-Block1 and Q-Block2 Options. 864 How the body is cached in the CoAP client (for Q-Block1 865 transmissions) or the CoAP server (for Q-Block2 transmissions) is 866 implementation specific. 868 As the entire body is being cached in the proxy, the Q-Block1 and 869 Q-Block2 Options are removed as part of the block assembly and thus 870 do not reach the cache. 872 For Q-Block2 responses, the ETag Option value is associated with the 873 data (and onward transmitted to the CoAP client), but is not part of 874 the cache key. 876 For requests with Q-Block1 Option, the Request-Tag Option is 877 associated with the build up of the body from successive payloads, 878 but is not part of the cache key. For the onward transmission of the 879 body using CoAP, a new Request-Tag SHOULD be generated and used. 880 Ideally this new Request-Tag should replace the client's request 881 Request-Tag. 883 It is possible that two or more CoAP clients are concurrently 884 updating the same resource through a common proxy to the same CoAP 885 server using Q-Block1 (or Block1) Option. If this is the case, the 886 first client to complete building the body causes that body to start 887 transmitting to the CoAP server with an appropriate Request-Tag 888 value. When the next client completes building the body, any 889 existing partial body transmission to the CoAP server is terminated 890 and the new body representation transmission starts with a new 891 Request-Tag value. Note that it cannot be assumed that the proxy 892 will always receive a complete body from a client. 894 A proxy that supports Q-Block2 Option MUST be prepared to receive a 895 GET or similar request indicating one or more missing blocks. The 896 proxy will serve from its cache the missing blocks that are available 897 in its cache in the same way a server would send all the appropriate 898 Q-Block2s. If the cache key matching body is not available in the 899 cache, the proxy MUST request the entire body from the CoAP server 900 using the information in the cache key. 902 How long a CoAP endpoint (or proxy) keeps the body in its cache is 903 implementation specific (e.g., it may be based on Max-Age). 905 8. HTTP-Mapping Considerations 907 As a reminder, the basic normative requirements on HTTP/CoAP mappings 908 are defined in Section 10 of [RFC7252]. The implementation 909 guidelines for HTTP/CoAP mappings are elaborated in [RFC8075]. 911 The rules defined in Section 5 of [RFC7959] are to be followed. 913 9. Examples of Selective Block Recovery 915 This section provides some sample flows to illustrate the use of 916 Q-Block1 and Q-Block2 Options. Figure 2 lists the conventions that 917 are used in the following subsections. 919 T: Token value 920 O: Observe Option value 921 M: Message ID 922 RT: Request-Tag 923 ET: ETag 924 QB1: Q-Block1 Option values NUM/More/SZX 925 QB2: Q-Block2 Option values NUM/More/SZX 926 \: Trimming long lines 927 [[]]: Comments 928 -->X: Message loss (request) 929 X<--: Message loss (response) 930 ...: Passage of time 932 Figure 2: Notations Used in the Figures 934 9.1. Q-Block1 Option: Non-Confirmable Example 936 Figure 3 depicts an example of a NON PUT request conveying Q-Block1 937 Option. All the blocks are received by the server. 939 CoAP CoAP 940 Client Server 941 | | 942 +--------->| NON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024 943 +--------->| NON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024 944 +--------->| NON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024 945 +--------->| NON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024 946 |<---------+ NON 2.04 M:0xf1 T:0xf3 947 | ... | 949 Figure 3: Example of NON Request with Q-Block1 Option (Without Loss) 950 Consider now a scenario where a new body of data is to be sent by the 951 client, but some blocks are dropped in transmission as illustrated in 952 Figure 4. 954 CoAP CoAP 955 Client Server 956 | | 957 +--------->| NON PUT /path M:0x05 T:0xe0 RT=11 QB1:0/1/1024 958 +--->X | NON PUT /path M:0x06 T:0xe1 RT=11 QB1:1/1/1024 959 +--->X | NON PUT /path M:0x07 T:0xe2 RT=11 QB1:2/1/1024 960 +--------->| NON PUT /path M:0x08 T:0xe3 RT=11 QB1:3/0/1024 961 | ... | 963 Figure 4: Example of NON Request with Q-Block1 Option (With Loss) 965 The server realizes that some blocks are missing and asks for the 966 missing ones in one go (Figure 5). It does so by indicating which 967 blocks have been received in the data portion of the response. The 968 Token just needs to be one of those that have been received for this 969 Request-Tag, so the client can derive the Request-Tag. 971 CoAP CoAP 972 Client Server 973 | ... | 974 |<---------+ NON 4.08 M:0xf2 T:0xe3 [Missing 1,2 [for RT=11]] 975 +--------->| NON PUT /path M:0x09 T:0xe4 RT=11 QB1:1/1/1024 976 +--->X | NON PUT /path M:0x0a T:0xe5 RT=11 QB1:2/1/1024 977 | ... | 978 [[Server realizes a block is still missing and asks for the missing 979 one]] 980 |<---------+ NON 4.08 M:0xf3 T:0xe4 [Missing 2 [for RT=11]] 981 +--------->| NON PUT /path M:0x0b T:0xe6 RT=11 QB1:2/1/1024 982 |<---------+ NON 2.04 M:0xf4 T:0xe6 983 | ... | 985 Figure 5: Example of NON Request with Q-Block1 Option (Blocks 986 Recovery) 988 Under high levels of traffic loss, the client can elect not to retry 989 sending missing blocks of data by "forgetting" all the tracked tokens 990 for this Request-Tag. This decision is implementation specific. 992 9.2. Q-Block2 Option: Non-Confirmable Example 994 Figure 6 illustrates the example of Q-Block2 Option. The client 995 sends a NON GET carrying an Observe and a Q-Block2 Options. The 996 Q-Block2 Option indicates a block size hint (1024 bytes). This 997 request is replied to by the server using four (4) blocks that are 998 transmitted to the client without any loss. Each of these blocks 999 carries a Q-Block2 Option. The same process is repeated when an 1000 Observe is triggered, but no loss is experienced by any of the 1001 notification blocks. 1003 CoAP CoAP 1004 Client Server 1005 | | 1006 +--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/0/1024 1007 |<---------+ NON 2.05 M:0xf1 T:0xf0 O:1234 ET=21 QB2:0/1/1024 1008 |<---------+ NON 2.05 M:0xf2 T:0xf0 O:1234 ET=21 QB2:1/1/1024 1009 |<---------+ NON 2.05 M:0xf3 T:0xf0 O:1234 ET=21 QB2:2/1/1024 1010 |<---------+ NON 2.05 M:0xf4 T:0xf0 O:1234 ET=21 QB2:3/0/1024 1011 | ... | 1012 | [[Observe triggered]] 1013 |<---------+ NON 2.05 M:0xf5 T:0xf0 O:1235 ET=22 QB2:0/1/1024 1014 |<---------+ NON 2.05 M:0xf6 T:0xf0 O:1235 ET=22 QB2:1/1/1024 1015 |<---------+ NON 2.05 M:0xf7 T:0xf0 O:1235 ET=22 QB2:2/1/1024 1016 |<---------+ NON 2.05 M:0xf8 T:0xf0 O:1235 ET=22 QB2:3/0/1024 1017 | ... | 1019 Figure 6: Example of NON Notifications with Q-Block2 Option (Without 1020 Loss) 1022 Figure 7 shows the example of an Observe that is triggered but for 1023 which some notification blocks are lost. The client detects the 1024 missing blocks and requests their retransmission. It does so by 1025 indicating the blocks that were successfully received. 1027 CoAP CoAP 1028 Client Server 1029 | ... | 1030 | [[Observe triggered]] 1031 |<---------+ NON 2.05 M:0xf9 T:0xf0 O:1236 ET=23 QB2:0/1/1024 1032 | X<---+ NON 2.05 M:0xfa T:0xf0 O:1236 ET=23 QB2:1/1/1024 1033 | X<---+ NON 2.05 M:0xfb T:0xf0 O:1236 ET=23 QB2:2/1/1024 1034 |<---------+ NON 2.05 M:0xfc T:0xf0 O:1236 ET=23 QB2:3/0/1024 1035 | ... | 1036 [[Client realizes blocks are missing and asks for the missing 1037 ones in one go]] 1038 +--------->| NON GET /path M:0x02 T:0xf1 QB2:1/0/1024\ 1039 | | QB2:2/0/1024 1040 | X<---+ NON 2.05 M:0xfd T:0xf1 ET=23 QB2:1/1/1024 1041 |<---------+ NON 2.05 M:0xfe T:0xf1 ET=23 QB2:2/1/1024 1042 | ... | 1043 [[Get the final missing block]] 1044 +--------->| NON GET /path M:0x03 T:0xf2 QB2:1/0/1024 1045 |<---------+ NON 2.05 M:0xff T:0xf2 ET=23 QB2:1/1/1024 1046 | ... | 1048 Figure 7: Example of NON Notifications with Q-Block2 Option (Blocks 1049 Recovery) 1051 Under high levels of traffic loss, the client can elect not to retry 1052 getting missing blocks of data. This decision is implementation 1053 specific. 1055 Figure 8 shows the example of an Observe that is triggered but only 1056 the first two notification blocks reaches the client. In order to 1057 retrieve the missing blocks, the client sends a request with a single 1058 Q-Block2 Option with the M bit set. 1060 CoAP CoAP 1061 Client Server 1062 | ... | 1063 | [[Observe triggered]] 1064 |<---------+ NON 2.05 M:0x123 T:0xf0 O:1237 ET=24 QB2:0/1/1024 1065 |<---------+ NON 2.05 M:0x124 T:0xf0 O:1237 ET=24 QB2:1/1/1024 1066 | X<---+ NON 2.05 M:0x125 T:0xf0 O:1237 ET=24 QB2:2/1/1024 1067 | X<---+ NON 2.05 M:0x126 T:0xf0 O:1237 ET=24 QB2:3/0/1024 1068 | ... | 1069 [[Client realizes blocks are missing and asks for the remaining missing 1070 ones in one go by setting the M bit]] 1071 +--------->| NON GET /path M:0x03 T:0xf3 QB2:2/1/1024 1072 |<---------+ NON 2.05 M:0x127 T:0xf3 ET=24 QB2:2/1/1024 1073 |<---------+ NON 2.05 M:0x128 T:0xf3 ET=24 QB2:3/0/1024 1074 | ... | 1076 Figure 8: Example of NON Notifications with Q-Block2 Option (Blocks 1077 Recovery with M bit Set) 1079 10. IANA Considerations 1081 10.1. New CoAP Options 1083 IANA is requested to add the following entries to the "CoAP Option 1084 Numbers" sub-registry [Options]: 1086 +--------+------------------+-----------+ 1087 | Number | Name | Reference | 1088 +========+==================+===========+ 1089 | TBA1 | Q-Block1 | [RFCXXXX] | 1090 | TBA2 | Q-Block2 | [RFCXXXX] | 1091 +--------+------------------+-----------+ 1093 Table 4: CoAP Q-Block1 and Q-Block2 Option Numbers 1095 This document suggests 19 (TBA1) and 51 (TBA2) as a values to be 1096 assigned for the new option numbers. 1098 10.2. New Media Type 1100 This document requests IANA to register the "application/missing- 1101 blocks+cbor-seq" media type in the "Media Types" registry 1102 [IANA-MediaTypes]: 1104 Type name: application 1106 Subtype name: missing-blocks+cbor-seq 1108 Required parameters: N/A 1110 Optional parameters: N/A 1112 Encoding considerations: binary 1114 Security considerations: See the Security Considerations Section of 1115 [This_Document]. 1117 Interoperability considerations: N/A 1119 Published specification: [This_Document] 1121 Applications that use this media type: Data serialization and deserialization. 1123 Fragment identifier considerations: N/A 1125 Additional information: 1127 Deprecated alias names for this type: N/A 1128 Magic number(s): N/A 1129 File extension(s): N/A 1130 Macintosh file type code(s): N/A 1132 Person & email address to contact for further information: IETF, 1133 iesg@ietf.org 1135 Intended usage: COMMON 1137 Restrictions on usage: none 1139 Author: See Authors' Addresses section. 1141 Change controller: IESG 1143 Provisional registration? No 1145 10.3. New Content Format 1147 This document requests IANA to register the CoAP Content-Format ID 1148 for the "application/missing-blocks+cbor-seq" media type in the "CoAP 1149 Content-Formats" registry [Format]: 1151 o Media Type: application/missing-blocks+cbor-seq 1152 o Encoding: - 1153 o Id: TBD3 1154 o Reference: [RFCXXXX] 1156 11. Security Considerations 1158 Security considerations discussed in Section 7 of [RFC7959] should be 1159 taken into account. 1161 Security considerations discussed in Sections 11.3 and 11.4 of 1162 [RFC7252] should be taken into account. 1164 OSCORE provides end-to-end protection of all information that is not 1165 required for proxy operations and requires that a security context is 1166 set up (Section 3.1 of [RFC8613]). It can be trusted that the source 1167 endpoint is legitimate even if NoSec security mode is used. However, 1168 an intermediary node can modify the unprotected outer Q-Block1 and/or 1169 Q-Block2 Options to cause a Q-Block transfer to fail or keep 1170 requesting all the blocks by setting the M bit and, thus, causing 1171 attack amplification. As discussed in Section 12.1 of [RFC8613], 1172 applications need to consider that certain message fields and 1173 messages types are not protected end-to-end and may be spoofed or 1174 manipulated. It is NOT RECOMMENDED that the NoSec security mode is 1175 used if the Q-Block1 and Q-Block2 Options are to be used. 1177 Security considerations related to the use of Request-Tag are 1178 discussed in Section 5 of [I-D.ietf-core-echo-request-tag]. 1180 12. Acknowledgements 1182 Thanks to Achim Kraus, Jim Schaad, Michael Richardson, and Marco 1183 Tiloca for the comments. 1185 Special thanks to Christian Amsuess and Carsten Bormann for their 1186 suggestions and several reviews, which improved this specification 1187 significantly. 1189 Some text from [RFC7959] is reused for readers convenience. 1191 13. References 1193 13.1. Normative References 1195 [I-D.ietf-core-echo-request-tag] 1196 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 1197 Request-Tag, and Token Processing", draft-ietf-core-echo- 1198 request-tag-11 (work in progress), November 2020. 1200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1201 Requirement Levels", BCP 14, RFC 2119, 1202 DOI 10.17487/RFC2119, March 1997, 1203 . 1205 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1206 Application Protocol (CoAP)", RFC 7252, 1207 DOI 10.17487/RFC7252, June 2014, 1208 . 1210 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1211 Application Protocol (CoAP)", RFC 7641, 1212 DOI 10.17487/RFC7641, September 2015, 1213 . 1215 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1216 the Constrained Application Protocol (CoAP)", RFC 7959, 1217 DOI 10.17487/RFC7959, August 2016, 1218 . 1220 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 1221 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 1222 the Constrained Application Protocol (CoAP)", RFC 8075, 1223 DOI 10.17487/RFC8075, February 2017, 1224 . 1226 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 1227 FETCH Methods for the Constrained Application Protocol 1228 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 1229 . 1231 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1232 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1233 May 2017, . 1235 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1236 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 1237 Application Protocol) over TCP, TLS, and WebSockets", 1238 RFC 8323, DOI 10.17487/RFC8323, February 2018, 1239 . 1241 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1242 "Object Security for Constrained RESTful Environments 1243 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1244 . 1246 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 1247 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 1248 . 1250 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1251 Representation (CBOR)", STD 94, RFC 8949, 1252 DOI 10.17487/RFC8949, December 2020, 1253 . 1255 13.2. Informative References 1257 [Format] , . 1260 [I-D.ietf-dots-telemetry] 1261 Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c., 1262 and J. Shallow, "Distributed Denial-of-Service Open Threat 1263 Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15 1264 (work in progress), December 2020. 1266 [IANA-MediaTypes] 1267 IANA, "Media Types", 1268 . 1270 [Options] , . 1273 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 1274 "Increasing TCP's Initial Window", RFC 6928, 1275 DOI 10.17487/RFC6928, April 2013, 1276 . 1278 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1279 Definition Language (CDDL): A Notational Convention to 1280 Express Concise Binary Object Representation (CBOR) and 1281 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1282 June 2019, . 1284 [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., 1285 Mortensen, A., and N. Teague, "Distributed Denial-of- 1286 Service Open Threat Signaling (DOTS) Signal Channel 1287 Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, 1288 . 1290 Appendix A. Examples with Confirmable Messages 1292 These examples assume NSTART has been increased to at least 4. 1294 The notations provided in Figure 2 are used in the following 1295 subsections. 1297 A.1. Q-Block1 Option 1299 Let's now consider the use Q-Block1 Option with a CON request as 1300 shown in Figure 9. All the blocks are acknowledged (ACK). 1302 CoAP CoAP 1303 Client Server 1304 | | 1305 +--------->| CON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024 1306 +--------->| CON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024 1307 +--------->| CON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024 1308 +--------->| CON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024 1309 |<---------+ ACK 0.00 M:0x01 1310 |<---------+ ACK 0.00 M:0x02 1311 |<---------+ ACK 0.00 M:0x03 1312 |<---------+ ACK 2.04 M:0x04 1314 Figure 9: Example of CON Request with Q-Block1 Option (Without Loss) 1316 Now, suppose that a new body of data is to sent but with some blocks 1317 dropped in transmission as illustrated in Figure 10. The client will 1318 retry sending blocks for which no ACK was received. 1320 CoAP CoAP 1321 Client Server 1322 | | 1323 +--------->| CON PUT /path M:0x05 T:0xf4 RT=11 QB1:0/1/1024 1324 +--->X | CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 1325 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 1326 +--------->| CON PUT /path M:0x08 T:0xf7 RT=11 QB1:3/1/1024 1327 |<---------+ ACK 0.00 M:0x05 1328 |<---------+ ACK 0.00 M:0x08 1329 | ... | 1330 [[The client retries sending packets not acknowledged]] 1331 +--------->| CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 1332 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 1333 |<---------+ ACK 0.00 M:0x06 1334 | ... | 1335 [[The client retransmits messages not acknowledged 1336 (exponential backoff)]] 1337 +--->? | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 1338 | ... | 1339 [[Either body transmission failure (acknowledge retry timeout) 1340 or successfully transmitted.]] 1342 Figure 10: Example of CON Request with Q-Block1 Option (Blocks 1343 Recovery) 1345 It is up to the implementation as to whether the application process 1346 stops trying to send this particular body of data on reaching 1347 MAX_RETRANSMIT for any payload, or separately tries to initiate the 1348 new transmission of the payloads that have not been acknowledged 1349 under these adverse traffic conditions. 1351 If there is likely to be the possibility of network transient losses, 1352 then the use of NON should be considered. 1354 A.2. Q-Block2 Option 1356 An example of the use of Q-Block2 Option with Confirmable messages is 1357 shown in Figure 11. 1359 Client Server 1360 | | 1361 +--------->| CON GET /path M:0x01 T:0xf0 O:0 QB2:0/0/1024 1362 |<---------+ ACK 2.05 M:0x01 T:0xf0 O:1234 ET=21 QB2:0/1/1024 1363 |<---------+ ACK 2.05 M:0xe1 T:0xf0 O:1234 ET=21 QB2:1/1/1024 1364 |<---------+ ACK 2.05 M:0xe2 T:0xf0 O:1234 ET=21 QB2:2/1/1024 1365 |<---------+ ACK 2.05 M:0xe3 T:0xf0 O:1234 ET=21 QB2:3/0/1024 1366 | ... | 1367 | [[Observe triggered]] 1368 |<---------+ CON 2.05 M:0xe4 T:0xf0 O:1235 ET=22 QB2:0/1/1024 1369 |<---------+ CON 2.05 M:0xe5 T:0xf0 O:1235 ET=22 QB2:1/1/1024 1370 |<---------+ CON 2.05 M:0xe6 T:0xf0 O:1235 ET=22 QB2:2/1/1024 1371 |<---------+ CON 2.05 M:0xe7 T:0xf0 O:1235 ET=22 QB2:3/0/1024 1372 |--------->+ ACK 0.00 M:0xe4 1373 |--------->+ ACK 0.00 M:0xe5 1374 |--------->+ ACK 0.00 M:0xe6 1375 |--------->+ ACK 0.00 M:0xe7 1376 | ... | 1377 | [[Observe triggered]] 1378 |<---------+ CON 2.05 M:0xe8 T:0xf0 O:1236 ET=23 QB2:0/1/1024 1379 | X<---+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 1380 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 1381 |<---------+ CON 2.05 M:0xeb T:0xf0 O:1236 ET=23 QB2:3/0/1024 1382 |--------->+ ACK 0.00 M:0xe8 1383 |--------->+ ACK 0.00 M:0xeb 1384 | ... | 1385 | [[Server retransmits messages not acknowledged]] 1386 |<---------+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 1387 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 1388 |--------->+ ACK 0.00 M:0xe9 1389 | ... | 1390 | [[Server retransmits messages not acknowledged 1391 | (exponential backoff)]] 1392 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 1393 | ... | 1394 [[Either body transmission failure (acknowledge retry timeout) 1395 or successfully transmitted.]] 1397 Figure 11: Example of CON Notifications with Q-Block2 Option 1399 It is up to the implementation as to whether the application process 1400 stops trying to send this particular body of data on reaching 1401 MAX_RETRANSMIT for any payload, or separately tries to initiate the 1402 new transmission of the payloads that have not been acknowledged 1403 under these adverse traffic conditions. 1405 If there is likely to be the possibility of network transient losses, 1406 then the use of NON should be considered. 1408 Authors' Addresses 1410 Mohamed Boucadair 1411 Orange 1412 Rennes 35000 1413 France 1415 Email: mohamed.boucadair@orange.com 1417 Jon Shallow 1418 United Kingdom 1420 Email: supjps-ietf@jpshallow.com