--- 1/draft-ietf-core-new-block-05.txt 2021-01-19 08:13:16.794212442 -0800 +++ 2/draft-ietf-core-new-block-06.txt 2021-01-19 08:13:16.938216096 -0800 @@ -1,19 +1,19 @@ CORE M. Boucadair Internet-Draft Orange Intended status: Standards Track J. Shallow -Expires: July 17, 2021 January 13, 2021 +Expires: July 23, 2021 January 19, 2021 Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Faster Transmission - draft-ietf-core-new-block-05 + draft-ietf-core-new-block-06 Abstract This document specifies alternative Constrained Application Protocol (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. These options are similar to the CoAP Block1 and Block2 Options, not a replacement for them, but do enable faster transmission rates for large amounts of data with less packet interchanges as well as supporting faster recovery should any of the blocks get lost in @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 17, 2021. + This Internet-Draft will expire on July 23, 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -53,61 +53,64 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Alternative CoAP Block-Wise Transfer Options . . . . . . 3 1.2. CoAP Response Code (4.08) Usage . . . . . . . . . . . . . 5 1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. The Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 6 3.1. Properties of Q-Block1 and Q-Block2 Options . . . . . . . 6 - 3.2. Structure of Q-Block1 and Q-Block2 Options . . . . . . . 8 + 3.2. Structure of Q-Block1 and Q-Block2 Options . . . . . . . 9 3.3. Using the Q-Block1 Option . . . . . . . . . . . . . . . . 9 - 3.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 12 - 3.5. Using Observe and Q-Block1 Options . . . . . . . . . . . 14 - 3.6. Using Observe and Q-Block2 Options . . . . . . . . . . . 15 - 3.7. Using Size1 and Size2 Options . . . . . . . . . . . . . . 15 - 3.8. Using Q-Block1 and Q-Block2 Options Together . . . . . . 15 - 4. The Use of 4.08 (Request Entity Incomplete) Response Code . . 15 + 3.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 13 + 3.5. Using Observe Option . . . . . . . . . . . . . . . . . . 15 + 3.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 15 + 3.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 15 + 3.8. Using Q-Block2 Option With Multicast . . . . . . . . . . 16 + 4. The Use of 4.08 (Request Entity Incomplete) Response Code . . 16 5. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 17 - 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 17 - 6.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 17 + 6. Congestion Control for Unreliable Transports . . . . . . . . 18 + 6.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 18 6.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 18 - 7. Caching Considerations . . . . . . . . . . . . . . . . . . . 21 - 8. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 22 - 9. Examples with Non-confirmable Messages . . . . . . . . . . . 22 + 7. Caching Considerations . . . . . . . . . . . . . . . . . . . 22 + 8. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 23 + 9. Examples with Non-confirmable Messages . . . . . . . . . . . 23 9.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 23 9.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 23 - 9.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 23 + 9.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 24 9.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . . 24 - 9.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 25 - 9.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 25 - 9.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 26 - 9.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . . 27 - 9.2.4. Handling Recovery using M-bit Set . . . . . . . . . . 28 - 9.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 29 - 9.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 29 - 9.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 30 - 9.3.3. Handling Recovery . . . . . . . . . . . . . . . . . . 31 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 - 10.1. New CoAP Options . . . . . . . . . . . . . . . . . . . . 33 - 10.2. New Media Type . . . . . . . . . . . . . . . . . . . . . 34 - 10.3. New Content Format . . . . . . . . . . . . . . . . . . . 35 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 36 - 13.2. Informative References . . . . . . . . . . . . . . . . . 38 - Appendix A. Examples with Confirmable Messages . . . . . . . . . 39 - A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 39 - A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 40 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 + 9.1.4. Handling Recovery with Failure . . . . . . . . . . . 26 + 9.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 26 + 9.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 27 + 9.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 27 + 9.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . . 28 + 9.2.4. Handling Recovery using M-bit Set . . . . . . . . . . 29 + 9.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 30 + 9.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 30 + 9.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 31 + 9.3.3. Handling Recovery . . . . . . . . . . . . . . . . . . 32 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 + 10.1. New CoAP Options . . . . . . . . . . . . . . . . . . . . 34 + 10.2. New Media Type . . . . . . . . . . . . . . . . . . . . . 35 + 10.3. New Content Format . . . . . . . . . . . . . . . . . . . 36 + 10.4. New CoAP Signaling Option Number . . . . . . . . . . . . 37 + + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 38 + 13.2. Informative References . . . . . . . . . . . . . . . . . 39 + Appendix A. Examples with Confirmable Messages . . . . . . . . . 40 + A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 40 + A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 42 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 1. Introduction The Constrained Application Protocol (CoAP) [RFC7252], although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control. [RFC7959] introduced the CoAP Block1 and Block2 Options to handle data records that cannot fit in a single IP packet, so not having to rely on IP fragmentation and was further updated by [RFC8323] for use over TCP, @@ -158,20 +161,22 @@ o Additional congestion control measures need to be put in place for NON (Section 6.2). o To reduce the transmission times for CON transmission of large bodies, NSTART needs to be increased from 1, but this affects congestion control where other parameters need to be tuned (Section 4.7 of [RFC7252]). Such tuning is out of scope of this document. + o There is no multicast support. + Using NON messages, the faster transmissions occur as all the blocks can be transmitted serially (as are IP fragmented packets) without having to wait for a response or next request from the remote CoAP peer. Recovery of missing blocks is faster in that multiple missing blocks can be requested in a single CoAP packet. Even if there is asymmetrical packet loss, a body can still be sent and received by the peer whether the body comprises of a single or multiple payloads assuming no recovery is required. Note that similar performance benefits can be applied to Confirmable @@ -196,22 +201,22 @@ transmissions can fall back to using Block1 and Block2 Options, respectively. The deviations from Block1 and Block2 Options are specified in Section 3. Pointers to appropriate [RFC7959] sections are provided. The specification refers to the base CoAP methods defined in Section 5.8 of [RFC7252] and the new CoAP methods, FETCH, PATCH, and iPATCH introduced in [RFC8132]. - Q-Block1 and Q-Block2 Options are designed to work with Non- - confirmable requests and responses, in particular. + Q-Block1 and Q-Block2 Options are designed to work in particular with + Non-confirmable requests and responses. 1.2. CoAP Response Code (4.08) Usage This document adds a media type for the 4.08 (Request Entity Incomplete) response defining an additional message format for reporting on payloads using the Q-Block1 Option that are not received by the server. See Section 4 for more details. @@ -294,45 +299,58 @@ The Content-Format Option applies to the body, not to the payload (i.e., it must be the same for all payloads of the same body). Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH, PATCH, and iPATCH requests and their responses. Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and iPATCH requests and their payload-bearing responses (2.01, 2.02, 2.03, 2.04, and 2.05) (Section 5.5 of [RFC7252]). - However, with methods needing both Q-Block1 for the request and - Q-Block2 for the response, and there is need for recovery following - payload loss, the numbers of packets needed to initiate and complete - the recovery can get very large as a function of the severity of the - experienced loss. - A CoAP endpoint (or proxy) MUST support either both or neither of the Q-Block1 and Q-Block2 Options. If Q-Block1 Option is present in a request or Q-Block2 Option in a response (i.e., in that message to the payload of which it pertains), it indicates a block-wise transfer and describes how this specific block-wise payload forms part of the entire body being transferred. If it is present in the opposite direction, it provides additional control on how that payload will be formed or was processed. To indicate support for Q-Block2 responses, the CoAP client MUST include the Q-Block2 Option in a GET or similar request, the Q-Block2 Option in a PUT or similar request, or the Q-Block1 Option in a PUT or similar so that the server knows that the client supports this Q-Block2 functionality should it need to send back a body that spans multiple payloads. Otherwise, the server would use the Block2 Option (if supported) to send back a message body that is too large to fit into a single IP packet [RFC7959]. + Alternatively, with CoAP over reliable transports, Capabilities and + Settings Messages (CSMs) can be used to indicate support of Q-Block + Options by means of the Q-Block-Wise-Transfer Capability Option + (Table 2). The behavior of CoAP peers is similar to the one + specified in Section 5.3.2 of [RFC8323], except that it indicates + support of Q-Block Options. + + +----+---+---+---------+---------------+--------+--------+--------+ + | # | C | R | Applies | Name | Format | Length | Base | + | | | | to | | | | Value | + +====+===+===+=========+===============+========+========+========+ + |TBA4| | | CSM | Q-Block-Wise- | empty | 0 | (none) | + | | | | | Transfer | | | | + +----+---+---+---------+---------------+--------+--------+--------+ + + C=Critical, R=Repeatable + + Table 2: The Q-Block-Wise-Transfer Capability Option + Implementation of the Q-Block1 and Q-Block2 Options is intended to be optional. However, when it is present in a CoAP message, it MUST be processed (or the message rejected). Therefore, Q-Block1 and Q-Block2 Options are identified as Critical options. With CoAP over UDP, the way a request message is rejected for critical options depends on the message type. A Confirmable message with an unrecognized critical option is rejected with a 4.02 (Bad Option) response (Section 5.4.1 of [RFC7252]). A Non-confirmable message with an unrecognized critical option is either rejected with @@ -343,38 +361,41 @@ The Q-Block1 and Q-Block2 Options are unsafe to forward. That is, a CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option MUST reject the request or response that uses either option. The Q-Block2 Option is repeatable when requesting retransmission of missing blocks, but not otherwise. Except that case, any request carrying multiple Q-Block1 (or Q-Block2) Options MUST be handled following the procedure specified in Section 5.4.5 of [RFC7252]. + Note that if Q-Block1 (or Q-Block2) Option is included in a packet, + Block1 (or Block2) Option MUST NOT be included. + The Q-Block1 and Q-Block2 Options, like the Block1 and Block2 Options, are both a class E and a class U in terms of OSCORE - processing (Table 2). The Q-Block1 (or Q-Block2) Option MAY be an + processing (Table 3). The Q-Block1 (or Q-Block2) Option MAY be an Inner or Outer option (Section 4.1 of [RFC8613]). The Inner and Outer values are therefore independent of each other. The Inner option is encrypted and integrity protected between clients and servers, and provides message body identification in case of end-to- end fragmentation of requests. The Outer option is visible to proxies and labels message bodies in case of hop-by-hop fragmentation of requests. +--------+-----------------+---+---+ | Number | Name | E | U | +========+=================+===+===+ | TBA1 | Q-Block1 | x | x | | TBA2 | Q-Block2 | x | x | +--------+-----------------+---+---+ - Table 2: OSCORE Protection of Q-Block1 and Q-Block2 Options + Table 3: OSCORE Protection of Q-Block1 and Q-Block2 Options 3.2. Structure of Q-Block1 and Q-Block2 Options The structure of Q-Block1 and Q-Block2 Options follows the structure defined in Section 2.2 of [RFC7959]. There is no default value for the Q-Block1 and Q-Block2 Options. Absence of one of these options is equivalent to an option value of 0 with respect to the value of block number (NUM) and more bit (M) that could be given in the option, i.e., it indicates that the current @@ -403,27 +424,31 @@ that it is unique for every different body of transmitted data. Implementation Note: It is suggested that the client treats the Request-Tag as an unsigned integer of 8 bytes in length. An implementation may want to consider limiting this to 4 bytes to reduce packet overhead size. The initial Request-Tag value should be randomly generated and then subsequently incremented by the client whenever a new body of data is being transmitted between peers. - Section 3.7 discusses the use of Size1 Option. + Section 3.6 discusses the use of Size1 Option. For Confirmable transmission, the server continues to acknowledge each packet, but a response is not required (whether separate or - piggybacked) until successful receipt of the body or, if some of the - payloads are sent as Non-confirmable and have not arrived, a - retransmit missing payloads response is needed. + piggybacked) until successful receipt of the body by the server. For + Non-confirmable transmission, no response is required until the + successful receipt of the body by the server or some of the payloads + have not arrived after a timeout and a retransmit missing payloads + response is needed. For reliable transports (e.g., [RFC8323]), a + response is not required until successful receipt of the body by the + server. Each individual payload of the body is treated as a new request (Section 5). The client MUST send the payloads with the block numbers increasing, starting from zero, until the body is complete (subject to any congestion control (Section 6)). Any missing payloads requested by the server must in addition be separately transmitted with increasing block numbers. @@ -448,21 +473,21 @@ This Response Code indicates successful receipt of the entire body and the resource was updated. The token used SHOULD be from the last received payload. The client should then release all of the tokens used for this body. 2.05 (Content) This Response Code indicates successful receipt of the entire FETCH request body (Section 2 of [RFC8132]) and the appropriate - representation of the resource has been returned. The token used + representation of the resource is being returned. The token used in the response MUST be the one in the FETCH request that has the Q-Block1 with the M bit unset. If the FETCH request includes the Observe Option, then the server MUST use the same token for returning any Observe triggered responses. The client should then release all of the tokens used for this body unless a resource is being observed. 2.31 (Continue) This Response Code can be used to indicate that all of the blocks @@ -479,52 +504,52 @@ It SHOULD NOT be generated for CON. 4.00 (Bad Request) This Response Code MUST be returned if the request does not include both a Request-Tag Option and a Size1 Option but does include a Q-Block1 option. 4.02 (Bad Option) - Either this Response Code or a reset message MUST be returned if - the server does not support the Q-Block1 Option. + Either this Response Code (in case of Confirmable request) or a + reset message (in case of Non-confirmable request) MUST be + returned if the server does not support the Q-Block1 Option. 4.08 (Request Entity Incomplete) This Response Code returned without Content-Type "application/ missing-blocks+cbor-seq" (Section 10.3) is handled as in Section 2.9.2 [RFC7959]. This Response Code returned with Content-Type "application/ missing-blocks+cbor-seq" indicates that some of the payloads are missing and need to be resent. The client then retransmits the missing payloads using the same Request-Tag, Size1 and Q-Block1 to - specify the block number, SZX, and M bit as appropriate. + specify the block NUM, SZX, and M bit as appropriate. - The Request-Tag value to use is determined from the token in the - 4.08 (Request Entity Incomplete) response and then finding the - matching client request which contains the Request-Tag that is - being used for this Q-Block1 body. + The Request-Tag value to use is determined by taking the token in + the 4.08 (Request Entity Incomplete) response, locating the + matching client request, and then using its Request-Tag. The token used in the response SHOULD be from the last received payload. See Section 4 for further information. 4.13 (Request Entity Too Large) This Response Code can be returned under similar conditions to those discussed in Section 2.9.3 of [RFC7959]. This Response Code can be returned if there is insufficient space to create a response PDU with a block size of 16 bytes (SZX = 0) to send back all the response options as appropriate. In this - case, the Size1 Option is not included. + case, the Size1 Option is not included in the response. If the server has not received all the payloads of a body, but one or more NON payloads have been received, it SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 6.2) before sending a 4.08 (Request Entity Incomplete) response. Further considerations related to the transmission timings of 4.08 (Request Entity Incomplete) and 2.31 (Continue) Response Codes are discussed in Section 6.2. If a server receives payloads with different Request-Tags for the same resource, it should continue to process all the bodies as it has @@ -545,27 +570,28 @@ up to NON_PARTIAL_TIMEOUT (Section 6.2). 3.4. Using the Q-Block2 Option In a request for any block number, the M bit unset indicates the request is just for that block. If the M bit is set, this has different meanings based on the NUM value: NUM is zero: This is a request for the entire body. - 'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero: - - This is used to confirm that the current set of MAX_PAYLOADS - payloads (the latest one having block number NUM-1) has been - successfully received and that, upon receipt of this request, the - server can continue to send the next set of payloads (the first - one having block number NUM). This is the 'Continue' Q-Block-2. + 'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero: This is + used to confirm that the current set of MAX_PAYLOADS payloads (the + latest one having block number NUM-1) has been successfully + received and that, upon receipt of this request, the server can + continue to send the next set of payloads (the first one having + block number NUM). This is the 'Continue' Q-Block-2 and + conceptually has the same usage (i.e., continue sending the next + set of data) as the use of 2.31 (Continue) for Q-Block1. Any other value of NUM: This is a request for that block and for all of the remaining blocks in the current MAX_PAYLOADS set. If the request includes multiple Q-Block2 Options and these options overlap (e.g., combination of M being set (this and later blocks) and being unset (this individual block)) resulting in an individual block being requested multiple times, the server MUST only send back one instance of that block. This behavior is meant to prevent amplification attacks. @@ -579,21 +605,21 @@ server SHOULD ensure that it is unique for every different body of transmitted data. Implementation Note: It is suggested that the server treats the ETag as an unsigned integer of 8 bytes in length. An implementation may want to consider limiting this to 4 bytes to reduce packet overhead size. The initial ETag value should be randomly generated and then subsequently incremented by the server whenever a new body of data is being transmitted between peers. - Section 3.7 discusses the use of Size2 Option. + Section 3.6 discusses the use of Size2 Option. The client may elect to request any detected missing blocks or just ignore the partial body. This decision is implementation specific. The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 6.2) after the last received payload for NON payloads before issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or more Q-Block2 Options that define the missing blocks with the M bit unset. It is permissible to set the M bit to request this and missing blocks from this MAX_PAYLOADS set. Further considerations @@ -608,26 +634,31 @@ For Confirmable responses, the client continues to acknowledge each packet. The server will detect failure to send a packet, but the client can issue, after a MAX_TRANSMIT_SPAN delay, a separate GET, POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as needed. If the client receives a duplicate block with the same ETag, it SHOULD silently ignore the packet. A client SHOULD only maintain a partial body (missing payloads) for up to NON_PARTIAL_TIMEOUT (Section 6.2) or as defined by the Max-Age - Option (or its default), whichever is the less. + Option (or its default of 60 seconds (Section 5.6.1 of [RFC7252])), + whichever is the less. The ETag Option should not be used in the request for missing blocks as the server could respond with a 2.03 (Valid Response) with no payload. It can be used in the request if the client wants to check - the freshness of the currently cached body response. + the freshness of the locally cached body response. + + It is RECOMMENDED that the server maintains a cached copy of the body + when using the Q-Block2 Option to facilitate retransmission of any + missing payloads. If the server detects part way through a body transfer that the resource data has changed and the server is not maintaining a cached copy of the old data, then the body response SHOULD be restarted with a different ETag Option value. Any subsequent missing block requests MUST be responded to using the latest ETag Option value. If the server responds during a body update with a different ETag Option value (as the resource representation has changed), then the client should treat the partial body with the old ETag as no longer @@ -637,72 +668,62 @@ Observe) with a new ETag to the same client as an additional response, the client should remove any partially received body held for a previous ETag for that resource as it is unlikely the missing blocks can be retrieved. If there is insufficient space to create a response PDU with a block size of 16 bytes (SZX = 0) to send back all the response options as appropriate, a 4.13 (Request Entity Too Large) is returned without the Size1 Option. -3.5. Using Observe and Q-Block1 Options - - As the blocks of the body are sent without waiting for - acknowledgement of the individual blocks, the observe value [RFC7641] - MUST be the same for all the blocks of the same body. - - If the server reports any missing payload, the client re-sends the - missing payload(s). Each re-sent payload is treated as a new request - and the Observe Option MUST be included in the request. - - If the response (or associated response) uses Q-Block2 Option, and - one of the response payloads is missing, the request for the missing - payload(s) is treated as a new request. The request MUST comprise of - all of the request payloads and the Observe Option MUST NOT be - included in either the request or response. - -3.6. Using Observe and Q-Block2 Options +3.5. Using Observe Option - As the blocks of the body are sent without waiting for - acknowledgement of the individual blocks, the Observe value [RFC7641] - MUST be the same for all the blocks of the same body. + For a request that uses Q-Block1, the Observe value [RFC7641] MUST be + the same for all the payloads of the same body. This includes any + missing payloads that are retransmitted. - If the client requests missing blocks, this is treated as a new - Request and the Observe Option MUST NOT be included in either the - request or response. If the ETag value in the response changes, then - the previously received partial body should be considered as not - fresh and the whole body re-requested. + For a response that uses Q-Block2, the Observe value MUST be the same + for all the payloads of the same body. This includes payloads + transmitted following receipt of the 'Continue' Q-Block2 Option + (Section 3.4) by the server. If a missing payload is requested, then + both the request and response MUST NOT include the Observe Option. -3.7. Using Size1 and Size2 Options +3.6. Using Size1 and Size2 Options Section 4 of [RFC7959] defines two CoAP options: Size1 for indicating the size of the representation transferred in requests and Size2 for indicating the size of the representation transferred in responses. The Size1 or Size2 option values MUST exactly represent the size of the data on the body so that any missing data can easily be determined. The Size1 Option MUST be used with the Q-Block1 Option when used in a request. The Size2 Option MUST be used with the Q-Block2 Option when used in a response. If Size1 or Size2 Options are used, they MUST be used in all payloads of the body and MUST preserve the same value in each of those payloads. -3.8. Using Q-Block1 and Q-Block2 Options Together +3.7. Using Q-Block1 and Q-Block2 Options Together The behavior is similar to the one defined in Section 3.3 of [RFC7959] with Q-Block1 substituted for Block1 and Q-Block2 for Block2. +3.8. Using Q-Block2 Option With Multicast + + Servers MUST ignore multicast requests that contain the Q-Block2 + Option. As a reminder, Block2 Option can be used as stated in + Section 2.8 of [RFC7959]. + 4. The Use of 4.08 (Request Entity Incomplete) Response Code 4.08 (Request Entity Incomplete) Response Code has a new Content-Type "application/missing-blocks+cbor-seq" used to indicate that the server has not received all of the blocks of the request body that it needs to proceed. Likely causes are the client has not sent all blocks, some blocks were dropped during transmission, or the client has sent them sufficiently long ago that the server has already discarded them. @@ -727,21 +748,21 @@ ; A unique block number not received: missing-block-number = uint Figure 1: Structure of the Missing Blocks Payload The token to use for the response SHOULD be the token that was used in the last block number received so far with the same Request-Tag value. Note that the use of any received token with the same Request-Tag would work, but providing the one used in the last received block number will aid any troubleshooting. The client will - use the token to determine what is the previously sent request to + use the token to determine what was the previously sent request to obtain the Request-Tag value to be used. If the size of the 4.08 (Request Entity Incomplete) response packet is larger than that defined by Section 4.6 [RFC7252], then the number of missing blocks MUST be limited so that the response can fit into a single packet. If this is the case, then the server can send subsequent 4.08 (Request Entity Incomplete) responses containing the missing other blocks on receipt of a new request providing a missing payload with the same Request-Tag. @@ -767,76 +788,90 @@ 5. The Use of Tokens Each new request MUST use a unique Token (Section 4 of [I-D.ietf-core-echo-request-tag]). Additional responses may use the same Token. Implementation Note: To minimize on the number of tokens that have to be tracked by clients, it is recommended that the bottom 32 bits is kept the same for the same body and the upper 32 bits - contains the individual payload number. + contains the individual payload number. This allows the client to + be alleviated from keeping all the per-request-state, e.g., in + Section 3 of [RFC8974]. Servers continue to treat the token as a unique opaque entity. If an individual payload has to be resent (e.g., requested upon packet loss), then the retransmitted packet is treated as a new request (i.e., the bottom 32 bits must change). -6. Congestion Control +6. Congestion Control for Unreliable Transports - The transmission of the payloads of a body either SHOULD all be - Confirmable or all be Non-confirmable. This is meant to simplify the - congestion control procedure. + The transmission of the payloads of a body over an unreliable + transport SHOULD either all be Confirmable or all be Non-confirmable. + This is meant to simplify the congestion control procedure. + + As a reminder, there is no need for CoAP-specific congestion control + for reliable transports [RFC8323]. 6.1. Confirmable (CON) Congestion control for CON requests and responses is specified in Section 4.7 of [RFC7252]. For faster transmission rates, NSTART will need to be increased from 1. However, the other CON congestion control parameters will need to be tuned to cover this change. This tuning is out of scope of this document as it is expected that all requests and responses using Q-Block1 and Q-Block2 will be Non- confirmable. It is implementation specific as to whether there should be any further requests for missing data as there will have been significant transmission failure as individual payloads will have failed after MAX_TRANSMIT_SPAN. 6.2. Non-confirmable (NON) This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT, NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and - NON_PARTIAL_TIMEOUT primarily for use with NON. + NON_PARTIAL_TIMEOUT primarily for use with NON (Table 4). MAX_PAYLOADS should be configurable with a default value of 10. Both CoAP endpoints SHOULD have the same value (otherwise there will be transmission delays in one direction) and the value MAY be negotiated between the endpoints to a common value by using a higher level protocol (out of scope of this document). This is the maximum number of payloads that can be transmitted at any one time. Note: The default value of 10 is chosen for reasons similar to those discussed in Section 5 of [RFC6928]. NON_TIMEOUT is the maximum period of delay between sending sets of MAX_PAYLOADS payloads for the same body. By default, NON_TIMEOUT has the same value as ACK_TIMEOUT (Section 4.8 of [RFC7252]). - NON_RECEIVE_TIMEOUT is the maximum time to wait for a missing payload - before requesting retransmission. NON_RECEIVE_TIMEOUT has a value of - twice NON_TIMEOUT. + NON_RECEIVE_TIMEOUT is the initial maximum time to wait for a missing + payload before requesting retransmission for the first time. Every + time the missing payload is re-requested, the time to wait value + doubles. The time to wait is calculated as: + + Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count - 1)) + + NON_RECEIVE_TIMEOUT has a default value of twice NON_TIMEOUT. + NON_RECEIVE_TIMEOUT MUST always be greater than NON_TIMEOUT by at + least one second so that the sender of the payloads has the + opportunity to start sending the next set of payloads before the + receiver times out. NON_MAX_RETRANSMIT is the maximum number of times a request for the retransmission of missing payloads can occur without a response from - the remote peer. After this occurs, the peer SHOULD consider the - body stale and remove all references to it. By default, + the remote peer. After this occurs, the local endpoint SHOULD + consider the body stale and remove all references to it. By default, NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT (Section 4.8 of [RFC7252]). NON_PROBING_WAIT is used to limit the potential wait needed calculated when using PROBING_WAIT. NON_PROBING_WAIT has the same value as computed for EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. NON_PARTIAL_TIMEOUT has the same value as computed for EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). @@ -845,21 +880,21 @@ | Parameter Name | Default Value | +=====================+===============| | MAX_PAYLOADS | 10 | | NON_MAX_RETRANSMIT | 4 | | NON_TIMEOUT | 2 s | | NON_RECEIVE_TIMEOUT | 4 s | | NON_PROBING_WAIT | 247 s | | NON_PARTIAL_TIMEOUT | 247 s | +---------------------+---------------+ - Table 3: Congestion Control Parameters + Table 4: Congestion Control Parameters PROBING_RATE parameter in CoAP indicates the average data rate that must not be exceeded by a CoAP endpoint in sending to a peer endpoint that does not respond. The single body of blocks will be subjected to PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets. If the wait time between sending bodies that are not being responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the gap time is limited to NON_PROBING_WAIT. Note: For the particular DOTS application, PROBING_RATE and other @@ -901,59 +936,55 @@ Response Code for the latest payload sent, then the client can continue to send the next set of payloads without any delay. If the server responds with a 4.08 (Request Entity Incomplete) Response Code, then the missing payloads SHOULD be retransmitted before going into another NON_TIMEOUT delay prior to sending the next set of payloads. For the server receiving NON Q-Block1 requests, it SHOULD send back a 2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS payloads to prevent the client unnecessarily delaying. Otherwise the - server SHOULD delay for NON_RECEIVE_TIMEOUT, before sending the 4.08 - (Request Entity Incomplete) Response Code. The NON_RECEIVE_TIMEOUT - delay may be reduced for the first time that this 4.08 (Request - Entity Incomplete) is sent if either the last of the MAX_PAYLOADS - payloads or the final payload with the M bit unset arrives, but - SHOULD NOT be reduced to zero as packets may arrive in the wrong - order. + server SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled + based on the repeat request count for a payload), before sending the + 4.08 (Request Entity Incomplete) Response Code for the missing + payload(s). If the repeat request count for a missing payload + exceeds NON_MAX_RETRANSMIT, the server SHOULD discard the partial + body and stop requesting the missing payloads. - It is possible that the client may start transmitting the next set of + It is likely that the client will start transmitting the next set of MAX_PAYLOADS payloads before the server times out on waiting for the last of the previous MAX_PAYLOADS payloads. On receipt of the first received payload from the new set of MAX_PAYLOADS payloads, the server SHOULD send a 4.08 (Request Entity Incomplete) Response Code indicating any missing payloads from any previous MAX_PAYLOADS payloads. Upon receipt of the 4.08 (Request Entity Incomplete) Response Code, the client SHOULD send the missing payloads before continuing to send the remainder of the MAX_PAYLOADS payloads and then go into another NON_TIMEOUT delay prior to sending the next set of payloads. For the client receiving NON Q-Block2 responses, it SHOULD send a - request for the next set of payloads on receipt of all of the - MAX_PAYLOADS payloads to prevent the server unnecessarily delaying. - Otherwise the client SHOULD delay for NON_RECEIVE_TIMEOUT, before - sending the request for the missing payloads. The - NON_RECEIVE_TIMEOUT delay may be reduced for the first time that this - request is sent if either the last of the MAX_PAYLOADS payloads or - the final payload with the M bit unset arrives, but SHOULD NOT be - reduced to zero as packets may arrive in the wrong order. + 'Continue' Q-Block2 request (Section 3.4) for the next set of + payloads on receipt of all of the MAX_PAYLOADS payloads to prevent + the server unnecessarily delaying. Otherwise the client SHOULD delay + for NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat + request count for a payload), before sending the request for the + missing payload(s). If the repeat request count for a missing + payload exceeds NON_MAX_RETRANSMIT, the client SHOULD discard the + partial body and stop requesting the missing payloads. - The request that the client sends to acknowledge the receipt of all - the current set of MAX_PAYLOADS payloads is the 'Continue' Q-Block2 - Option ('NUM modulo MAX_PAYLOADS' is zero, NUM is not zero, and M bit - is set (Section 3.4)). The server SHOULD recognize this as a + The server SHOULD recognize the 'Continue' Q-Block2 request as a continue request and just continue the transmission of the body (including Observe Option, if appropriate for an unsolicited response) rather than as a request for the remaining missing blocks. - It is possible that the server may start transmitting the next set of + It is likely that the server will start transmitting the next set of MAX_PAYLOADS payloads before the client times out on waiting for the last of the previous MAX_PAYLOADS payloads. Upon receipt of the first payload from the new set of MAX_PAYLOADS payloads, the client SHOULD send a request indicating any missing payloads from any previous set of MAX_PAYLOADS payloads. Upon receipt of such request, the server SHOULD send the missing payloads before continuing to send the remainder of the MAX_PAYLOADS payloads and then go into another NON_TIMEOUT delay prior to sending the next set of payloads. The client does not need to acknowledge the receipt of the entire @@ -1114,26 +1145,25 @@ +--->X | NON PUT /path M:0x1b T:0xeb RT=11 QB1:10/1/1024 +--------->| NON PUT /path M:0x1c T:0xec RT=11 QB1:11/1/1024 | | Figure 5: Example of MAX_PAYLOADS NON Request with Q-Block1 Option (With Loss) On seeing a payload from the next set of payloads, the server realizes that some blocks are missing from the previous MAX_PAYLOADS payloads and asks for the missing blocks in one go (Figure 6). It - does so by indicating which blocks have not been received in the data - portion of the response. The token used in the response should be - the token that was used in the last block number received payload. - - The client can then derive the Request-Tag by matching the token with - the sent request. + does so by indicating which blocks from the previous MAX_PAYLOADS + payloads have not been received in the data portion of the response. + The token used in the response should be the token that was used in + the last block number received payload. The client can then derive + the Request-Tag by matching the token with the sent request. CoAP CoAP Client Server | | |<---------+ NON 4.08 M:0x91 T:0xec [Missing 1,9 [for RT=11]] | [[Client responds with missing payloads]] +--------->| NON PUT /path M:0x1d T:0xed RT=11 QB1:1/1/1024 +--------->| NON PUT /path M:0x1e T:0xee RT=11 QB1:9/1/1024 | [[Client continues sending next set of payloads]] +--------->| NON PUT /path M:0x1f T:0xef RT=11 QB1:12/0/1024 @@ -1142,31 +1172,69 @@ | [[The server realizes a block is still missing and asks | for the missing one]] |<---------+ NON 4.08 M:0x92 T:0xef [Missing 10 [for RT=11]] +--------->| NON PUT /path M:0x20 T:0xf0 RT=11 QB1:10/1/1024 |<---------+ NON 2.04 M:0x93 T:0xf0 | ... | Figure 6: Example of NON Request with Q-Block1 Option (Blocks Recovery) - Under high levels of traffic loss, the client can elect not to retry - sending missing blocks of data by "forgetting" all the tracked tokens - for this Request-Tag. Similarly, the server can elect to not to - continue asking for missing blocks. Both these decisions are - implementation specific. +9.1.4. Handling Recovery with Failure + + Figure 7 depicts an example of a NON PUT request conveying Q-Block1 + Option where recovery takes place, but eventually fails. + + CoAP CoAP + Client Server + | | + +--------->| NON PUT /path M:0x91 T:0xd0 RT=12 QB1:0/1/1024 + +--->X | NON PUT /path M:0x92 T:0xd1 RT=12 QB1:1/1/1024 + +--------->| NON PUT /path M:0x93 T:0xd2 RT=12 QB1:2/0/1024 + | ... | + [[NON_RECEIVE_TIMEOUT (server) delay expires]] + | [[The server realizes a block is missing and asks + | for the missing one. Retry #1]] + |<---------+ NON 4.08 M:0x01 T:0xd2 [Missing 1 [for RT=12]] + | ... | + [[2 * NON_RECEIVE_TIMEOUT (server) delay expires]] + | [[The server realizes a block is still missing and asks + | for the missing one. Retry #2]] + |<---------+ NON 4.08 M:0x02 T:0xd2 [Missing 1 [for RT=12]] + | ... | + [[4 * NON_RECEIVE_TIMEOUT (server) delay expires]] + | [[The server realizes a block is still missing and asks + | for the missing one. Retry #3]] + |<---------+ NON 4.08 M:0x03 T:0xd2 [Missing 1 [for RT=12]] + | ... | + [[8 * NON_RECEIVE_TIMEOUT (server) delay expires]] + | [[The server realizes a block is still missing and asks + | for the missing one. Retry #4]] + |<---------+ NON 4.08 M:0x04 T:0xd2 [Missing 1 [for RT=12]] + | ... | + [[16 * NON_RECEIVE_TIMEOUT (server) delay expires]] + | [[NON_MAX_RETRANSMIT exceeded. Server stops requesting + | for missing blocks and releases partial body]] + | ... | + + Figure 7: Example of NON Request with Q-Block1 Option (With Eventual + Failure) 9.2. Q-Block2 Option + These examples include the Observe Option to demonstrate how that + option is used. Note that the Observe Option is not required for + Q-Block2; the observe detail can thus be ignored. + 9.2.1. A Simple Example - Figure 7 illustrates the example of Q-Block2 Option. The client + Figure 8 illustrates the example of Q-Block2 Option. The client sends a NON GET carrying Observe and Q-Block2 Options. The Q-Block2 Option indicates a block size hint (1024 bytes). This request is replied to by the server using four (4) blocks that are transmitted to the client without any loss. Each of these blocks carries a Q-Block2 Option. The same process is repeated when an Observe is triggered, but no loss is experienced by any of the notification blocks. CoAP CoAP Client Server @@ -1177,26 +1245,26 @@ |<---------+ NON 2.05 M:0xf3 T:0xc0 O:1220 ET=19 QB2:2/1/1024 |<---------+ NON 2.05 M:0xf4 T:0xc0 O:1220 ET=19 QB2:3/0/1024 | ... | | [[Observe triggered]] |<---------+ NON 2.05 M:0xf5 T:0xc0 O:1221 ET=20 QB2:0/1/1024 |<---------+ NON 2.05 M:0xf6 T:0xc0 O:1221 ET=20 QB2:1/1/1024 |<---------+ NON 2.05 M:0xf7 T:0xc0 O:1221 ET=20 QB2:2/1/1024 |<---------+ NON 2.05 M:0xf8 T:0xc0 O:1221 ET=20 QB2:3/0/1024 | ... | - Figure 7: Example of NON Notifications with Q-Block2 Option (Without + Figure 8: Example of NON Notifications with Q-Block2 Option (Without Loss) 9.2.2. Handling MAX_PAYLOADS Limits - Figure 8 illustrates the same as Figure 7 but this time has eleven + Figure 9 illustrates the same as Figure 8 but this time has eleven (11) payloads which exceeds MAX_PAYLOADS. There is no loss experienced. CoAP CoAP Client Server | | +--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024 |<---------+ NON 2.05 M:0x81 T:0xf0 O:1234 ET=21 QB2:0/1/1024 |<---------+ NON 2.05 M:0x82 T:0xf0 O:1234 ET=21 QB2:1/1/1024 |<---------+ [[Payloads 3 - 9 not detailed]] @@ -1213,29 +1281,30 @@ |<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ NON 2.05 M:0x9a T:0xf0 O:1235 ET=22 QB2:9/1/1024 [[MAX_PAYLOADS has been reached]] | [[MAX_PAYLOADS blocks acknowledged by client using | 'Continue' Q-Block2]] +--------->| NON GET /path M:0x03 T:0xf2 QB2:10/1/1024 |<---------+ NON 2.05 M:0x9b T:0xf0 O:1235 ET=22 QB2:10/0/1024 [[Body has been received]] | ... | - Figure 8: Example of NON Notifications with Q-Block2 Option (Without + Figure 9: Example of NON Notifications with Q-Block2 Option (Without Loss) 9.2.3. Handling MAX_PAYLOADS with Recovery - Figure 9 shows the example of an Observe that is triggered but for + Figure 10 shows the example of an Observe that is triggered but for which some notification blocks are lost. The client detects the missing blocks and requests their retransmission. It does so by - indicating the blocks that were successfully received. + indicating the blocks that are missing as one or more Q-Block2 + Options. CoAP CoAP Client Server | ... | | [[Observe triggered]] |<---------+ NON 2.05 M:0xa1 T:0xf0 O:1236 ET=23 QB2:0/1/1024 | X<---+ NON 2.05 M:0xa2 T:0xf0 O:1236 ET=23 QB2:1/1/1024 |<---------+ [[Payloads 3 - 8 not detailed]] | X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024 [[MAX_PAYLOADS has been reached]] @@ -1253,30 +1322,26 @@ |<---------+ NON 2.05 M:0xad T:0xf3 ET=23 QB2:9/1/1024 | ... | [[NON_RECEIVE_TIMEOUT (client) delay expires]] | [[Client realizes block is still missing and asks for | missing block]] +--------->| NON GET /path M:0x05 T:0xf4 QB2:1/0/1024 |<---------+ NON 2.05 M:0xae T:0xf4 ET=23 QB2:1/1/1024 [[Body has been received]] | ... | - Figure 9: Example of NON Notifications with Q-Block2 Option (Blocks + Figure 10: Example of NON Notifications with Q-Block2 Option (Blocks Recovery) - Under high levels of traffic loss, the client can elect not to retry - getting missing blocks of data. This decision is implementation - specific. - 9.2.4. Handling Recovery using M-bit Set - Figure 10 shows the example of an Observe that is triggered but only + Figure 11 shows the example of an Observe that is triggered but only the first two notification blocks reach the client. In order to retrieve the missing blocks, the client sends a request with a single Q-Block2 Option with the M bit set. CoAP CoAP Client Server | ... | | [[Observe triggered]] |<---------+ NON 2.05 M:0xb1 T:0xf0 O:1237 ET=24 QB2:0/1/1024 |<---------+ NON 2.05 M:0xb2 T:0xf0 O:1237 ET=24 QB2:1/1/1024 @@ -1297,28 +1362,28 @@ |<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ NON 2.05 M:0xc2 T:0xf5 ET=24 QB2:9/1/1024 [[MAX_PAYLOADS has been reached]] | [[MAX_PAYLOADS acknowledged by client using 'Continue' | Q-Block2]] +--------->| NON GET /path M:0x87 T:0xf6 QB2:10/1/1024 |<---------+ NON 2.05 M:0xc3 T:0xf0 O:1237 ET=24 QB2:10/0/1024 [[Body has been received]] | ... | - Figure 10: Example of NON Notifications with Q-Block2 Option (Blocks + Figure 11: Example of NON Notifications with Q-Block2 Option (Blocks Recovery with M bit Set) 9.3. Q-Block1 and Q-Block2 Options 9.3.1. A Simple Example - Figure 11 illustrates the example of a FETCH using both Q-Block1 and + Figure 12 illustrates the example of a FETCH using both Q-Block1 and Q-Block2 Options along with an Observe Option. No loss is experienced. CoAP CoAP Client Server | | +--------->| NON FETCH /path M:0x10 T:0x90 O:0 RT=30 QB1:0/1/1024 +--------->| NON FETCH /path M:0x11 T:0x91 O:0 RT=30 QB1:1/1/1024 +--------->| NON FETCH /path M:0x12 T:0x93 O:0 RT=30 QB1:2/0/1024 |<---------+ NON 2.05 M:0x60 T:0x93 O:1320 ET=90 QB2:0/1/1024 @@ -1326,26 +1391,26 @@ |<---------+ NON 2.05 M:0x62 T:0x93 O:1320 ET=90 QB2:2/1/1024 |<---------+ NON 2.05 M:0x63 T:0x93 O:1320 ET=90 QB2:3/0/1024 | ... | | [[Observe triggered]] |<---------+ NON 2.05 M:0x64 T:0x93 O:1321 ET=91 QB2:0/1/1024 |<---------+ NON 2.05 M:0x65 T:0x93 O:1321 ET=91 QB2:1/1/1024 |<---------+ NON 2.05 M:0x66 T:0x93 O:1321 ET=91 QB2:2/1/1024 |<---------+ NON 2.05 M:0x67 T:0x93 O:1321 ET=91 QB2:3/0/1024 | ... | - Figure 11: Example of NON FETCH with Q-Block1 and Q-Block2 Options + Figure 12: Example of NON FETCH with Q-Block1 and Q-Block2 Options (Without Loss) 9.3.2. Handling MAX_PAYLOADS Limits - Figure 12 illustrates the same as Figure 11 but this time has eleven + Figure 13 illustrates the same as Figure 12 but this time has eleven (11) payloads in both directions which exceeds MAX_PAYLOADS. There is no loss experienced. CoAP CoAP Client Server | | +--------->| NON FETCH /path M:0x30 T:0xa0 O:0 RT=10 QB1:0/1/1024 +--------->| NON FETCH /path M:0x31 T:0xa1 O:0 RT=10 QB1:1/1/1024 +--------->| [[Payloads 3 - 9 not detailed]] +--------->| NON FETCH /path M:0x39 T:0xa9 O:0 RT=10 QB1:9/1/1024 @@ -1369,43 +1434,43 @@ |<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ NON 2.05 M:0x95 T:0xaa O:1335 ET=22 QB2:9/1/1024 [[MAX_PAYLOADS has been reached]] | [[MAX_PAYLOADS blocks acknowledged by client using | 'Continue' Q-Block2]] +--------->| NON FETCH /path M:0x3c T:0xac QB2:10/1/1024 |<---------+ NON 2.05 M:0x96 T:0xaa O:1335 ET=22 QB2:10/0/1024 [[Body has been received]] | ... | - Figure 12: Example of NON FETCH with Q-Block1 and Q-Block2 Options + Figure 13: Example of NON FETCH with Q-Block1 and Q-Block2 Options (Without Loss) 9.3.3. Handling Recovery Consider now a scenario where there are some blocks are lost in - transmission as illustrated in Figure 13. + transmission as illustrated in Figure 14. CoAP CoAP Client Server | | +--------->| NON FETCH /path M:0x50 T:0xc0 O:0 RT=31 QB1:0/1/1024 +--->X | NON FETCH /path M:0x51 T:0xc1 O:0 RT=31 QB1:1/1/1024 +--->X | NON FETCH /path M:0x52 T:0xc2 O:0 RT=31 QB1:2/1/1024 +--------->| NON FETCH /path M:0x53 T:0xc3 O:0 RT=31 QB1:3/0/1024 | ... | [[NON_RECEIVE_TIMEOUT (server) delay expires]] - Figure 13: Example of NON FETCH with Q-Block1 and Q-Block2 Options + Figure 14: Example of NON FETCH with Q-Block1 and Q-Block2 Options (With Loss) The server realizes that some blocks are missing and asks for the - missing blocks in one go (Figure 14). It does so by indicating which + missing blocks in one go (Figure 15). It does so by indicating which blocks have not been received in the data portion of the response. The token used in the response is be the token that was used in the last block number received payload. The client can then derive the Request-Tag by matching the token with the sent request. CoAP CoAP Client Server | | |<---------+ NON 4.08 M:0xa0 T:0xc3 [Missing 1,2 [for RT=31]] | [[Client responds with missing payloads]] @@ -1414,86 +1479,81 @@ | [[Server received FETCH body, | starts transmitting response body]] |<---------+ NON 2.05 M:0xa1 T:0xc3 O:1236 ET=23 QB2:0/1/1024 | X<---+ NON 2.05 M:0xa2 T:0xc3 O:1236 ET=23 QB2:1/1/1024 |<---------+ NON 2.05 M:0xa3 T:0xc3 O:1236 ET=23 QB2:2/1/1024 | X<---+ NON 2.05 M:0xa4 T:0xc3 O:1236 ET=23 QB2:3/0/1024 | ... | [[NON_RECEIVE_TIMEOUT (client) delay expires]] | | - Figure 14: Example of NON Request with Q-Block1 Option (Server + Figure 15: Example of NON Request with Q-Block1 Option (Server Recovery) The client realizes that not all the payloads of the response have been returned. The client then asks for the missing blocks in one go - (Figure 15). However, because the original request is spread over - multiple payloads using Q-Block1, the entire FETCH body has to be - used to make the request for the missing payloads. + (Figure 16). Note that, following Section 2.7 of [RFC7959], the + FETCH request does not include the Q-Block1 or any payload. CoAP CoAP Client Server | | - +--------->| NON FETCH /path M:0x56 T:0xc6 RT=31 QB1:0/1/1024\ - | | QB2:1/0/1024\ - | | QB2:3/0/1024 - +--------->| NON FETCH /path M:0x57 T:0xc7 RT=31 QB1:1/1/1024\ - | | QB2:1/0/1024\ - | | QB2:3/0/1024 - +--------->| NON FETCH /path M:0x58 T:0xc8 RT=31 QB1:2/1/1024\ - | | QB2:1/0/1024\ - | | QB2:3/0/1024 - +--------->| NON FETCH /path M:0x59 T:0xc9 RT=31 QB1:3/0/1024\ - | | QB2:1/0/1024\ + +--------->| NON FETCH /path M:0x56 T:0xc6 RT=31 QB2:1/0/1024\ | | QB2:3/0/1024 - | [[Server received FETCH request, + | [[Server receives FETCH request for missing payloads, | starts transmitting missing blocks]] - | X<---+ NON 2.05 M:0xa5 T:0xc9 ET=23 QB2:1/1/1024 - |<---------+ NON 2.05 M:0xa6 T:0xc9 ET=23 QB2:3/0/1024 + | X<---+ NON 2.05 M:0xa5 T:0xc6 ET=23 QB2:1/1/1024 + |<---------+ NON 2.05 M:0xa6 T:0xc6 ET=23 QB2:3/0/1024 | ... | [[NON_RECEIVE_TIMEOUT (client) delay expires]] | [[Client realizes block is still missing and asks for | missing block]] - +--------->| NON FETCH /path M:0x5a T:0xca RT=31 QB1:0/1/1024\ - | | QB2:1/0/1024 - +--------->| NON FETCH /path M:0x5b T:0xcb RT=31 QB1:1/1/1024\ - | | QB2:1/0/1024 - +--------->| NON FETCH /path M:0x5c T:0xcc RT=31 QB1:2/1/1024\ - | | QB2:1/0/1024 - +--------->| NON FETCH /path M:0x5d T:0xcd RT=31 QB1:3/0/1024\ - | | QB2:1/0/1024 - | [[Server received FETCH request, + +--------->| NON FETCH /path M:0x57 T:0xc7 RT=31 QB2:1/0/1024 + | [[Server receives FETCH request for missing payload, | starts transmitting missing block]] - |<---------+ NON 2.05 M:0xa7 T:0xcd ET=23 QB2:1/1/1024 + |<---------+ NON 2.05 M:0xa7 T:0xc7 ET=23 QB2:1/1/1024 + [[Body has been received]] + | ... | + | [[Observe triggered]] + |<---------+ NON 2.05 M:0xa8 T:0xc3 O:1337 ET=24 QB2:0/1/1024 + | X<---+ NON 2.05 M:0xa9 T:0xc3 O:1337 ET=24 QB2:1/1/1024 + |<---------+ NON 2.05 M:0xaa T:0xc3 O:1337 ET=24 QB2:2/0/1024 + [[NON_RECEIVE_TIMEOUT (client) delay expires]] + | [[Client realizes block is still missing and asks for + | missing block]] + +--------->| NON FETCH /path M:0x58 T:0xc8 RT=31 QB2:1/0/1024 + | [[Server receives FETCH request for missing payload, + | starts transmitting missing block]] + |<---------+ NON 2.05 M:0xa7 T:0xc8 ET=23 QB2:1/1/1024 [[Body has been received]] | ... | - Figure 15: Example of NON Request with Q-Block1 Option (Client + Figure 16: Example of NON Request with Q-Block1 Option (Client Recovery) 10. IANA Considerations 10.1. New CoAP Options IANA is requested to add the following entries to the "CoAP Option Numbers" sub-registry [Options]: +--------+------------------+-----------+ | Number | Name | Reference | +========+==================+===========+ | TBA1 | Q-Block1 | [RFCXXXX] | | TBA2 | Q-Block2 | [RFCXXXX] | +--------+------------------+-----------+ - Table 4: CoAP Q-Block1 and Q-Block2 Option Numbers + Table 5: CoAP Q-Block1 and Q-Block2 Option Numbers - This document suggests 19 (TBA1) and 51 (TBA2) as a values to be + This document suggests 19 (TBA1) and 51 (TBA2) as values to be assigned for the new option numbers. 10.2. New Media Type This document requests IANA to register the "application/missing- blocks+cbor-seq" media type in the "Media Types" registry [IANA-MediaTypes]: Type name: application @@ -1538,23 +1598,42 @@ Provisional registration? No 10.3. New Content Format This document requests IANA to register the CoAP Content-Format ID for the "application/missing-blocks+cbor-seq" media type in the "CoAP Content-Formats" registry [Format]: o Media Type: application/missing-blocks+cbor-seq o Encoding: - - o Id: TBD3 + o Id: TBA3 o Reference: [RFCXXXX] + This document suggests 272 (TBA3) as a value to be assigned for the + new content format number. + +10.4. New CoAP Signaling Option Number + + This document requests IANA to register the following option in the + "CoAP Signaling Option Numbers" registry [CSM]. + + +------------+--------+-----------------------+-----------+ + | Applies to | Number | Name | Reference | + +============+========+=======================+===========+ + | 7.01 | TBA4 | Q-Block-Wise-Transfer | [RFCXXXX] | + +------------+--------+-----------------------+-----------+ + + Table 6: CoAP Signaling Option Codes + + This document suggests 8 (TBA4) as a value to be assigned for the new + option number. + 11. Security Considerations Security considerations discussed in Section 7 of [RFC7959] should be taken into account. Security considerations discussed in Sections 11.3 and 11.4 of [RFC7252] should be taken into account. OSCORE provides end-to-end protection of all information that is not required for proxy operations and requires that a security context is @@ -1642,89 +1721,98 @@ Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . 13.2. Informative References - [Format] , . + [CSM] "CoAP Signaling Option Numbers", + . + + [Format] "CoAP Content-Formats", . [I-D.bosh-dots-quick-blocks] Boucadair, M. and J. Shallow, "Distributed Denial-of- Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Faster Block Transmission", draft-bosh-dots-quick-blocks-00 (work in progress), January 2021. [I-D.ietf-dots-telemetry] Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c., and J. Shallow, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15 (work in progress), December 2020. [IANA-MediaTypes] IANA, "Media Types", . - [Options] , . + [Options] "CoAP Option Numbers", . [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, DOI 10.17487/RFC6928, April 2013, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., Mortensen, A., and N. Teague, "Distributed Denial-of- Service Open Threat Signaling (DOTS) Signal Channel Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, . + [RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and + Stateless Clients in the Constrained Application Protocol + (CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021, + . + Appendix A. Examples with Confirmable Messages These examples assume NSTART has been increased to at least 4. The notations provided in Figure 2 are used in the following subsections. A.1. Q-Block1 Option Let's now consider the use Q-Block1 Option with a CON request as - shown in Figure 16. All the blocks are acknowledged (ACK). + shown in Figure 17. All the blocks are acknowledged (ACK). CoAP CoAP Client Server | | +--------->| CON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024 +--------->| CON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024 +--------->| CON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024 +--------->| CON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024 |<---------+ ACK 0.00 M:0x01 |<---------+ ACK 0.00 M:0x02 |<---------+ ACK 0.00 M:0x03 |<---------+ ACK 2.04 M:0x04 | | - Figure 16: Example of CON Request with Q-Block1 Option (Without Loss) + Figure 17: Example of CON Request with Q-Block1 Option (Without Loss) Now, suppose that a new body of data is to be sent but with some - blocks dropped in transmission as illustrated in Figure 17. The + blocks dropped in transmission as illustrated in Figure 18. The client will retry sending blocks for which no ACK was received. CoAP CoAP Client Server | | +--------->| CON PUT /path M:0x05 T:0xf4 RT=11 QB1:0/1/1024 +--->X | CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 +--------->| CON PUT /path M:0x08 T:0xf7 RT=11 QB1:3/1/1024 |<---------+ ACK 0.00 M:0x05 @@ -1736,36 +1824,36 @@ +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 |<---------+ ACK 0.00 M:0x06 | ... | [[ACK_TIMEOUT exponential backoff (client) delay expires]] | [[Client retransmits associated packet]] +--->? | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 | ... | [[Either body transmission failure (acknowledge retry timeout) or successfully transmitted.]] - Figure 17: Example of CON Request with Q-Block1 Option (Blocks + Figure 18: Example of CON Request with Q-Block1 Option (Blocks Recovery) It is up to the implementation as to whether the application process stops trying to send this particular body of data on reaching MAX_RETRANSMIT for any payload, or separately tries to initiate the new transmission of the payloads that have not been acknowledged under these adverse traffic conditions. If there is likely to be the possibility of network transient losses, then the use of NON should be considered. A.2. Q-Block2 Option An example of the use of Q-Block2 Option with Confirmable messages is - shown in Figure 18. + shown in Figure 19. Client Server | | +--------->| CON GET /path M:0x01 T:0xf0 O:0 QB2:0/0/1024 |<---------+ ACK 2.05 M:0x01 T:0xf0 O:1234 ET=21 QB2:0/1/1024 |<---------+ ACK 2.05 M:0xe1 T:0xf0 O:1234 ET=21 QB2:1/1/1024 |<---------+ ACK 2.05 M:0xe2 T:0xf0 O:1234 ET=21 QB2:2/1/1024 |<---------+ ACK 2.05 M:0xe3 T:0xf0 O:1234 ET=21 QB2:3/0/1024 | ... | | [[Observe triggered]] @@ -1792,21 +1880,21 @@ | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 |--------->+ ACK 0.00 M:0xe9 | ... | [[ACK_TIMEOUT exponential backoff (server) delay expires]] | [[Server retransmits associated packet]] | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 | ... | [[Either body transmission failure (acknowledge retry timeout) or successfully transmitted.]] - Figure 18: Example of CON Notifications with Q-Block2 Option + Figure 19: Example of CON Notifications with Q-Block2 Option It is up to the implementation as to whether the application process stops trying to send this particular body of data on reaching MAX_RETRANSMIT for any payload, or separately tries to initiate the new transmission of the payloads that have not been acknowledged under these adverse traffic conditions. If there is likely to be the possibility of network transient losses, then the use of NON should be considered.