--- 1/draft-ietf-core-new-block-11.txt 2021-05-11 06:13:51.365776064 -0700 +++ 2/draft-ietf-core-new-block-12.txt 2021-05-11 06:13:51.453778258 -0700 @@ -1,243 +1,285 @@ CoRE Working Group M. Boucadair Internet-Draft Orange Intended status: Standards Track J. Shallow -Expires: October 30, 2021 April 28, 2021 +Expires: November 12, 2021 May 11, 2021 Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Faster Transmission - draft-ietf-core-new-block-11 + draft-ietf-core-new-block-12 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 - defined in RFC 7959, not a replacement for them, but do enable faster - transmission rates for large amounts of data with less packet - interchanges. Also, Q-Block1 and Q-Block2 Options support faster - recovery should any of the blocks get lost in transmission. + These options are similar to, but distinct from, the CoAP Block1 and + Block2 Options defined in RFC 7959. Q-Block1 and Q-Block2 Options + are not intended to replace Block1 and Block2 Options, but rather + have the goal of enabling faster transmission rates for large amounts + of data with fewer packet interchanges. Also, the Q-Block1 and + Q-Block2 Options support faster recovery should any of the blocks get + lost in transmission. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 October 30, 2021. + This Internet-Draft will expire on November 12, 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Alternative CoAP Block-Wise Transfer Options . . . . . . . . 4 - 3.1. CoAP Response Code (4.08) Usage . . . . . . . . . . . . . 6 - 3.2. Applicability Scope . . . . . . . . . . . . . . . . . . . 6 - 4. The Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 7 - 4.1. Properties of Q-Block1 and Q-Block2 Options . . . . . . . 7 - 4.2. Structure of Q-Block1 and Q-Block2 Options . . . . . . . 9 - 4.3. Using the Q-Block1 Option . . . . . . . . . . . . . . . . 9 - 4.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 13 - 4.5. Using Observe Option . . . . . . . . . . . . . . . . . . 16 - 4.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 16 - 4.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 16 - 4.8. Using Q-Block2 Option With Multicast . . . . . . . . . . 16 - 5. The Use of 4.08 (Request Entity Incomplete) Response Code . . 16 - 6. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 18 - 7. Congestion Control for Unreliable Transports . . . . . . . . 18 - 7.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 18 - 7.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 19 - 8. Caching Considerations . . . . . . . . . . . . . . . . . . . 22 - 9. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 24 - 10. Examples with Non-confirmable Messages . . . . . . . . . . . 24 - 10.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . 24 - 10.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 24 - 10.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 25 - 10.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 25 - 10.1.4. Handling Recovery with Failure . . . . . . . . . . . 27 - 10.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . 27 - 10.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 28 - 10.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 28 - 10.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 29 - 10.2.4. Handling Recovery using M-bit Set . . . . . . . . . 30 - 10.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . 31 - 10.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 31 - 10.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 32 - 10.3.3. Handling Recovery . . . . . . . . . . . . . . . . . 33 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 35 - 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 - 12.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 36 - 12.2. Media Type Registration . . . . . . . . . . . . . . . . 36 - 12.3. CoAP Content-Formats Registry . . . . . . . . . . . . . 37 - - 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 - Appendix B. Examples with Reliable Transports . . . . . . . . . 44 - B.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 44 - B.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 44 - Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 + 3. Alternative CoAP Block-Wise Transfer Options . . . . . . . . 5 + 3.1. CoAP Response Code (4.08) Usage . . . . . . . . . . . . . 7 + 3.2. Applicability Scope . . . . . . . . . . . . . . . . . . . 7 + 4. The Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 8 + 4.1. Properties of Q-Block1 and Q-Block2 Options . . . . . . . 8 + 4.2. Structure of Q-Block1 and Q-Block2 Options . . . . . . . 10 + 4.3. Using the Q-Block1 Option . . . . . . . . . . . . . . . . 10 + 4.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 14 + 4.5. Using Observe Option . . . . . . . . . . . . . . . . . . 17 + 4.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 17 + 4.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 17 + 4.8. Using Q-Block2 Option With Multicast . . . . . . . . . . 17 + 5. The Use of 4.08 (Request Entity Incomplete) Response Code . . 17 + 6. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 19 + 7. Congestion Control for Unreliable Transports . . . . . . . . 19 + 7.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 19 + 7.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 20 + 8. Caching Considerations . . . . . . . . . . . . . . . . . . . 24 + 9. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 25 + 10. Examples with Non-confirmable Messages . . . . . . . . . . . 25 + 10.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . 26 + 10.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 26 + 10.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 26 + 10.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 26 + 10.1.4. Handling Recovery with Failure . . . . . . . . . . . 28 + 10.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . 29 + 10.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 29 + 10.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 30 + 10.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 31 + 10.2.4. Handling Recovery using M-bit Set . . . . . . . . . 32 + 10.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . 33 + 10.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 33 + 10.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 34 + 10.3.3. Handling Recovery . . . . . . . . . . . . . . . . . 35 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 + 12.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 38 + 12.2. Media Type Registration . . . . . . . . . . . . . . . . 38 + 12.3. CoAP Content-Formats Registry . . . . . . . . . . . . . 39 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 40 + 13.2. Informative References . . . . . . . . . . . . . . . . . 41 + Appendix A. Examples with Confirmable Messages . . . . . . . . . 42 + A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 42 + A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 44 + Appendix B. Examples with Reliable Transports . . . . . . . . . 46 + B.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 46 + B.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 46 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 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, - TLS, and WebSockets. + delivery, simple congestion control, and flow control. CoAP supports + two message types (Section 1.2 of [RFC7252]): Confirmable (CON) and + Non-confirmable (NON) messages. Unlike NON messages, every CON + message will elect an acknowledgement or a reset. + + The CoAP specification recommends that a CoAP message should fit + within a single IP packet (i.e., avoid IP fragmentation). To handle + data records that cannot fit in a single IP packet, [RFC7959] + introduced the concept of block-wise transfer and the companion CoAP + Block1 and Block2 Options. However, this concept is designed to work + exclusively with Confirmable messages (Section 1 of [RFC7959]). Note + that the block-wise transfer was further updated by [RFC8323] for use + over TCP, TLS, and WebSockets. The CoAP Block1 and Block2 Options work well in environments where - there are no or minimal packet losses. These options operate + there are no, or minimal, packet losses. These options operate synchronously, i.e., each individual block has to be requested. A CoAP endpoint can only ask for (or send) the next block when the transfer of the previous block has completed. Packet transmission rate, and hence block transmission rate, is controlled by Round Trip Times (RTTs). - There is a requirement for these blocks of data to be transmitted at - higher rates under network conditions where there may be asymmetrical - transient packet loss (i.e., responses may get dropped). An example - is when a network is subject to a Distributed Denial of Service - (DDoS) attack and there is a need for DDoS mitigation agents relying - upon CoAP to communicate with each other (e.g., - [RFC8782][I-D.ietf-dots-telemetry]). As a reminder, [RFC7959] - recommends the use of Confirmable (CON) responses to handle potential + There is a requirement for blocks of data larger than a single IP + datagram to be transmitted at higher rates under network conditions + where there may be asymmetrical transient packet loss (e.g., + responses may get dropped). An example is when a network is subject + to a Distributed Denial of Service (DDoS) attack and there is a need + for DDoS mitigation agents relying upon CoAP to communicate with each + other (e.g., [RFC8782][I-D.ietf-dots-telemetry]). As a reminder, + + [RFC7959] recommends the use of CON responses to handle potential packet loss. However, such a recommendation does not work with a - flooded pipe DDoS situation. + flooded pipe DDoS situation (e.g., [RFC8782]). - This document introduces the CoAP Q-Block1 and Q-Block2 Options - (Section 3). + This document introduces the CoAP Q-Block1 and Q-Block2 Options which + allow block-wise transfer to work with series of Non-confirmable + messages, instead of lock-stepping using Confirmable messages + (Section 3). In other words, this document provides a missing piece + of [RFC7959], namely the support of block-wise transfer using Non- + confirmable where an entire body of data can be transmitted without + the requirement for an acknowledgement (but recovery is available + should it be needed). + + Similar to [RFC7959], this specification does not remove any of the + constraints posed by the base CoAP specification [RFC7252] it is + strictly layered on top of. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. Readers should be familiar with the terms and concepts defined in - [RFC7252], [RFC7959], and [RFC8132]. + [RFC7252], [RFC7959], and [RFC8132]. Particularly, the document uses + the following key concepts: + + Token: is used to match responses to requests independently from the + underlying messages (Section 5.3.1 of [RFC7252]). + + ETag: is used as a resource-local identifier for differentiating + between representations of the same resource that vary over time + (Section 5.10.6 of [RFC7252]). The terms "payload" and "body" are defined in [RFC7959]. The term "payload" is thus used for the content of a single CoAP message (i.e., a single block being transferred), while the term "body" is used for the entire resource representation that is being transferred in a block-wise fashion. + Request-Tag refers to an option that allows a CoAP server to match + message fragments belonging to the same request + [I-D.ietf-core-echo-request-tag]. + + MAX_PAYLOADS is the maximum number of payloads that can be + transmitted at any one time. + + MAX_PAYLOADS_SET is the set of blocks identified by block numbers + that, when divided by MAX_PAYLOADS, they have the same numeric + result. For example, if MAX_PAYLOADS is set to '10', a + MAX_PAYLOADS_SET could be blocks #0 to #9, #10 to #19, etc. + Depending on the data size, the MAX_PAYLOADS_SET may not comprise all + the MAX_PAYLOADS blocks. + 3. Alternative CoAP Block-Wise Transfer Options This document introduces the CoAP Q-Block1 and Q-Block2 Options. - These options are similar in operation to the CoAP Block1 and Block2 - Options, respectively. They are not a replacement for them, but have - the following benefits: + These options are designed to work in particular with NON requests + and responses. + + Using NON messages, the faster transmissions occur as all the blocks + can be transmitted serially (akin to fragmented IP 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 message. Even if there is + asymmetrical packet loss, a body can still be sent and received by + the peer whether the body comprises a single or multiple payloads, + assuming no recovery is required. + + A CoAP endpoint can acknowledge all or a subset of the blocks. + Concretely, the receiving CoAP endpoint either informs the CoAP + sender endpoint of successful reception or reports on all blocks in + the body that have not yet been received. The CoAP sender endpoint + will then retransmit only the blocks that have been lost in + transmission. + + Note that similar transmission rate benefits can be applied to + Confirmable messages if the value of NSTART is increased from 1 + (Section 4.7 of [RFC7252]). However, the use of Confirmable messages + will not work effectively if there is asymmetrical packet loss. Some + examples with Confirmable messages are provided in Appendix A. + + There is little, if any, benefit of using these options with CoAP + running over a reliable connection [RFC8323]. In this case, there is + no differentiation between CON and NON as they are not used. Some + examples using a reliable transport are provided in Appendix B. + + Q-Block1 and Q-Block2 Options are similar in operation to the CoAP + Block1 and Block2 Options, respectively. They are not a replacement + for them, but have the following benefits: o They can operate in environments where packet loss is highly asymmetrical. o They enable faster transmissions of sets of blocks of data with - less packet interchanges. + fewer packet interchanges. o They support faster recovery should any of the blocks get lost in transmission. - o They support sending an entire body using Non-confirmable (NON) - messages without requiring a response from the peer. + o They support sending an entire body using NON messages without + requiring an intermediate response from the peer. There are the following disadvantages over using CoAP Block1 and Block2 Options: o Loss of lock-stepping so payloads are not always received in the correct (block ascending) order. o Additional congestion control measures need to be put in place for NON messages (Section 7.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. + congestion control and incurs a requirement to re-tune other + parameters (Section 4.7 of [RFC7252]). Such tuning is out of + scope of this document. o Mixing of NON and CON during requests/responses using Q-Block is not supported. o The Q-Block Options do not support stateless operation/random access. o Proxying of Q-Block is limited to caching full representations. o There is no multicast support. - Q-Block1 and Q-Block2 Options are designed to work in particular with - NON requests and responses. - - 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 message. 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. - - A CoAP endpoint can acknowledge all or a subset of the blocks. - Concretely, the receiving CoAP endpoint either informs the CoAP - sender endpoint of successful reception or reports on all blocks in - the body that have not yet been received. The CoAP sender endpoint - will then retransmit only the blocks that have been lost in - transmission. - - Note that similar performance benefits can be applied to Confirmable - messages if the value of NSTART is increased from 1 (Section 4.7 of - [RFC7252]). However, the use of Confirmable messages will not work - if there is asymmetrical packet loss. Some examples with Confirmable - messages are provided in Appendix A. - - There is little, if any, benefit of using these options with CoAP - running over a reliable connection [RFC8323]. In this case, there is - no differentiation between CON and NON as they are not used. Some - examples using a reliable transport are provided in Appendix B. - Q-Block1 and Q-Block2 Options can be used instead of Block1 and Block2 Options when the different transmission properties are required. If the new options are not supported by a peer, then transmissions can fall back to using Block1 and Block2 Options (Section 4.1). The deviations from Block1 and Block2 Options are specified in Section 4. Pointers to appropriate [RFC7959] sections are provided. The specification refers to the base CoAP methods defined in @@ -261,41 +303,43 @@ The block-wise transfer specified in [RFC7959] covers the general case, but falls short in situations where packet loss is highly asymmetrical. The mechanism specified in this document provides roughly similar features to the Block1/Block2 Options. It provides additional properties that are tailored towards the intended use case of Non-Confirmable transmission. Concretely, this mechanism primarily targets applications such as DDoS Open Threat Signaling (DOTS) that cannot use CON responses to handle potential packet loss and that support application-specific mechanisms to assess whether - the remote peer is able to handle the messages sent by a CoAP - endpoint (e.g., DOTS heartbeats in Section 4.7 of [RFC8782]). + the remote peer is not overloaded and thus is able to process the + messages sent by a CoAP endpoint (e.g., DOTS heartbeats in + Section 4.7 of [RFC8782]). The mechanism includes guards to prevent a CoAP agent from overloading the network by adopting an aggressive sending rate. These guards MUST be followed in addition to the existing CoAP congestion control as specified in Section 4.7 of [RFC7252]. See Section 7 for more details. This mechanism is not intended for general CoAP usage, and any use outside the intended use case should be carefully weighed against the loss of interoperability with generic CoAP applications. It is hoped that the experience gained with this mechanism can feed future extensions of the block-wise mechanism that will both be generally applicable and serve this particular use case. It is not recommended that these options are used in a NoSec security mode (Section 9 of [RFC7252]) as the source endpoint needs to be trusted. Using OSCORE [RFC8613] does provide a security context and, - hence, a trust of the source endpoint. However, using a NoSec - security mode may still be inadequate for reasons discussed in + hence, a trust of the source endpoint that prepared the inner OSCORE + content. However, even with OSCORE, using a NoSec security mode with + these options may still be inadequate, for reasons discussed in Section 11. 4. The Q-Block1 and Q-Block2 Options 4.1. Properties of Q-Block1 and Q-Block2 Options The properties of the Q-Block1 and Q-Block2 Options are shown in Table 1. The formatting of this table follows the one used in Table 4 of [RFC7252] (Section 5.10). The C, U, N, and R columns indicate the properties Critical, UnSafe, NoCacheKey, and Repeatable @@ -314,100 +358,107 @@ Table 1: CoAP Q-Block1 and Q-Block2 Option Properties The Q-Block1 and Q-Block2 Options can be present in both the request and response messages. The Q-Block1 Option pertains to the request payload and the Q-Block2 Option pertains to the response payload. When the Content-Format Option is present together with the Q-Block1 or Q-Block2 Option, the 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. + The Q-Block1 Option is useful with the payload-bearing, e.g., 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]). + The Q-Block2 Option is useful, e.g., with GET, POST, PUT, FETCH, + PATCH, and iPATCH requests and their payload-bearing responses (2.01, + 2.02, 2.04, and 2.05) (Section 5.5 of [RFC7252]). 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. + If the Q-Block1 Option is present in a request or the Q-Block2 Option + is returned in a response, this 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 (FETCH, for - example), the Q-Block2 Option in a PUT or similar request, or the - Q-Block1 Option in a PUT or similar request so that the server knows - that the client supports this Q-Block 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]. + example), the Q-Block2 Option in a PUT or similar request (POST, for + example), or the Q-Block1 Option in a PUT or similar request so that + the server knows that the client supports this Q-Block 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]. How a client decides whether it needs to include a Q-Block1 or - Q-Block2 Option can be driven by a local configuration knob, + Q-Block2 Option can be driven by a local configuration parameter, triggered by an application (DOTS, for example), etc. Such considerations are out of the scope of the document. 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 a Reset message or just silently ignored (Sections 5.4.1 and 4.3 of [RFC7252]). To reliably get a rejection message, it is therefore REQUIRED that clients use a Confirmable message for determining - support for Q-Block1 and Q-Block2 Options. + support for Q-Block1 and Q-Block2 Options. This CON message can be + sent under base CoAP congestion control setup specified in + Section 4.7 of [RFC7252] (that is, NSTART does not need to be + increased (Section 7.1)). 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]. The Q-Block1 and Q-Block2 Options, like the Block1 and Block2 - Options, both of class E and class U for OSCORE processing (Table 2). - 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. + Options, are of both class E and class U for OSCORE processing + (Table 2). 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 Note that if Q-Block1 or Q-Block2 Options are included in a packet as Inner options, Block1 or Block2 Options MUST NOT be included as Inner - options. Similarly there MUST NOT be a mix of Q-Block and Block for + options. Similarly, there MUST NOT be a mix of Q-Block and Block for the Outer options. Messages that do not adhere with this behavior MUST be rejected with 4.02 (Bad Option). Q-Block and Block Options can be mixed across Inner and Outer options as these are handled - independently of each other. + independently of each other. For clarity, if OSCORE is not being + used, there MUST NOT be a mix of Q-Block and Block Options in the + same packet. 4.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 @@ -423,117 +474,117 @@ 4.3. Using the Q-Block1 Option The Q-Block1 Option is used when the client wants to send a large amount of data to the server using the POST, PUT, FETCH, PATCH, or iPATCH methods where the data and headers do not fit into a single packet. When Q-Block1 Option is used, the client MUST include a Request-Tag Option [I-D.ietf-core-echo-request-tag]. The Request-Tag value MUST be the same for all of the requests for the body of data that is - being transferred. The Request-Tag is opaque, the server still - treats it as opaque but the client MUST ensure that it is unique for - every different body of transmitted data. + being transferred. The Request-Tag is opaque, but the client MUST + ensure 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 4.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 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. + Non-confirmable transmission, no response is required until either + the successful receipt of the body by the server or a timer expires + with some of the payloads having not yet arrived. In the latter + case, 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 message that carries a block of the body is treated as a new request (Section 6). - 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 7)). Any missing payloads requested by - the server must in addition be separately transmitted with increasing - block numbers. + The client MUST send the payloads in order of increasing block + number, starting from zero, until the body is complete (subject to + any congestion control (Section 7)). Any missing payloads requested + by the server must in addition be separately transmitted with + increasing block numbers. The following Response Codes are used: 2.01 (Created) This Response Code indicates successful receipt of the entire body - and that the resource was created. The token used MUST be one of - the tokens that were received in a request for this block-wise + and that the resource was created. The token to use MUST be one + of the tokens that were received in a request for this block-wise exchange. However, it is desirable to provide the one used in the last received request, since that will aid any troubleshooting. The client should then release all of the tokens used for this - body. Note that the last received payload may not be the one with - the highest block number. + body. Note that the last received payload might not be the one + with the highest block number. 2.02 (Deleted) This Response Code indicates successful receipt of the entire body and that the resource was deleted when using POST (Section 5.8.2 - [RFC7252]). The token used MUST be one of the tokens that were + [RFC7252]). The token to use MUST be one of the tokens that were received in a request for this block-wise exchange. However, it is desirable to provide the one used in the last received request. The client should then release all of the tokens used for this body. 2.04 (Changed) This Response Code indicates successful receipt of the entire body - and that the resource was updated. The token used MUST be one of - the tokens that were received in a request for this block-wise + and that the resource was updated. The token to use MUST be one + of the tokens that were received in a request for this block-wise exchange. However, it is desirable to provide the one used in the last received request. 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 that the appropriate representation of the resource is being returned. The - token used MUST be one of the tokens that were received in a + token to use MUST be one of the tokens that were received in a request for this block-wise exchange. However, it is desirable to provide the one used in the last received request. If the FETCH request includes the Observe Option, then the server MUST use the same token as used for the initial response for returning any Observe triggered responses so that the client can match them up. 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 up to and including the Q-Block1 Option block NUM (all having the - M bit set) have been successfully received. The token used MUST + M bit set) have been successfully received. The token to use MUST be one of the tokens that were received in a request for this block-wise exchange. However, it is desirable to provide the one used in the last received request. A response using this Response Code SHOULD NOT be generated for every received Q-Block1 Option request (Section 7.2). It SHOULD only be generated when all the payload requests are Non- - confirmable and a set of MAX_PAYLOADS payloads have been received - by the server. More details about the motivations for this - optimization are discussed in Section 7.2. + confirmable and a MAX_PAYLOADS_SET has been received by the + server. More details about the motivations for this optimization + are discussed in Section 7.2. This Response Code SHOULD NOT be generated for CON. 4.00 (Bad Request) This Response Code MUST be returned if the request does not include a Request-Tag Option or a Size1 Option but does include a Q-Block1 option. 4.02 (Bad Option) @@ -544,39 +595,40 @@ 4.08 (Request Entity Incomplete) As a reminder, this Response Code returned without Content-Type "application/missing-blocks+cbor-seq" (Section 12.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 NUM, SZX, and M bit as appropriate. + individual missing payloads using the same Request-Tag, Size1, + and, Q-Block1 Option to specify the same NUM, SZX, and M bit as + sent initially in the original, but not received, packet. 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 MUST be one of the tokens that were received in a - request for this block-wise exchange. However, it is desirable to - provide the one used in the last received request. See Section 5 - for further information. + The token to use in the 4.08 (Request Entity Incomplete) response + MUST be one of the tokens that were received in a request for this + block-wise body exchange. However, it is desirable to provide the + one used in the last received request. See Section 5 for further + information. If the server has not received all the blocks of a body, but one - or more NON payloads have been received, it SHOULD wait for up to + or more NON payloads have been received, it SHOULD wait for NON_RECEIVE_TIMEOUT (Section 7.2) before sending a 4.08 (Request Entity Incomplete) response. 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 in the response. Further considerations related to the transmission timings of 4.08 (Request Entity Incomplete) and 2.31 (Continue) Response Codes are @@ -591,124 +643,125 @@ absent any local policy, the client MUST "forget" all tracked tokens associated with the body's Request-Tag so that a reset message is generated for the invalid token in the 4.08 (Request Entity Incomplete) response. The server on receipt of the reset message SHOULD delete the partial body. If the server receives a duplicate block with the same Request-Tag, it MUST ignore the payload of the packet, but MUST still respond as if the block was received for the first time. - A server SHOULD maintain a partial body (missing payloads) for up to + A server SHOULD maintain a partial body (missing payloads) for NON_PARTIAL_TIMEOUT (Section 7.2). 4.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 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. + used to confirm that the current MAX_PAYLOADS_SET (the latest + block having block number NUM-1) has been successfully received + and that, upon receipt of this request, the server can continue to + send the next MAX_PAYLOADS_SET (the first block 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. + 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. The payloads sent back from the server as a response MUST all have the same ETag (Section 5.10.6 of [RFC7252]) for the same body. The server MUST NOT use the same ETag value for different representations of a resource. - The ETag is opaque, the client still treats it as opaque but the - server MUST ensure that it is unique for every different body of - transmitted data. + The ETag is opaque, but the server MUST 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 4.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 7.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. The client MAY set the M bit to request this and later blocks - from this MAX_PAYLOADS set. Further considerations related to the - transmission timing for missing requests are discussed in - Section 7.2. + For NON payloads, the client SHOULD wait NON_RECEIVE_TIMEOUT + (Section 7.2) after the last received payload before requesting + retransmission of any missing blocks. Retransmission is requested by + issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request that + contains one or more Q-Block2 Options that define the missing + block(s). Generally the M bit on the Q-Block2 Option(s) SHOULD be + unset, although the M bit MAY be set to request this and later blocks + from this MAX_PAYLOADS_SET, see Section 10.2.4 for an example of this + in operation. Further considerations related to the transmission + timing for missing requests are discussed in Section 7.2. The missing block numbers requested by the client MUST have an increasing block number in each additional Q-Block2 Option with no duplicates. The server SHOULD respond with a 4.00 (Bad Request) to requests not adhering to this behavior. Note that the ordering constraint is meant to force the client to check for duplicates and remove them. This also helps with troubleshooting. For Confirmable responses, the client continues to acknowledge each packet. Typically, the server acknowledges the initial request using an ACK with the payload, and then sends the subsequent payloads as CON responses. 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 MUST silently ignore the payload. - A client SHOULD maintain a partial body (missing payloads) for up to + A client SHOULD maintain a partial body (missing payloads) for NON_PARTIAL_TIMEOUT (Section 7.2) or as defined by the Max-Age Option (or its default of 60 seconds (Section 5.6.1 of [RFC7252])), whichever is the less. On release of the partial body, the client - should then release all of the tokens used for this body unless a - resource is being observed. + should then release all of the tokens used for this body apart from + the token that is used to track a resource that is being observed. 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 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. + The server SHOULD maintain 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 transmission is terminated. Any subsequent missing block requests MUST be responded to using the latest ETag and Size2 Option values with the updated data. 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 - being fresh. + being fresh. The client may then request all of the new data by + specifying Q-Block2 with block number '0' and the M bit set. If the server transmits a new body of data (e.g., a triggered Observe notification) 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 @@ -727,29 +780,29 @@ following receipt of the 'Continue' Q-Block2 Option (Section 4.4) by the server. If a missing payload is requested by a client, then both the request and response MUST NOT include the Observe Option. 4.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. + For Q-Block1 and Q-Block2 Options, 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 and MUST be present in all payloads of the request preserving - the same value. The Size2 Option MUST be used with the Q-Block2 - Option when used in a response and MUST be present in all payloads of - the response preserving the same value. + request and MUST be present in all payloads of the request, + preserving the same value. The Size2 Option MUST be used with the + Q-Block2 Option when used in a response and MUST be present in all + payloads of the response, preserving the same value. 4.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. 4.8. Using Q-Block2 Option With Multicast Servers MUST ignore multicast requests that contain the Q-Block2 @@ -762,21 +815,21 @@ "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. Such messages must not be treated by the client as a fatal error. 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. The data payload of the 4.08 (Request Entity Incomplete) response is - encoded as a CBOR Sequence [RFC8742]. It comprises of one or more + encoded as a CBOR Sequence [RFC8742]. It comprises one or more missing block numbers encoded as CBOR unsigned integers [RFC8949]. The missing block numbers MUST be unique in each 4.08 (Request Entity Incomplete) response when created by the server; the client MUST ignore any duplicates in the same 4.08 (Request Entity Incomplete) response. The Content-Format Option (Section 5.10.3 of [RFC7252]) MUST be used in the 4.08 (Request Entity Incomplete) response. It MUST be set to "application/missing-blocks+cbor-seq" (Section 12.3). @@ -785,35 +838,35 @@ follows: ; A notional array, the elements of which are to be used ; in a CBOR Sequence: payload = [+ missing-block-number] ; 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 be acceptable, but providing the one used in the - last received payload will aid any troubleshooting. The client will - use the token to determine what was the previously sent request to - obtain the Request-Tag value to be used. + It is desirable that the token to use for the response is 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 be acceptable, but providing the one used in + the last received payload will aid any troubleshooting. The client + will use the token to determine what was the previously sent request + to obtain the Request-Tag value that was 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. + of reported 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. The missing blocks MUST be reported in ascending order without any duplicates. The client SHOULD silently drop 4.08 (Request Entity Incomplete) responses not adhering with this behavior. Implementation Note: Consider limiting the number of missing payloads to MAX_PAYLOADS to minimize congestion control being needed. The CBOR sequence does not include any array wrapper. The 4.08 (Request Entity Incomplete) with Content-Type "application/ @@ -842,204 +895,214 @@ unreliable transport MUST 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]. 7.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 (Section 3.2). + Section 4.7 of [RFC7252]. In order to benefit from 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 not specified in this + document, given that the applicability scope of the current + specification assumes that all requests and responses using Q-Block1 + and Q-Block2 will be Non-confirmable (Section 3.2) apart from the + initial Q-Block functionality negotiation. - 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. + Following the failure to transmit a packet due to packet loss after + MAX_TRANSMIT_SPAN time (Section 4.8.2 of [RFC7252]), it is + implementation specific as to whether there should be any further + requests for missing data. 7.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 (Table 3). 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]. + those discussed in Section 5 of [RFC6928], especially given the + target application discussed in Section 3.2. - 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_TIMEOUT is the period of delay between sending MAX_PAYLOADS_SET + 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 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: + NON_RECEIVE_TIMEOUT is the initial 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 + opportunity to start sending the next MAX_PAYLOADS_SET 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 local endpoint SHOULD consider the body stale, remove any body, and release Tokens and Request-Tag on the client (or the ETag on the server). 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_PROBING_WAIT is used to limit the potential wait needed when + using PROBING_RATE. By default, NON_PROBING_WAIT has the same value + as 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 + By default, NON_PARTIAL_TIMEOUT has the same value as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). +---------------------+---------------+ | 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 - 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. + The 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. A single body 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 wait time + is limited to NON_PROBING_WAIT. Note: For the particular DOTS application, PROBING_RATE and other transmission parameters are negotiated between peers. Even when not negotiated, the DOTS application uses customized defaults as discussed in Section 4.5.2 of [RFC8782]. Note that MAX_PAYLOADS, - NON_MAX_RETRANSMIT, and NON_TIMEOUT can be negotiated between DOTS - peers as per [I-D.bosh-dots-quick-blocks]. + NON_MAX_RETRANSMIT, NON_TIMEOUT, NON_PROBING_WAIT, and + NON_PARTIAL_TIMEOUT can be negotiated between DOTS peers, e.g., as + per [I-D.bosh-dots-quick-blocks]. Each NON 4.08 (Request Entity Incomplete) response is subject to PROBING_RATE. - Each NON GET or FETCH request using Q-Block2 Option is subject to + Each NON GET or FETCH request using a Q-Block2 Option is subject to PROBING_RATE. As the sending of many payloads of a single body may itself cause - congestion, it is RECOMMENDED that after transmission of every set of - MAX_PAYLOADS payloads of a single body, a delay is introduced of - NON_TIMEOUT before sending the next set of payloads to manage + congestion, it is RECOMMENDED that after transmission of every + MAX_PAYLOADS_SET of a single body, a delay is introduced of + NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to manage potential congestion issues. - If the CoAP peer reports at least one payload has not arrived for - each body for at least a 24 hour period and it is known that there - are no other network issues over that period, then the value of - MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1) and - the situation re-evaluated for another 24 hour period until there is - no report of missing payloads under normal operating conditions. The - newly derived value for MAX_PAYLOADS should be used for both ends of - this particular CoAP peer link. Note that the CoAP peer will not - know about the MAX_PAYLOADS change until it is reconfigured. As a - consequence of the two peers having different MAX_PAYLOADS values, a - peer may continue indicate that there are some missing payloads as - all of its MAX_PAYLOADS set may not have arrived. How the two peer - values for MAX_PAYLOADS are synchronized is out of the scope. + If the CoAP peer reports that at least one payload has not arrived + for each body for at least a 24-hour period and it is known that + there are no other network issues over that period (e.g., DDoS + attacks), then the value of MAX_PAYLOADS can be reduced by 1 at a + time (to a minimum of 1) and the situation re-evaluated for another + 24-hour period until there is no report of missing payloads under + normal operating conditions. Following a period of 24 hours where no + packet recovery was required, the value of MAX_PAYLOADS can be + increased by 1 (but without exceeding the default value) for a + further 24-hour evaluation. The newly derived value for MAX_PAYLOADS + should be used for both ends of this particular CoAP peer link. Note + that the CoAP peer will not know about the MAX_PAYLOADS change until + it is reconfigured. As a consequence of the two peers having + different MAX_PAYLOADS values, a peer may continue indicating that + there are some missing payloads as all of its MAX_PAYLOADS_SET may + not have arrived. How the two peer values for MAX_PAYLOADS are + synchronized is out of the scope. - The sending of a set of missing blocks of a body is subject to - MAX_PAYLOADS set of payloads. + The sending of a set of missing blocks of a body is restricted to + those in a MAX_PAYLOADS_SET at a time. In other words, a NON_TIMEOUT + delay is still observed between each MAX_PAYLOAD_SET. For Q-Block1 Option, if the server responds with a 2.31 (Continue) 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. + continue to send the next MAX_PAYLOADS_SET without any further 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. If not all of - the MAX_PAYLOADS payloads were received, the 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 this is a - repeat for the 2.31 (Continue) response, the server SHOULD send a - 4.08 (Request Entity Incomplete) response detailing the missing - payloads after the block number that would have been indicated in the - 2.31 (Continue). 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. + 2.31 (Continue) Response Code on receipt of all of the + MAX_PAYLOADS_SET to prevent the client unnecessarily delaying. If + not all of the MAX_PAYLOADS_SET were received, the 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 all + of the MAX_PAYLOADS_SET were received and a 2.31 (Continue) had been + sent, but no more payloads were received for NON_RECEIVE_TIMEOUT + (exponentially scaled), the server SHOULD send a 4.08 (Request Entity + Incomplete) response detailing the missing payloads after the block + number that was indicated in the sent 2.31 (Continue). If the repeat + request count for the 4.08 (Request Entity Incomplete) exceeds + NON_MAX_RETRANSMIT, the server SHOULD discard the partial body and + stop requesting the missing payloads. - 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 - 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. + It is likely that the client will start transmitting the next + MAX_PAYLOADS_SET before the server times out on waiting for the last + of the previous MAX_PAYLOADS_SET. On receipt of a payload from the + next MAX_PAYLOADS_SET, the server SHOULD send a 4.08 (Request Entity + Incomplete) Response Code indicating any missing payloads from any + previous MAX_PAYLOADS_SET. 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_SET and then go into another NON_TIMEOUT delay prior to + sending the next MAX_PAYLOADS_SET. For the client receiving NON Q-Block2 responses, it SHOULD send a - 'Continue' Q-Block2 request (Section 4.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. + 'Continue' Q-Block2 request (Section 4.4) for the next + MAX_PAYLOADS_SET on receipt of all of the MAX_PAYLOADS_SET, 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 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 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. + It is likely that the server will start transmitting the next + MAX_PAYLOADS_SET before the client times out on waiting for the last + of the previous MAX_PAYLOADS_SET. Upon receipt of a payload from the + new MAX_PAYLOADS_SET, the client SHOULD send a request indicating any + missing payloads from any previous MAX_PAYLOADS_SET. Upon receipt of + such request, the server SHOULD send the missing payloads before + continuing to send the remainder of the MAX_PAYLOADS_SET and then go + into another NON_TIMEOUT delay prior to sending the next + MAX_PAYLOADS_SET. The client does not need to acknowledge the receipt of the entire body. Note: If there is asymmetric traffic loss causing responses to never get received, a delay of NON_TIMEOUT after every - transmission of MAX_PAYLOADS blocks will be observed. The - endpoint receiving the body is still likely to receive the entire - body. + transmission of MAX_PAYLOADS_SET will be observed. The endpoint + receiving the body is still likely to receive the entire body. 8. Caching Considerations Caching block based information is not straight forward in a proxy. For Q-Block1 and Q-Block2 Options, for simplicity it is expected that the proxy will reassemble the body (using any appropriate recovery options for packet loss) before passing on the body to the appropriate CoAP endpoint. This does not preclude an implementation doing a more complex per payload caching, but how to do this is out of the scope of this document. The onward transmission of the body @@ -1074,23 +1137,23 @@ value. When the next client completes building the body, any existing partial body transmission to the CoAP server is terminated and the new body representation transmission starts with a new Request-Tag value. Note that it cannot be assumed that the proxy will always receive a complete body from a client. A proxy that supports Q-Block2 Option MUST be prepared to receive a GET or similar request indicating one or more missing blocks. The proxy will serve from its cache the missing blocks that are available in its cache in the same way a server would send all the appropriate - Q-Block2 responses. If the cache key matching body is not available - in the cache, the proxy MUST request the entire body from the CoAP - server using the information in the cache key. + Q-Block2 responses. If a body matching the cache key is not + available in the cache, the proxy MUST request the entire body from + the CoAP server using the information in the cache key. How long a CoAP endpoint (or proxy) keeps the body in its cache is implementation specific (e.g., it may be based on Max-Age). 9. HTTP-Mapping Considerations As a reminder, the basic normative requirements on HTTP/CoAP mappings are defined in Section 10 of [RFC7252]. The implementation guidelines for HTTP/CoAP mappings are elaborated in [RFC8075]. @@ -1106,22 +1169,23 @@ to 10 and NON_MAX_RETRANSMIT is set to 4. Figure 2 lists the conventions that are used in the following subsections. T: Token value O: Observe Option value M: Message ID RT: Request-Tag ET: ETag - QB1: Q-Block1 Option values NUM/More/SZX - QB2: Q-Block2 Option values NUM/More/SZX + QB1: Q-Block1 Option values NUM/More/Size + QB2: Q-Block2 Option values NUM/More/Size + Size: Actual block size encoded in SZX \: Trimming long lines [[]]: Comments -->X: Message loss (request) X<--: Message loss (response) ...: Passage of time Payload N: Corresponds to the CoAP message that conveys a block number (N-1) of a given block-wise exchange. Figure 2: Notations Used in the Figures @@ -1150,22 +1214,22 @@ Option. The number of payloads exceeds MAX_PAYLOADS. All the blocks are received by the server. CoAP CoAP Client Server | | +--------->| NON PUT /path M:0x01 T:0xf1 RT=10 QB1:0/1/1024 +--------->| NON PUT /path M:0x02 T:0xf2 RT=10 QB1:1/1/1024 +--------->| [[Payloads 3 - 9 not detailed]] +--------->| NON PUT /path M:0x0a T:0xfa RT=10 QB1:9/1/1024 - [[MAX_PAYLOADS has been reached]] - | [[MAX_PAYLOADS blocks receipt acknowledged by server]] + [[MAX_PAYLOADS_SET has been received]] + | [[MAX_PAYLOADS_SET receipt acknowledged by server]] |<---------+ NON 2.31 M:0x81 T:0xfa +--------->| NON PUT /path M:0x0b T:0xfb RT=10 QB1:10/0/1024 |<---------+ NON 2.04 M:0x82 T:0xfb | ... | Figure 4: Example of MAX_PAYLOADS NON Request with Q-Block1 Option (Without Loss) 10.1.3. Handling MAX_PAYLOADS with Recovery @@ -1174,48 +1238,49 @@ Figure 5. CoAP CoAP Client Server | | +--------->| NON PUT /path M:0x11 T:0xe1 RT=11 QB1:0/1/1024 +--->X | NON PUT /path M:0x12 T:0xe2 RT=11 QB1:1/1/1024 +--------->| [[Payloads 3 - 8 not detailed]] +--------->| NON PUT /path M:0x19 T:0xe9 RT=11 QB1:8/1/1024 +--->X | NON PUT /path M:0x1a T:0xea RT=11 QB1:9/1/1024 - [[MAX_PAYLOADS has been reached]] + [[Some of MAX_PAYLOADS_SET have been received]] | ... | [[NON_TIMEOUT (client) delay expires]] - | [[Client starts sending next set of payloads]] + | [[Client starts sending next MAX_PAYLOAD_SET]] +--->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 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 received payload. The client can then derive the Request- - Tag by matching the token with the sent request. + On seeing a payload from the next MAX_PAYLOAD_SET, the server + realizes that some blocks are missing from the previous + MAX_PAYLOADS_SET and asks for the missing blocks in one go + (Figure 6). It does so by indicating which blocks from the previous + MAX_PAYLOADS_SET have not been received in the data portion of the + response (Section 5). The token used in the response should be the + token that was used in the last 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] | [[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]] + | [[Client continues sending next MAX_PAYLOAD_SET]] +--------->| NON PUT /path M:0x1f T:0xef RT=11 QB1:12/0/1024 | ... | [[NON_RECEIVE_TIMEOUT (server) delay expires]] | [[The server realizes a block is still missing and asks | for the missing one]] |<---------+ NON 4.08 M:0x92 T:0xef [Missing 10] +--------->| NON PUT /path M:0x20 T:0xf0 RT=11 QB1:10/1/1024 |<---------+ NON 2.04 M:0x93 T:0xf0 | ... | @@ -1305,33 +1370,33 @@ 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]] |<---------+ NON 2.05 M:0x8a T:0xf0 O:1234 ET=21 QB2:9/1/1024 - [[MAX_PAYLOADS has been reached]] - | [[MAX_PAYLOADS blocks acknowledged by client using + [[MAX_PAYLOADS_SET has been received]] + | [[MAX_PAYLOADS_SET acknowledged by client using | 'Continue' Q-Block2]] +--------->| NON GET /path M:0x02 T:0xf1 QB2:10/1/1024 |<---------+ NON 2.05 M:0x8b T:0xf0 O:1234 ET=21 QB2:10/0/1024 | ... | | [[Observe triggered]] |<---------+ NON 2.05 M:0x91 T:0xf0 O:1235 ET=22 QB2:0/1/1024 |<---------+ NON 2.05 M:0x92 T:0xf0 O:1235 ET=22 QB2:1/1/1024 |<---------+ [[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 + [[MAX_PAYLOADS_SET has been received]] + | [[MAX_PAYLOADS_SET 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 9: Example of NON Notifications with Q-Block2 Option (Without Loss) 10.2.3. Handling MAX_PAYLOADS with Recovery @@ -1343,28 +1408,27 @@ 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 - 9 not detailed]] | X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024 - [[MAX_PAYLOADS has been reached]] + [[Some of MAX_PAYLOADS_SET have been received]] | ... | [[NON_TIMEOUT (server) delay expires]] - | [[Server sends next set of payloads]] + | [[Server sends next MAX_PAYLOAD_SET]] |<---------+ NON 2.05 M:0xab T:0xf0 O:1236 ET=23 QB2:10/0/1024 - | ... | - [[NON_RECEIVE_TIMEOUT (client) delay expires]] - | [[Client realizes blocks are missing and asks for the + | [[On seeing a payload from the next MAX_PAYLOAD_SET, + | Client realizes blocks are missing and asks for the | missing ones in one go]] +--------->| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\ | | QB2:9/0/1024 | X<---+ NON 2.05 M:0xac T:0xf3 ET=23 QB2:1/1/1024 |<---------+ 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 @@ -1384,35 +1448,35 @@ 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 | X<---+ NON 2.05 M:0xb3 T:0xf0 O:1237 ET=24 QB2:2/1/1024 | X<---+ [[Payloads 4 - 9 not detailed]] | X<---+ NON 2.05 M:0xb9 T:0xf0 O:1237 ET=24 QB2:9/1/1024 - [[MAX_PAYLOADS has been reached]] + [[Some of MAX_PAYLOADS_SET have been received]] | ... | [[NON_TIMEOUT (server) delay expires]] - | [[Server sends next set of payloads]] + | [[Server sends next MAX_PAYLOAD_SET]] | X<---+ NON 2.05 M:0xba T:0xf0 O:1237 ET=24 QB2:10/0/1024 | ... | [[NON_RECEIVE_TIMEOUT (client) delay expires]] | [[Client realizes blocks are missing and asks for the | missing ones in one go by setting the M bit]] +--------->| NON GET /path M:0x06 T:0xf5 QB2:2/1/1024 |<---------+ NON 2.05 M:0xbb T:0xf5 ET=24 QB2:2/1/1024 |<---------+ [[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' + [[MAX_PAYLOADS_SET has been received]] + | [[MAX_PAYLOADS_SET 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 11: Example of NON Notifications with Q-Block2 Option (Blocks Recovery with M bit Set) 10.3. Q-Block1 and Q-Block2 Options @@ -1450,50 +1514,55 @@ (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 - [[MAX_PAYLOADS has been reached]] - | [[MAX_PAYLOADS blocks receipt acknowledged by server]] + [[MAX_PAYLOADS_SET has been received]] + | [[MAX_PAYLOADS_SET acknowledged by server]] |<---------+ NON 2.31 M:0x80 T:0xa9 +--------->| NON FETCH /path M:0x3a T:0xaa O:0 RT=10 QB1:10/0/1024 |<---------+ NON 2.05 M:0x81 T:0xaa O:1334 ET=21 QB2:0/1/1024 |<---------+ NON 2.05 M:0x82 T:0xaa O:1334 ET=21 QB2:1/1/1024 |<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ NON 2.05 M:0x8a T:0xaa O:1334 ET=21 QB2:9/1/1024 - [[MAX_PAYLOADS has been reached]] - | [[MAX_PAYLOADS blocks acknowledged by client using + [[MAX_PAYLOADS_SET has been received]] + | [[MAX_PAYLOADS_SET acknowledged by client using | 'Continue' Q-Block2]] +--------->| NON FETCH /path M:0x3b T:0xab QB2:10/1/1024 |<---------+ NON 2.05 M:0x8b T:0xaa O:1334 ET=21 QB2:10/0/1024 | ... | | [[Observe triggered]] |<---------+ NON 2.05 M:0x8c T:0xaa O:1335 ET=22 QB2:0/1/1024 |<---------+ NON 2.05 M:0x8d T:0xaa O:1335 ET=22 QB2:1/1/1024 |<---------+ [[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 + [[MAX_PAYLOADS_SET has been received]] + | [[MAX_PAYLOADS_SET 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 13: Example of NON FETCH with Q-Block1 and Q-Block2 Options (Without Loss) + Note that as 'Continue' was used, the server continues to use the + same token (0xaa) since the 'Continue' is not being used as a request + for a new set of packets, but rather is being used to instruct the + server to continue its transmission (Section 7.2). + 10.3.3. Handling Recovery Consider now a scenario where some blocks are lost in 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 @@ -1584,22 +1653,22 @@ OSCORE provides end-to-end protection of all information that is not required for proxy operations and requires that a security context is set up (Section 3.1 of [RFC8613]). It can be trusted that the source endpoint is legitimate even if NoSec security mode is used. However, an intermediary node can modify the unprotected outer Q-Block1 and/or Q-Block2 Options to cause a Q-Block transfer to fail or keep requesting all the blocks by setting the M bit and, thus, causing attack amplification. As discussed in Section 12.1 of [RFC8613], applications need to consider that certain message fields and messages types are not protected end-to-end and may be spoofed or - manipulated. It is NOT RECOMMENDED that the NoSec security mode is - used if the Q-Block1 and Q-Block2 Options are to be used. + manipulated. Therefore, it is NOT RECOMMENDED to use the NoSec + security mode if either the Q-Block1 or Q-Block2 Options is used. Security considerations related to the use of Request-Tag are discussed in Section 5 of [I-D.ietf-core-echo-request-tag]. 12. IANA Considerations RFC Editor Note: Please replace [RFCXXXX] with the RFC number to be assigned to this document. 12.1. CoAP Option Numbers Registry @@ -1681,23 +1750,23 @@ o Reference: [RFCXXXX] This document suggests 272 (TBA3) as a value to be assigned for the new content format number. 13. References 13.1. Normative References [I-D.ietf-core-echo-request-tag] - Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, - Request-Tag, and Token Processing", draft-ietf-core-echo- - request-tag-11 (work in progress), November 2020. + Amsuess, C., Mattsson, J. P., and G. Selander, "CoAP: + Echo, Request-Tag, and Token Processing", draft-ietf-core- + echo-request-tag-12 (work in progress), February 2021. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . @@ -1758,22 +1827,22 @@ core-parameters/core-parameters.xhtml#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-01 (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 + Boucadair, M., Reddy, T., Doron, E., Chen, M., 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] "CoAP Option Numbers", . @@ -1864,21 +1933,21 @@ 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, + If there is likely to be the possibility of transient network 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 19. Client Server | | +--------->| CON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024 @@ -1926,21 +1995,21 @@ or successfully transmitted.]] 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, + If there is likely to be the possibility of transient network losses, then the use of NON should be considered. Appendix B. Examples with Reliable Transports The notations provided in Figure 2 are used in the following subsections. B.1. Q-Block1 Option Let's now consider the use of Q-Block1 Option with a reliable @@ -1952,21 +2021,21 @@ | | +--------->| PUT /path T:0xf0 RT=10 QB1:0/1/1024 +--------->| PUT /path T:0xf1 RT=10 QB1:1/1/1024 +--------->| PUT /path T:0xf2 RT=10 QB1:2/1/1024 +--------->| PUT /path T:0xf3 RT=10 QB1:3/0/1024 |<---------+ 2.04 | | Figure 20: Example of Reliable Request with Q-Block1 Option - If there is likely to be the possibility of network transient losses, + If there is likely to be the possibility of transient network losses, then the use of unreliable transport with NON should be considered. B.2. Q-Block2 Option An example of the use of Q-Block2 Option with a reliable transport is shown in Figure 21. Client Server | | +--------->| GET /path T:0xf0 O:0 QB2:0/1/1024 @@ -1990,21 +2059,24 @@ Acknowledgements Thanks to Achim Kraus, Jim Schaad, and Michael Richardson for their comments. Special thanks to Christian Amsuess, Carsten Bormann, and Marco Tiloca for their suggestions and several reviews, which improved this specification significantly. Thanks to Francesca Palombini for the AD review. - Thanks to Pete Resnick for the Gen-ART review. + Thanks to Pete Resnick for the Gen-ART review, Colin Perkins for the + Tsvart review, and Emmanuel Baccelli for the Iotdir review. Thanks + to Martin Duke, Eric Vyncke, Benjamin Kaduk, Roman Danyliw, and John + Scudder for the IESG review. Some text from [RFC7959] is reused for readers convenience. Authors' Addresses Mohamed Boucadair Orange Rennes 35000 France