draft-ietf-core-new-block-11.txt   draft-ietf-core-new-block-12.txt 
CoRE Working Group M. Boucadair CoRE Working Group M. Boucadair
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track J. Shallow 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 Constrained Application Protocol (CoAP) Block-Wise Transfer Options for
Faster Transmission Faster Transmission
draft-ietf-core-new-block-11 draft-ietf-core-new-block-12
Abstract Abstract
This document specifies alternative Constrained Application Protocol This document specifies alternative Constrained Application Protocol
(CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options.
These options are similar to the CoAP Block1 and Block2 Options These options are similar to, but distinct from, the CoAP Block1 and
defined in RFC 7959, not a replacement for them, but do enable faster Block2 Options defined in RFC 7959. Q-Block1 and Q-Block2 Options
transmission rates for large amounts of data with less packet are not intended to replace Block1 and Block2 Options, but rather
interchanges. Also, Q-Block1 and Q-Block2 Options support faster have the goal of enabling faster transmission rates for large amounts
recovery should any of the blocks get lost in transmission. 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Alternative CoAP Block-Wise Transfer Options . . . . . . . . 4 3. Alternative CoAP Block-Wise Transfer Options . . . . . . . . 5
3.1. CoAP Response Code (4.08) Usage . . . . . . . . . . . . . 6 3.1. CoAP Response Code (4.08) Usage . . . . . . . . . . . . . 7
3.2. Applicability Scope . . . . . . . . . . . . . . . . . . . 6 3.2. Applicability Scope . . . . . . . . . . . . . . . . . . . 7
4. The Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 7 4. The Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 8
4.1. Properties of Q-Block1 and Q-Block2 Options . . . . . . . 7 4.1. Properties of Q-Block1 and Q-Block2 Options . . . . . . . 8
4.2. Structure of Q-Block1 and Q-Block2 Options . . . . . . . 9 4.2. Structure of Q-Block1 and Q-Block2 Options . . . . . . . 10
4.3. Using the Q-Block1 Option . . . . . . . . . . . . . . . . 9 4.3. Using the Q-Block1 Option . . . . . . . . . . . . . . . . 10
4.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 13 4.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 14
4.5. Using Observe Option . . . . . . . . . . . . . . . . . . 16 4.5. Using Observe Option . . . . . . . . . . . . . . . . . . 17
4.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 16 4.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 17
4.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 16 4.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 17
4.8. Using Q-Block2 Option With Multicast . . . . . . . . . . 16 4.8. Using Q-Block2 Option With Multicast . . . . . . . . . . 17
5. The Use of 4.08 (Request Entity Incomplete) Response Code . . 16 5. The Use of 4.08 (Request Entity Incomplete) Response Code . . 17
6. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 18 6. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 19
7. Congestion Control for Unreliable Transports . . . . . . . . 18 7. Congestion Control for Unreliable Transports . . . . . . . . 19
7.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 18 7.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 19
7.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 19 7.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 20
8. Caching Considerations . . . . . . . . . . . . . . . . . . . 22 8. Caching Considerations . . . . . . . . . . . . . . . . . . . 24
9. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 24 9. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 25
10. Examples with Non-confirmable Messages . . . . . . . . . . . 24 10. Examples with Non-confirmable Messages . . . . . . . . . . . 25
10.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . 24 10.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . 26
10.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 24 10.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 26
10.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 25 10.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 26
10.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 25 10.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 26
10.1.4. Handling Recovery with Failure . . . . . . . . . . . 27 10.1.4. Handling Recovery with Failure . . . . . . . . . . . 28
10.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . 27 10.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . 29
10.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 28 10.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 29
10.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 28 10.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 30
10.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 29 10.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 31
10.2.4. Handling Recovery using M-bit Set . . . . . . . . . 30 10.2.4. Handling Recovery using M-bit Set . . . . . . . . . 32
10.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . 31 10.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . 33
10.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 31 10.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 33
10.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 32 10.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 34
10.3.3. Handling Recovery . . . . . . . . . . . . . . . . . 33 10.3.3. Handling Recovery . . . . . . . . . . . . . . . . . 35
11. Security Considerations . . . . . . . . . . . . . . . . . . . 35 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
12.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 36 12.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 38
12.2. Media Type Registration . . . . . . . . . . . . . . . . 36 12.2. Media Type Registration . . . . . . . . . . . . . . . . 38
12.3. CoAP Content-Formats Registry . . . . . . . . . . . . . 37 12.3. CoAP Content-Formats Registry . . . . . . . . . . . . . 39
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 13.1. Normative References . . . . . . . . . . . . . . . . . . 40
13.1. Normative References . . . . . . . . . . . . . . . . . . 38 13.2. Informative References . . . . . . . . . . . . . . . . . 41
13.2. Informative References . . . . . . . . . . . . . . . . . 39 Appendix A. Examples with Confirmable Messages . . . . . . . . . 42
Appendix A. Examples with Confirmable Messages . . . . . . . . . 40 A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 42
A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 40 A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 44
A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 42 Appendix B. Examples with Reliable Transports . . . . . . . . . 46
Appendix B. Examples with Reliable Transports . . . . . . . . . 44 B.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 46
B.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 44 B.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 46
B.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 44 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252], although The Constrained Application Protocol (CoAP) [RFC7252], although
inspired by HTTP, was designed to use UDP instead of TCP. The inspired by HTTP, was designed to use UDP instead of TCP. The
message layer of CoAP over UDP includes support for reliable message layer of CoAP over UDP includes support for reliable
delivery, simple congestion control, and flow control. [RFC7959] delivery, simple congestion control, and flow control. CoAP supports
introduced the CoAP Block1 and Block2 Options to handle data records two message types (Section 1.2 of [RFC7252]): Confirmable (CON) and
that cannot fit in a single IP packet, so not having to rely on IP Non-confirmable (NON) messages. Unlike NON messages, every CON
fragmentation and was further updated by [RFC8323] for use over TCP, message will elect an acknowledgement or a reset.
TLS, and WebSockets.
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 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 synchronously, i.e., each individual block has to be requested. A
CoAP endpoint can only ask for (or send) the next block when the CoAP endpoint can only ask for (or send) the next block when the
transfer of the previous block has completed. Packet transmission transfer of the previous block has completed. Packet transmission
rate, and hence block transmission rate, is controlled by Round Trip rate, and hence block transmission rate, is controlled by Round Trip
Times (RTTs). Times (RTTs).
There is a requirement for these blocks of data to be transmitted at There is a requirement for blocks of data larger than a single IP
higher rates under network conditions where there may be asymmetrical datagram to be transmitted at higher rates under network conditions
transient packet loss (i.e., responses may get dropped). An example where there may be asymmetrical transient packet loss (e.g.,
is when a network is subject to a Distributed Denial of Service responses may get dropped). An example is when a network is subject
(DDoS) attack and there is a need for DDoS mitigation agents relying to a Distributed Denial of Service (DDoS) attack and there is a need
upon CoAP to communicate with each other (e.g., for DDoS mitigation agents relying upon CoAP to communicate with each
[RFC8782][I-D.ietf-dots-telemetry]). As a reminder, [RFC7959] other (e.g., [RFC8782][I-D.ietf-dots-telemetry]). As a reminder,
recommends the use of Confirmable (CON) responses to handle potential
[RFC7959] recommends the use of CON responses to handle potential
packet loss. However, such a recommendation does not work with a 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 This document introduces the CoAP Q-Block1 and Q-Block2 Options which
(Section 3). 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 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers should be familiar with the terms and concepts defined in 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 The terms "payload" and "body" are defined in [RFC7959]. The term
"payload" is thus used for the content of a single CoAP message "payload" is thus used for the content of a single CoAP message
(i.e., a single block being transferred), while the term "body" is (i.e., a single block being transferred), while the term "body" is
used for the entire resource representation that is being transferred used for the entire resource representation that is being transferred
in a block-wise fashion. 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 3. Alternative CoAP Block-Wise Transfer Options
This document introduces the CoAP Q-Block1 and Q-Block2 Options. This document introduces the CoAP Q-Block1 and Q-Block2 Options.
These options are similar in operation to the CoAP Block1 and Block2 These options are designed to work in particular with NON requests
Options, respectively. They are not a replacement for them, but have and responses.
the following benefits:
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 o They can operate in environments where packet loss is highly
asymmetrical. asymmetrical.
o They enable faster transmissions of sets of blocks of data with 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 o They support faster recovery should any of the blocks get lost in
transmission. transmission.
o They support sending an entire body using Non-confirmable (NON) o They support sending an entire body using NON messages without
messages without requiring a response from the peer. requiring an intermediate response from the peer.
There are the following disadvantages over using CoAP Block1 and There are the following disadvantages over using CoAP Block1 and
Block2 Options: Block2 Options:
o Loss of lock-stepping so payloads are not always received in the o Loss of lock-stepping so payloads are not always received in the
correct (block ascending) order. correct (block ascending) order.
o Additional congestion control measures need to be put in place for o Additional congestion control measures need to be put in place for
NON messages (Section 7.2). NON messages (Section 7.2).
o To reduce the transmission times for CON transmission of large o To reduce the transmission times for CON transmission of large
bodies, NSTART needs to be increased from 1, but this affects bodies, NSTART needs to be increased from 1, but this affects
congestion control where other parameters need to be tuned congestion control and incurs a requirement to re-tune other
(Section 4.7 of [RFC7252]). Such tuning is out of scope of this parameters (Section 4.7 of [RFC7252]). Such tuning is out of
document. scope of this document.
o Mixing of NON and CON during requests/responses using Q-Block is o Mixing of NON and CON during requests/responses using Q-Block is
not supported. not supported.
o The Q-Block Options do not support stateless operation/random o The Q-Block Options do not support stateless operation/random
access. access.
o Proxying of Q-Block is limited to caching full representations. o Proxying of Q-Block is limited to caching full representations.
o There is no multicast support. 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 Q-Block1 and Q-Block2 Options can be used instead of Block1 and
Block2 Options when the different transmission properties are Block2 Options when the different transmission properties are
required. If the new options are not supported by a peer, then required. If the new options are not supported by a peer, then
transmissions can fall back to using Block1 and Block2 Options transmissions can fall back to using Block1 and Block2 Options
(Section 4.1). (Section 4.1).
The deviations from Block1 and Block2 Options are specified in The deviations from Block1 and Block2 Options are specified in
Section 4. Pointers to appropriate [RFC7959] sections are provided. Section 4. Pointers to appropriate [RFC7959] sections are provided.
The specification refers to the base CoAP methods defined in The specification refers to the base CoAP methods defined in
skipping to change at page 6, line 36 skipping to change at page 7, line 29
The block-wise transfer specified in [RFC7959] covers the general The block-wise transfer specified in [RFC7959] covers the general
case, but falls short in situations where packet loss is highly case, but falls short in situations where packet loss is highly
asymmetrical. The mechanism specified in this document provides asymmetrical. The mechanism specified in this document provides
roughly similar features to the Block1/Block2 Options. It provides roughly similar features to the Block1/Block2 Options. It provides
additional properties that are tailored towards the intended use case additional properties that are tailored towards the intended use case
of Non-Confirmable transmission. Concretely, this mechanism of Non-Confirmable transmission. Concretely, this mechanism
primarily targets applications such as DDoS Open Threat Signaling primarily targets applications such as DDoS Open Threat Signaling
(DOTS) that cannot use CON responses to handle potential packet loss (DOTS) that cannot use CON responses to handle potential packet loss
and that support application-specific mechanisms to assess whether and that support application-specific mechanisms to assess whether
the remote peer is able to handle the messages sent by a CoAP the remote peer is not overloaded and thus is able to process the
endpoint (e.g., DOTS heartbeats in Section 4.7 of [RFC8782]). 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 The mechanism includes guards to prevent a CoAP agent from
overloading the network by adopting an aggressive sending rate. overloading the network by adopting an aggressive sending rate.
These guards MUST be followed in addition to the existing CoAP These guards MUST be followed in addition to the existing CoAP
congestion control as specified in Section 4.7 of [RFC7252]. See congestion control as specified in Section 4.7 of [RFC7252]. See
Section 7 for more details. Section 7 for more details.
This mechanism is not intended for general CoAP usage, and any use This mechanism is not intended for general CoAP usage, and any use
outside the intended use case should be carefully weighed against the outside the intended use case should be carefully weighed against the
loss of interoperability with generic CoAP applications. It is hoped loss of interoperability with generic CoAP applications. It is hoped
that the experience gained with this mechanism can feed future that the experience gained with this mechanism can feed future
extensions of the block-wise mechanism that will both be generally extensions of the block-wise mechanism that will both be generally
applicable and serve this particular use case. applicable and serve this particular use case.
It is not recommended that these options are used in a NoSec security 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 mode (Section 9 of [RFC7252]) as the source endpoint needs to be
trusted. Using OSCORE [RFC8613] does provide a security context and, trusted. Using OSCORE [RFC8613] does provide a security context and,
hence, a trust of the source endpoint. However, using a NoSec hence, a trust of the source endpoint that prepared the inner OSCORE
security mode may still be inadequate for reasons discussed in content. However, even with OSCORE, using a NoSec security mode with
these options may still be inadequate, for reasons discussed in
Section 11. Section 11.
4. The Q-Block1 and Q-Block2 Options 4. The Q-Block1 and Q-Block2 Options
4.1. Properties of 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 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 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 Table 4 of [RFC7252] (Section 5.10). The C, U, N, and R columns
indicate the properties Critical, UnSafe, NoCacheKey, and Repeatable indicate the properties Critical, UnSafe, NoCacheKey, and Repeatable
skipping to change at page 7, line 42 skipping to change at page 8, line 35
Table 1: CoAP Q-Block1 and Q-Block2 Option Properties Table 1: CoAP Q-Block1 and Q-Block2 Option Properties
The Q-Block1 and Q-Block2 Options can be present in both the request 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 and response messages. The Q-Block1 Option pertains to the request
payload and the Q-Block2 Option pertains to the response payload. payload and the Q-Block2 Option pertains to the response payload.
When the Content-Format Option is present together with the Q-Block1 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 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). (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, The Q-Block1 Option is useful with the payload-bearing, e.g., POST,
PATCH, and iPATCH requests and their responses. PUT, FETCH, PATCH, and iPATCH requests and their responses.
Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and The Q-Block2 Option is useful, e.g., with GET, POST, PUT, FETCH,
iPATCH requests and their payload-bearing responses (2.01, 2.02, PATCH, and iPATCH requests and their payload-bearing responses (2.01,
2.03, 2.04, and 2.05) (Section 5.5 of [RFC7252]). 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 A CoAP endpoint (or proxy) MUST support either both or neither of the
Q-Block1 and Q-Block2 Options. Q-Block1 and Q-Block2 Options.
If Q-Block1 Option is present in a request or Q-Block2 Option in a If the Q-Block1 Option is present in a request or the Q-Block2 Option
response (i.e., in that message to the payload of which it pertains), is returned in a response, this indicates a block-wise transfer and
it indicates a block-wise transfer and describes how this specific describes how this specific block-wise payload forms part of the
block-wise payload forms part of the entire body being transferred. entire body being transferred. If it is present in the opposite
If it is present in the opposite direction, it provides additional direction, it provides additional control on how that payload will be
control on how that payload will be formed or was processed. formed or was processed.
To indicate support for Q-Block2 responses, the CoAP client MUST To indicate support for Q-Block2 responses, the CoAP client MUST
include the Q-Block2 Option in a GET or similar request (FETCH, for 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 example), the Q-Block2 Option in a PUT or similar request (POST, for
Q-Block1 Option in a PUT or similar request so that the server knows example), or the Q-Block1 Option in a PUT or similar request so that
that the client supports this Q-Block functionality should it need to the server knows that the client supports this Q-Block functionality
send back a body that spans multiple payloads. Otherwise, the server should it need to send back a body that spans multiple payloads.
would use the Block2 Option (if supported) to send back a message Otherwise, the server would use the Block2 Option (if supported) to
body that is too large to fit into a single IP packet [RFC7959]. 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 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 triggered by an application (DOTS, for example), etc. Such
considerations are out of the scope of the document. considerations are out of the scope of the document.
Implementation of the Q-Block1 and Q-Block2 Options is intended to be 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 optional. However, when it is present in a CoAP message, it MUST be
processed (or the message rejected). Therefore, Q-Block1 and processed (or the message rejected). Therefore, Q-Block1 and
Q-Block2 Options are identified as Critical options. Q-Block2 Options are identified as Critical options.
With CoAP over UDP, the way a request message is rejected for With CoAP over UDP, the way a request message is rejected for
critical options depends on the message type. A Confirmable message critical options depends on the message type. A Confirmable message
with an unrecognized critical option is rejected with a 4.02 (Bad with an unrecognized critical option is rejected with a 4.02 (Bad
Option) response (Section 5.4.1 of [RFC7252]). A Non-confirmable Option) response (Section 5.4.1 of [RFC7252]). A Non-confirmable
message with an unrecognized critical option is either rejected with 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 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 [RFC7252]). To reliably get a rejection message, it is therefore
REQUIRED that clients use a Confirmable message for determining 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 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 CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option
MUST reject the request or response that uses either option. MUST reject the request or response that uses either option.
The Q-Block2 Option is repeatable when requesting retransmission of The Q-Block2 Option is repeatable when requesting retransmission of
missing blocks, but not otherwise. Except that case, any request missing blocks, but not otherwise. Except that case, any request
carrying multiple Q-Block1 (or Q-Block2) Options MUST be handled carrying multiple Q-Block1 (or Q-Block2) Options MUST be handled
following the procedure specified in Section 5.4.5 of [RFC7252]. following the procedure specified in Section 5.4.5 of [RFC7252].
The Q-Block1 and Q-Block2 Options, like the Block1 and Block2 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). Options, are of both class E and class U for OSCORE processing
The Q-Block1 (or Q-Block2) Option MAY be an Inner or Outer option (Table 2). The Q-Block1 (or Q-Block2) Option MAY be an Inner or
(Section 4.1 of [RFC8613]). The Inner and Outer values are therefore Outer option (Section 4.1 of [RFC8613]). The Inner and Outer values
independent of each other. The Inner option is encrypted and are therefore independent of each other. The Inner option is
integrity protected between clients and servers, and provides message encrypted and integrity protected between clients and servers, and
body identification in case of end-to-end fragmentation of requests. provides message body identification in case of end-to-end
The Outer option is visible to proxies and labels message bodies in fragmentation of requests. The Outer option is visible to proxies
case of hop-by-hop fragmentation of requests. and labels message bodies in case of hop-by-hop fragmentation of
requests.
+--------+-----------------+---+---+ +--------+-----------------+---+---+
| Number | Name | E | U | | Number | Name | E | U |
+========+=================+===+===+ +========+=================+===+===+
| TBA1 | Q-Block1 | x | x | | TBA1 | Q-Block1 | x | x |
| TBA2 | Q-Block2 | x | x | | TBA2 | Q-Block2 | x | x |
+--------+-----------------+---+---+ +--------+-----------------+---+---+
Table 2: OSCORE Protection of Q-Block1 and Q-Block2 Options 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 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 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 the Outer options. Messages that do not adhere with this behavior
MUST be rejected with 4.02 (Bad Option). Q-Block and Block Options 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 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 4.2. Structure of Q-Block1 and Q-Block2 Options
The structure of Q-Block1 and Q-Block2 Options follows the structure The structure of Q-Block1 and Q-Block2 Options follows the structure
defined in Section 2.2 of [RFC7959]. defined in Section 2.2 of [RFC7959].
There is no default value for the Q-Block1 and Q-Block2 Options. 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 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 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 could be given in the option, i.e., it indicates that the current
skipping to change at page 10, line 8 skipping to change at page 11, line 8
4.3. Using the Q-Block1 Option 4.3. Using the Q-Block1 Option
The Q-Block1 Option is used when the client wants to send a large 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 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 iPATCH methods where the data and headers do not fit into a single
packet. packet.
When Q-Block1 Option is used, the client MUST include a Request-Tag 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 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 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 being transferred. The Request-Tag is opaque, but the client MUST
treats it as opaque but the client MUST ensure that it is unique for ensure that it is unique for every different body of transmitted
every different body of transmitted data. data.
Implementation Note: It is suggested that the client treats the Implementation Note: It is suggested that the client treats the
Request-Tag as an unsigned integer of 8 bytes in length. An Request-Tag as an unsigned integer of 8 bytes in length. An
implementation may want to consider limiting this to 4 bytes to implementation may want to consider limiting this to 4 bytes to
reduce packet overhead size. The initial Request-Tag value should reduce packet overhead size. The initial Request-Tag value should
be randomly generated and then subsequently incremented by the be randomly generated and then subsequently incremented by the
client whenever a new body of data is being transmitted between client whenever a new body of data is being transmitted between
peers. peers.
Section 4.6 discusses the use of Size1 Option. Section 4.6 discusses the use of Size1 Option.
For Confirmable transmission, the server continues to acknowledge For Confirmable transmission, the server continues to acknowledge
each packet, but a response is not required (whether separate or each packet, but a response is not required (whether separate or
piggybacked) until successful receipt of the body by the server. For piggybacked) until successful receipt of the body by the server. For
Non-confirmable transmission, no response is required until the Non-confirmable transmission, no response is required until either
successful receipt of the body by the server or some of the payloads the successful receipt of the body by the server or a timer expires
have not arrived after a timeout and a retransmit missing payloads with some of the payloads having not yet arrived. In the latter
response is needed. For reliable transports (e.g., [RFC8323]), a case, a "retransmit missing payloads" response is needed. For
response is not required until successful receipt of the body by the reliable transports (e.g., [RFC8323]), a response is not required
server. until successful receipt of the body by the server.
Each individual message that carries a block of the body is treated Each individual message that carries a block of the body is treated
as a new request (Section 6). as a new request (Section 6).
The client MUST send the payloads with the block numbers increasing, The client MUST send the payloads in order of increasing block
starting from zero, until the body is complete (subject to any number, starting from zero, until the body is complete (subject to
congestion control (Section 7)). Any missing payloads requested by any congestion control (Section 7)). Any missing payloads requested
the server must in addition be separately transmitted with increasing by the server must in addition be separately transmitted with
block numbers. increasing block numbers.
The following Response Codes are used: The following Response Codes are used:
2.01 (Created) 2.01 (Created)
This Response Code indicates successful receipt of the entire body This Response Code indicates successful receipt of the entire body
and that the resource was created. The token used MUST be one of and that the resource was created. The token to use MUST be one
the tokens that were received in a request for this block-wise 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 exchange. However, it is desirable to provide the one used in the
last received request, since that will aid any troubleshooting. last received request, since that will aid any troubleshooting.
The client should then release all of the tokens used for this 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 body. Note that the last received payload might not be the one
the highest block number. with the highest block number.
2.02 (Deleted) 2.02 (Deleted)
This Response Code indicates successful receipt of the entire body This Response Code indicates successful receipt of the entire body
and that the resource was deleted when using POST (Section 5.8.2 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 received in a request for this block-wise exchange. However, it
is desirable to provide the one used in the last received request. is desirable to provide the one used in the last received request.
The client should then release all of the tokens used for this The client should then release all of the tokens used for this
body. body.
2.04 (Changed) 2.04 (Changed)
This Response Code indicates successful receipt of the entire body This Response Code indicates successful receipt of the entire body
and that the resource was updated. The token used MUST be one of and that the resource was updated. The token to use MUST be one
the tokens that were received in a request for this block-wise 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 exchange. However, it is desirable to provide the one used in the
last received request. The client should then release all of the last received request. The client should then release all of the
tokens used for this body. tokens used for this body.
2.05 (Content) 2.05 (Content)
This Response Code indicates successful receipt of the entire This Response Code indicates successful receipt of the entire
FETCH request body (Section 2 of [RFC8132]) and that the FETCH request body (Section 2 of [RFC8132]) and that the
appropriate representation of the resource is being returned. 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 request for this block-wise exchange. However, it is desirable to
provide the one used in the last received request. provide the one used in the last received request.
If the FETCH request includes the Observe Option, then the server If the FETCH request includes the Observe Option, then the server
MUST use the same token as used for the initial response for MUST use the same token as used for the initial response for
returning any Observe triggered responses so that the client can returning any Observe triggered responses so that the client can
match them up. match them up.
The client should then release all of the tokens used for this The client should then release all of the tokens used for this
body unless a resource is being observed. body unless a resource is being observed.
2.31 (Continue) 2.31 (Continue)
This Response Code can be used to indicate that all of the blocks 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 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 be one of the tokens that were received in a request for this
block-wise exchange. However, it is desirable to provide the one block-wise exchange. However, it is desirable to provide the one
used in the last received request. used in the last received request.
A response using this Response Code SHOULD NOT be generated for A response using this Response Code SHOULD NOT be generated for
every received Q-Block1 Option request (Section 7.2). It SHOULD every received Q-Block1 Option request (Section 7.2). It SHOULD
only be generated when all the payload requests are Non- only be generated when all the payload requests are Non-
confirmable and a set of MAX_PAYLOADS payloads have been received confirmable and a MAX_PAYLOADS_SET has been received by the
by the server. More details about the motivations for this server. More details about the motivations for this optimization
optimization are discussed in Section 7.2. are discussed in Section 7.2.
This Response Code SHOULD NOT be generated for CON. This Response Code SHOULD NOT be generated for CON.
4.00 (Bad Request) 4.00 (Bad Request)
This Response Code MUST be returned if the request does not This Response Code MUST be returned if the request does not
include a Request-Tag Option or a Size1 Option but does include a include a Request-Tag Option or a Size1 Option but does include a
Q-Block1 option. Q-Block1 option.
4.02 (Bad Option) 4.02 (Bad Option)
skipping to change at page 12, line 31 skipping to change at page 13, line 31
4.08 (Request Entity Incomplete) 4.08 (Request Entity Incomplete)
As a reminder, this Response Code returned without Content-Type As a reminder, this Response Code returned without Content-Type
"application/missing-blocks+cbor-seq" (Section 12.3) is handled as "application/missing-blocks+cbor-seq" (Section 12.3) is handled as
in Section 2.9.2 [RFC7959]. in Section 2.9.2 [RFC7959].
This Response Code returned with Content-Type "application/ This Response Code returned with Content-Type "application/
missing-blocks+cbor-seq" indicates that some of the payloads are missing-blocks+cbor-seq" indicates that some of the payloads are
missing and need to be resent. The client then retransmits the missing and need to be resent. The client then retransmits the
missing payloads using the same Request-Tag, Size1 and Q-Block1 to individual missing payloads using the same Request-Tag, Size1,
specify the block NUM, SZX, and M bit as appropriate. 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 Request-Tag value to use is determined by taking the token in
the 4.08 (Request Entity Incomplete) response, locating the the 4.08 (Request Entity Incomplete) response, locating the
matching client request, and then using its Request-Tag. matching client request, and then using its Request-Tag.
The token used MUST be one of the tokens that were received in a The token to use in the 4.08 (Request Entity Incomplete) response
request for this block-wise exchange. However, it is desirable to MUST be one of the tokens that were received in a request for this
provide the one used in the last received request. See Section 5 block-wise body exchange. However, it is desirable to provide the
for further information. 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 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 NON_RECEIVE_TIMEOUT (Section 7.2) before sending a 4.08 (Request
Entity Incomplete) response. Entity Incomplete) response.
4.13 (Request Entity Too Large) 4.13 (Request Entity Too Large)
This Response Code can be returned under similar conditions to This Response Code can be returned under similar conditions to
those discussed in Section 2.9.3 of [RFC7959]. those discussed in Section 2.9.3 of [RFC7959].
This Response Code can be returned if there is insufficient space 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 create a response PDU with a block size of 16 bytes (SZX = 0)
to send back all the response options as appropriate. In this to send back all the response options as appropriate. In this
case, the Size1 Option is not included in the response. case, the Size1 Option is not included in the response.
Further considerations related to the transmission timings of 4.08 Further considerations related to the transmission timings of 4.08
(Request Entity Incomplete) and 2.31 (Continue) Response Codes are (Request Entity Incomplete) and 2.31 (Continue) Response Codes are
skipping to change at page 13, line 30 skipping to change at page 14, line 32
absent any local policy, the client MUST "forget" all tracked tokens absent any local policy, the client MUST "forget" all tracked tokens
associated with the body's Request-Tag so that a reset message is associated with the body's Request-Tag so that a reset message is
generated for the invalid token in the 4.08 (Request Entity generated for the invalid token in the 4.08 (Request Entity
Incomplete) response. The server on receipt of the reset message Incomplete) response. The server on receipt of the reset message
SHOULD delete the partial body. SHOULD delete the partial body.
If the server receives a duplicate block with the same Request-Tag, 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 it MUST ignore the payload of the packet, but MUST still respond as
if the block was received for the first time. 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). NON_PARTIAL_TIMEOUT (Section 7.2).
4.4. Using the Q-Block2 Option 4.4. Using the Q-Block2 Option
In a request for any block number, the M bit unset indicates the 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 request is just for that block. If the M bit is set, this has
different meanings based on the NUM value: different meanings based on the NUM value:
NUM is zero: This is a request for the entire body. NUM is zero: This is a request for the entire body.
'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero: This is '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 used to confirm that the current MAX_PAYLOADS_SET (the latest
latest one having block number NUM-1) has been successfully block having block number NUM-1) has been successfully received
received and that, upon receipt of this request, the server can and that, upon receipt of this request, the server can continue to
continue to send the next set of payloads (the first one having send the next MAX_PAYLOADS_SET (the first block having block
block number NUM). This is the 'Continue' Q-Block-2 and number NUM). This is the 'Continue' Q-Block-2 and conceptually
conceptually has the same usage (i.e., continue sending the next has the same usage (i.e., continue sending the next set of data)
set of data) as the use of 2.31 (Continue) for Q-Block1. 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 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 If the request includes multiple Q-Block2 Options and these options
overlap (e.g., combination of M being set (this and later blocks) and overlap (e.g., combination of M being set (this and later blocks) and
being unset (this individual block)) resulting in an individual block being unset (this individual block)) resulting in an individual block
being requested multiple times, the server MUST only send back one being requested multiple times, the server MUST only send back one
instance of that block. This behavior is meant to prevent instance of that block. This behavior is meant to prevent
amplification attacks. amplification attacks.
The payloads sent back from the server as a response MUST all have 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 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 server MUST NOT use the same ETag value for different representations
of a resource. of a resource.
The ETag is opaque, the client still treats it as opaque but the The ETag is opaque, but the server MUST ensure that it is unique for
server MUST ensure that it is unique for every different body of every different body of transmitted data.
transmitted data.
Implementation Note: It is suggested that the server treats the Implementation Note: It is suggested that the server treats the
ETag as an unsigned integer of 8 bytes in length. An ETag as an unsigned integer of 8 bytes in length. An
implementation may want to consider limiting this to 4 bytes to implementation may want to consider limiting this to 4 bytes to
reduce packet overhead size. The initial ETag value should be reduce packet overhead size. The initial ETag value should be
randomly generated and then subsequently incremented by the server randomly generated and then subsequently incremented by the server
whenever a new body of data is being transmitted between peers. whenever a new body of data is being transmitted between peers.
Section 4.6 discusses the use of Size2 Option. Section 4.6 discusses the use of Size2 Option.
The client may elect to request any detected missing blocks or just The client may elect to request any detected missing blocks or just
ignore the partial body. This decision is implementation specific. ignore the partial body. This decision is implementation specific.
The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2) For NON payloads, the client SHOULD wait NON_RECEIVE_TIMEOUT
after the last received payload for NON payloads before issuing a (Section 7.2) after the last received payload before requesting
GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or retransmission of any missing blocks. Retransmission is requested by
more Q-Block2 Options that define the missing blocks with the M bit issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request that
unset. The client MAY set the M bit to request this and later blocks contains one or more Q-Block2 Options that define the missing
from this MAX_PAYLOADS set. Further considerations related to the block(s). Generally the M bit on the Q-Block2 Option(s) SHOULD be
transmission timing for missing requests are discussed in unset, although the M bit MAY be set to request this and later blocks
Section 7.2. 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 The missing block numbers requested by the client MUST have an
increasing block number in each additional Q-Block2 Option with no increasing block number in each additional Q-Block2 Option with no
duplicates. The server SHOULD respond with a 4.00 (Bad Request) to duplicates. The server SHOULD respond with a 4.00 (Bad Request) to
requests not adhering to this behavior. Note that the ordering requests not adhering to this behavior. Note that the ordering
constraint is meant to force the client to check for duplicates and constraint is meant to force the client to check for duplicates and
remove them. This also helps with troubleshooting. remove them. This also helps with troubleshooting.
For Confirmable responses, the client continues to acknowledge each For Confirmable responses, the client continues to acknowledge each
packet. Typically, the server acknowledges the initial request using packet. Typically, the server acknowledges the initial request using
an ACK with the payload, and then sends the subsequent payloads as an ACK with the payload, and then sends the subsequent payloads as
CON responses. The server will detect failure to send a packet, but CON responses. The server will detect failure to send a packet, but
the client can issue, after a MAX_TRANSMIT_SPAN delay, a separate the client can issue, after a MAX_TRANSMIT_SPAN delay, a separate
GET, POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as GET, POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as
needed. needed.
If the client receives a duplicate block with the same ETag, it MUST If the client receives a duplicate block with the same ETag, it MUST
silently ignore the payload. 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 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])), (or its default of 60 seconds (Section 5.6.1 of [RFC7252])),
whichever is the less. On release of the partial body, the client 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 should then release all of the tokens used for this body apart from
resource is being observed. 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 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 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 payload. It can be used in the request if the client wants to check
the freshness of the locally cached body response. the freshness of the locally cached body response.
It is RECOMMENDED that the server maintains a cached copy of the body The server SHOULD maintain a cached copy of the body when using the
when using the Q-Block2 Option to facilitate retransmission of any Q-Block2 Option to facilitate retransmission of any missing payloads.
missing payloads.
If the server detects part way through a body transfer that the If the server detects part way through a body transfer that the
resource data has changed and the server is not maintaining a cached resource data has changed and the server is not maintaining a cached
copy of the old data, then the transmission is terminated. Any copy of the old data, then the transmission is terminated. Any
subsequent missing block requests MUST be responded to using the subsequent missing block requests MUST be responded to using the
latest ETag and Size2 Option values with the updated data. latest ETag and Size2 Option values with the updated data.
If the server responds during a body update with a different ETag If the server responds during a body update with a different ETag
Option value (as the resource representation has changed), then the Option value (as the resource representation has changed), then the
client should treat the partial body with the old ETag as no longer 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 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 notification) with a new ETag to the same client as an additional
response, the client should remove any partially received body held response, the client should remove any partially received body held
for a previous ETag for that resource as it is unlikely the missing for a previous ETag for that resource as it is unlikely the missing
blocks can be retrieved. blocks can be retrieved.
If there is insufficient space to create a response PDU with a block 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 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 appropriate, a 4.13 (Request Entity Too Large) is returned without
skipping to change at page 16, line 25 skipping to change at page 17, line 25
following receipt of the 'Continue' Q-Block2 Option (Section 4.4) by 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 server. If a missing payload is requested by a client, then both
the request and response MUST NOT include the Observe Option. the request and response MUST NOT include the Observe Option.
4.6. Using Size1 and Size2 Options 4.6. Using Size1 and Size2 Options
Section 4 of [RFC7959] defines two CoAP options: Size1 for indicating Section 4 of [RFC7959] defines two CoAP options: Size1 for indicating
the size of the representation transferred in requests and Size2 for the size of the representation transferred in requests and Size2 for
indicating the size of the representation transferred in responses. indicating the size of the representation transferred in responses.
The Size1 or Size2 option values MUST exactly represent the size of For Q-Block1 and Q-Block2 Options, the Size1 or Size2 Option values
the data on the body so that any missing data can easily be MUST exactly represent the size of the data on the body so that any
determined. missing data can easily be determined.
The Size1 Option MUST be used with the Q-Block1 Option when used in a 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 request and MUST be present in all payloads of the request,
the same value. The Size2 Option MUST be used with the Q-Block2 preserving the same value. The Size2 Option MUST be used with the
Option when used in a response and MUST be present in all payloads of Q-Block2 Option when used in a response and MUST be present in all
the response preserving the same value. payloads of the response, preserving the same value.
4.7. Using Q-Block1 and Q-Block2 Options Together 4.7. Using Q-Block1 and Q-Block2 Options Together
The behavior is similar to the one defined in Section 3.3 of The behavior is similar to the one defined in Section 3.3 of
[RFC7959] with Q-Block1 substituted for Block1 and Q-Block2 for [RFC7959] with Q-Block1 substituted for Block1 and Q-Block2 for
Block2. Block2.
4.8. Using Q-Block2 Option With Multicast 4.8. Using Q-Block2 Option With Multicast
Servers MUST ignore multicast requests that contain the Q-Block2 Servers MUST ignore multicast requests that contain the Q-Block2
skipping to change at page 17, line 12 skipping to change at page 18, line 12
"application/missing-blocks+cbor-seq" used to indicate that the "application/missing-blocks+cbor-seq" used to indicate that the
server has not received all of the blocks of the request body that it 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 needs to proceed. Such messages must not be treated by the client as
a fatal error. a fatal error.
Likely causes are the client has not sent all blocks, some blocks Likely causes are the client has not sent all blocks, some blocks
were dropped during transmission, or the client has sent them were dropped during transmission, or the client has sent them
sufficiently long ago that the server has already discarded them. sufficiently long ago that the server has already discarded them.
The data payload of the 4.08 (Request Entity Incomplete) response is 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]. missing block numbers encoded as CBOR unsigned integers [RFC8949].
The missing block numbers MUST be unique in each 4.08 (Request Entity The missing block numbers MUST be unique in each 4.08 (Request Entity
Incomplete) response when created by the server; the client MUST Incomplete) response when created by the server; the client MUST
ignore any duplicates in the same 4.08 (Request Entity Incomplete) ignore any duplicates in the same 4.08 (Request Entity Incomplete)
response. response.
The Content-Format Option (Section 5.10.3 of [RFC7252]) MUST be used 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 in the 4.08 (Request Entity Incomplete) response. It MUST be set to
"application/missing-blocks+cbor-seq" (Section 12.3). "application/missing-blocks+cbor-seq" (Section 12.3).
skipping to change at page 17, line 35 skipping to change at page 18, line 35
follows: follows:
; A notional array, the elements of which are to be used ; A notional array, the elements of which are to be used
; in a CBOR Sequence: ; in a CBOR Sequence:
payload = [+ missing-block-number] payload = [+ missing-block-number]
; A unique block number not received: ; A unique block number not received:
missing-block-number = uint missing-block-number = uint
Figure 1: Structure of the Missing Blocks Payload Figure 1: Structure of the Missing Blocks Payload
The token to use for the response SHOULD be the token that was used It is desirable that the token to use for the response is the token
in the last block number received so far with the same Request-Tag that was used in the last block number received so far with the same
value. Note that the use of any received token with the same Request-Tag value. Note that the use of any received token with the
Request-Tag would be acceptable, but providing the one used in the same Request-Tag would be acceptable, but providing the one used in
last received payload will aid any troubleshooting. The client will the last received payload will aid any troubleshooting. The client
use the token to determine what was the previously sent request to will use the token to determine what was the previously sent request
obtain the Request-Tag value to be used. to obtain the Request-Tag value that was used.
If the size of the 4.08 (Request Entity Incomplete) response packet 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 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 of reported missing blocks MUST be limited so that the response can
single packet. If this is the case, then the server can send fit into a single packet. If this is the case, then the server can
subsequent 4.08 (Request Entity Incomplete) responses containing the send subsequent 4.08 (Request Entity Incomplete) responses containing
missing other blocks on receipt of a new request providing a missing the missing other blocks on receipt of a new request providing a
payload with the same Request-Tag. missing payload with the same Request-Tag.
The missing blocks MUST be reported in ascending order without any The missing blocks MUST be reported in ascending order without any
duplicates. The client SHOULD silently drop 4.08 (Request Entity duplicates. The client SHOULD silently drop 4.08 (Request Entity
Incomplete) responses not adhering with this behavior. Incomplete) responses not adhering with this behavior.
Implementation Note: Consider limiting the number of missing Implementation Note: Consider limiting the number of missing
payloads to MAX_PAYLOADS to minimize congestion control being payloads to MAX_PAYLOADS to minimize congestion control being
needed. The CBOR sequence does not include any array wrapper. needed. The CBOR sequence does not include any array wrapper.
The 4.08 (Request Entity Incomplete) with Content-Type "application/ The 4.08 (Request Entity Incomplete) with Content-Type "application/
skipping to change at page 18, line 46 skipping to change at page 19, line 46
unreliable transport MUST either all be Confirmable or all be Non- unreliable transport MUST either all be Confirmable or all be Non-
confirmable. This is meant to simplify the congestion control confirmable. This is meant to simplify the congestion control
procedure. procedure.
As a reminder, there is no need for CoAP-specific congestion control As a reminder, there is no need for CoAP-specific congestion control
for reliable transports [RFC8323]. for reliable transports [RFC8323].
7.1. Confirmable (CON) 7.1. Confirmable (CON)
Congestion control for CON requests and responses is specified in Congestion control for CON requests and responses is specified in
Section 4.7 of [RFC7252]. For faster transmission rates, NSTART will Section 4.7 of [RFC7252]. In order to benefit from faster
need to be increased from 1. However, the other CON congestion transmission rates, NSTART will need to be increased from 1.
control parameters will need to be tuned to cover this change. This However, the other CON congestion control parameters will need to be
tuning is out of scope of this document as it is expected that all tuned to cover this change. This tuning is not specified in this
requests and responses using Q-Block1 and Q-Block2 will be Non- document, given that the applicability scope of the current
confirmable (Section 3.2). 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 Following the failure to transmit a packet due to packet loss after
further requests for missing data as there will have been significant MAX_TRANSMIT_SPAN time (Section 4.8.2 of [RFC7252]), it is
transmission failure as individual payloads will have failed after implementation specific as to whether there should be any further
MAX_TRANSMIT_SPAN. requests for missing data.
7.2. Non-confirmable (NON) 7.2. Non-confirmable (NON)
This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT, This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT,
NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and
NON_PARTIAL_TIMEOUT primarily for use with NON (Table 3). NON_PARTIAL_TIMEOUT primarily for use with NON (Table 3).
MAX_PAYLOADS should be configurable with a default value of 10. Both MAX_PAYLOADS should be configurable with a default value of 10. Both
CoAP endpoints SHOULD have the same value (otherwise there will be CoAP endpoints SHOULD have the same value (otherwise there will be
transmission delays in one direction) and the value MAY be negotiated transmission delays in one direction) and the value MAY be negotiated
between the endpoints to a common value by using a higher level between the endpoints to a common value by using a higher level
protocol (out of scope of this document). This is the maximum number protocol (out of scope of this document). This is the maximum number
of payloads that can be transmitted at any one time. of payloads that can be transmitted at any one time.
Note: The default value of 10 is chosen for reasons similar to 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 NON_TIMEOUT is the period of delay between sending MAX_PAYLOADS_SET
MAX_PAYLOADS payloads for the same body. By default, NON_TIMEOUT has for the same body. By default, NON_TIMEOUT has the same value as
the same value as ACK_TIMEOUT (Section 4.8 of [RFC7252]). ACK_TIMEOUT (Section 4.8 of [RFC7252]).
NON_RECEIVE_TIMEOUT is the initial maximum time to wait for a missing NON_RECEIVE_TIMEOUT is the initial time to wait for a missing payload
payload before requesting retransmission for the first time. Every before requesting retransmission for the first time. Every time the
time the missing payload is re-requested, the time to wait value missing payload is re-requested, the time to wait value doubles. The
doubles. The time to wait is calculated as: time to wait is calculated as:
Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count - 1)) 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 has a default value of twice NON_TIMEOUT.
NON_RECEIVE_TIMEOUT MUST always be greater than NON_TIMEOUT by at NON_RECEIVE_TIMEOUT MUST always be greater than NON_TIMEOUT by at
least one second so that the sender of the payloads has the 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. receiver times out.
NON_MAX_RETRANSMIT is the maximum number of times a request for the NON_MAX_RETRANSMIT is the maximum number of times a request for the
retransmission of missing payloads can occur without a response from retransmission of missing payloads can occur without a response from
the remote peer. After this occurs, the local endpoint SHOULD the remote peer. After this occurs, the local endpoint SHOULD
consider the body stale, remove any body, and release Tokens and consider the body stale, remove any body, and release Tokens and
Request-Tag on the client (or the ETag on the server). By default, 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 NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT (Section 4.8
of [RFC7252]). of [RFC7252]).
NON_PROBING_WAIT is used to limit the potential wait needed NON_PROBING_WAIT is used to limit the potential wait needed when
calculated when using PROBING_WAIT. NON_PROBING_WAIT has the same using PROBING_RATE. By default, NON_PROBING_WAIT has the same value
value as computed for EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).
NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. 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]). EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).
+---------------------+---------------+ +---------------------+---------------+
| Parameter Name | Default Value | | Parameter Name | Default Value |
+=====================+===============| +=====================+===============|
| MAX_PAYLOADS | 10 | | MAX_PAYLOADS | 10 |
| NON_MAX_RETRANSMIT | 4 | | NON_MAX_RETRANSMIT | 4 |
| NON_TIMEOUT | 2 s | | NON_TIMEOUT | 2 s |
| NON_RECEIVE_TIMEOUT | 4 s | | NON_RECEIVE_TIMEOUT | 4 s |
| NON_PROBING_WAIT | 247 s | | NON_PROBING_WAIT | 247 s |
| NON_PARTIAL_TIMEOUT | 247 s | | NON_PARTIAL_TIMEOUT | 247 s |
+---------------------+---------------+ +---------------------+---------------+
Table 3: Congestion Control Parameters Table 3: Congestion Control Parameters
PROBING_RATE parameter in CoAP indicates the average data rate that The PROBING_RATE parameter in CoAP indicates the average data rate
must not be exceeded by a CoAP endpoint in sending to a peer endpoint that must not be exceeded by a CoAP endpoint in sending to a peer
that does not respond. The single body of blocks will be subjected endpoint that does not respond. A single body will be subjected to
to PROBING_RATE (Section 4.7 of [RFC7252]), not the individual PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets.
packets. If the wait time between sending bodies that are not being If the wait time between sending bodies that are not being responded
responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time
gap time is limited to NON_PROBING_WAIT. is limited to NON_PROBING_WAIT.
Note: For the particular DOTS application, PROBING_RATE and other Note: For the particular DOTS application, PROBING_RATE and other
transmission parameters are negotiated between peers. Even when transmission parameters are negotiated between peers. Even when
not negotiated, the DOTS application uses customized defaults as not negotiated, the DOTS application uses customized defaults as
discussed in Section 4.5.2 of [RFC8782]. Note that MAX_PAYLOADS, discussed in Section 4.5.2 of [RFC8782]. Note that MAX_PAYLOADS,
NON_MAX_RETRANSMIT, and NON_TIMEOUT can be negotiated between DOTS NON_MAX_RETRANSMIT, NON_TIMEOUT, NON_PROBING_WAIT, and
peers as per [I-D.bosh-dots-quick-blocks]. 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 Each NON 4.08 (Request Entity Incomplete) response is subject to
PROBING_RATE. 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. PROBING_RATE.
As the sending of many payloads of a single body may itself cause As the sending of many payloads of a single body may itself cause
congestion, it is RECOMMENDED that after transmission of every set of congestion, it is RECOMMENDED that after transmission of every
MAX_PAYLOADS payloads of a single body, a delay is introduced of MAX_PAYLOADS_SET of a single body, a delay is introduced of
NON_TIMEOUT before sending the next set of payloads to manage NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to manage
potential congestion issues. potential congestion issues.
If the CoAP peer reports at least one payload has not arrived for If the CoAP peer reports that at least one payload has not arrived
each body for at least a 24 hour period and it is known that there for each body for at least a 24-hour period and it is known that
are no other network issues over that period, then the value of there are no other network issues over that period (e.g., DDoS
MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1) and attacks), then the value of MAX_PAYLOADS can be reduced by 1 at a
the situation re-evaluated for another 24 hour period until there is time (to a minimum of 1) and the situation re-evaluated for another
no report of missing payloads under normal operating conditions. The 24-hour period until there is no report of missing payloads under
newly derived value for MAX_PAYLOADS should be used for both ends of normal operating conditions. Following a period of 24 hours where no
this particular CoAP peer link. Note that the CoAP peer will not packet recovery was required, the value of MAX_PAYLOADS can be
know about the MAX_PAYLOADS change until it is reconfigured. As a increased by 1 (but without exceeding the default value) for a
consequence of the two peers having different MAX_PAYLOADS values, a further 24-hour evaluation. The newly derived value for MAX_PAYLOADS
peer may continue indicate that there are some missing payloads as should be used for both ends of this particular CoAP peer link. Note
all of its MAX_PAYLOADS set may not have arrived. How the two peer that the CoAP peer will not know about the MAX_PAYLOADS change until
values for MAX_PAYLOADS are synchronized is out of the scope. 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 The sending of a set of missing blocks of a body is restricted to
MAX_PAYLOADS set of payloads. 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) For Q-Block1 Option, if the server responds with a 2.31 (Continue)
Response Code for the latest payload sent, then the client can Response Code for the latest payload sent, then the client can
continue to send the next set of payloads without any delay. If the continue to send the next MAX_PAYLOADS_SET without any further delay.
server responds with a 4.08 (Request Entity Incomplete) Response If the server responds with a 4.08 (Request Entity Incomplete)
Code, then the missing payloads SHOULD be retransmitted before going Response Code, then the missing payloads SHOULD be retransmitted
into another NON_TIMEOUT delay prior to sending the next set of before going into another NON_TIMEOUT delay prior to sending the next
payloads. set of payloads.
For the server receiving NON Q-Block1 requests, it SHOULD send back a 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 2.31 (Continue) Response Code on receipt of all of the
payloads to prevent the client unnecessarily delaying. If not all of MAX_PAYLOADS_SET to prevent the client unnecessarily delaying. If
the MAX_PAYLOADS payloads were received, the server SHOULD delay for not all of the MAX_PAYLOADS_SET were received, the server SHOULD
NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the
count for a payload) before sending the 4.08 (Request Entity repeat request count for a payload) before sending the 4.08 (Request
Incomplete) Response Code for the missing payload(s). If this is a Entity Incomplete) Response Code for the missing payload(s). If all
repeat for the 2.31 (Continue) response, the server SHOULD send a of the MAX_PAYLOADS_SET were received and a 2.31 (Continue) had been
4.08 (Request Entity Incomplete) response detailing the missing sent, but no more payloads were received for NON_RECEIVE_TIMEOUT
payloads after the block number that would have been indicated in the (exponentially scaled), the server SHOULD send a 4.08 (Request Entity
2.31 (Continue). If the repeat request count for a missing payload Incomplete) response detailing the missing payloads after the block
exceeds NON_MAX_RETRANSMIT, the server SHOULD discard the partial number that was indicated in the sent 2.31 (Continue). If the repeat
body and stop requesting the missing payloads. 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 It is likely that the client will start transmitting the next
MAX_PAYLOADS payloads before the server times out on waiting for the MAX_PAYLOADS_SET before the server times out on waiting for the last
last of the previous MAX_PAYLOADS payloads. On receipt of the first of the previous MAX_PAYLOADS_SET. On receipt of a payload from the
payload from the new set of MAX_PAYLOADS payloads, the server SHOULD next MAX_PAYLOADS_SET, the server SHOULD send a 4.08 (Request Entity
send a 4.08 (Request Entity Incomplete) Response Code indicating any Incomplete) Response Code indicating any missing payloads from any
missing payloads from any previous MAX_PAYLOADS payloads. Upon previous MAX_PAYLOADS_SET. Upon receipt of the 4.08 (Request Entity
receipt of the 4.08 (Request Entity Incomplete) Response Code, the Incomplete) Response Code, the client SHOULD send the missing
client SHOULD send the missing payloads before continuing to send the payloads before continuing to send the remainder of the
remainder of the MAX_PAYLOADS payloads and then go into another MAX_PAYLOADS_SET and then go into another NON_TIMEOUT delay prior to
NON_TIMEOUT delay prior to sending the next set of payloads. sending the next MAX_PAYLOADS_SET.
For the client receiving NON Q-Block2 responses, it SHOULD send a For the client receiving NON Q-Block2 responses, it SHOULD send a
'Continue' Q-Block2 request (Section 4.4) for the next set of 'Continue' Q-Block2 request (Section 4.4) for the next
payloads on receipt of all of the MAX_PAYLOADS payloads to prevent MAX_PAYLOADS_SET on receipt of all of the MAX_PAYLOADS_SET, to
the server unnecessarily delaying. Otherwise the client SHOULD delay prevent the server unnecessarily delaying. Otherwise the client
for NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on
request count for a payload), before sending the request for the the repeat request count for a payload), before sending the request
missing payload(s). If the repeat request count for a missing for the missing payload(s). If the repeat request count for a
payload exceeds NON_MAX_RETRANSMIT, the client SHOULD discard the missing payload exceeds NON_MAX_RETRANSMIT, the client SHOULD discard
partial body and stop requesting the missing payloads. the partial body and stop requesting the missing payloads.
The server SHOULD recognize the 'Continue' Q-Block2 request as a The server SHOULD recognize the 'Continue' Q-Block2 request as a
continue request and just continue the transmission of the body continue request and just continue the transmission of the body
(including Observe Option, if appropriate for an unsolicited (including Observe Option, if appropriate for an unsolicited
response) rather than as a request for the remaining missing blocks. response) rather than as a request for the remaining missing blocks.
It is likely that the server will start transmitting the next set of It is likely that the server will start transmitting the next
MAX_PAYLOADS payloads before the client times out on waiting for the MAX_PAYLOADS_SET before the client times out on waiting for the last
last of the previous MAX_PAYLOADS payloads. Upon receipt of the of the previous MAX_PAYLOADS_SET. Upon receipt of a payload from the
first payload from the new set of MAX_PAYLOADS payloads, the client new MAX_PAYLOADS_SET, the client SHOULD send a request indicating any
SHOULD send a request indicating any missing payloads from any missing payloads from any previous MAX_PAYLOADS_SET. Upon receipt of
previous set of MAX_PAYLOADS payloads. Upon receipt of such request, such request, the server SHOULD send the missing payloads before
the server SHOULD send the missing payloads before continuing to send continuing to send the remainder of the MAX_PAYLOADS_SET and then go
the remainder of the MAX_PAYLOADS payloads and then go into another into another NON_TIMEOUT delay prior to sending the next
NON_TIMEOUT delay prior to sending the next set of payloads. MAX_PAYLOADS_SET.
The client does not need to acknowledge the receipt of the entire The client does not need to acknowledge the receipt of the entire
body. body.
Note: If there is asymmetric traffic loss causing responses to Note: If there is asymmetric traffic loss causing responses to
never get received, a delay of NON_TIMEOUT after every never get received, a delay of NON_TIMEOUT after every
transmission of MAX_PAYLOADS blocks will be observed. The transmission of MAX_PAYLOADS_SET will be observed. The endpoint
endpoint receiving the body is still likely to receive the entire receiving the body is still likely to receive the entire body.
body.
8. Caching Considerations 8. Caching Considerations
Caching block based information is not straight forward in a proxy. Caching block based information is not straight forward in a proxy.
For Q-Block1 and Q-Block2 Options, for simplicity it is expected that For Q-Block1 and Q-Block2 Options, for simplicity it is expected that
the proxy will reassemble the body (using any appropriate recovery the proxy will reassemble the body (using any appropriate recovery
options for packet loss) before passing on the body to the options for packet loss) before passing on the body to the
appropriate CoAP endpoint. This does not preclude an implementation appropriate CoAP endpoint. This does not preclude an implementation
doing a more complex per payload caching, but how to do this is out 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 of the scope of this document. The onward transmission of the body
skipping to change at page 23, line 41 skipping to change at page 24, line 52
value. When the next client completes building the body, any value. When the next client completes building the body, any
existing partial body transmission to the CoAP server is terminated existing partial body transmission to the CoAP server is terminated
and the new body representation transmission starts with a new and the new body representation transmission starts with a new
Request-Tag value. Note that it cannot be assumed that the proxy Request-Tag value. Note that it cannot be assumed that the proxy
will always receive a complete body from a client. will always receive a complete body from a client.
A proxy that supports Q-Block2 Option MUST be prepared to receive a A proxy that supports Q-Block2 Option MUST be prepared to receive a
GET or similar request indicating one or more missing blocks. The GET or similar request indicating one or more missing blocks. The
proxy will serve from its cache the missing blocks that are available 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 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 Q-Block2 responses. If a body matching the cache key is not
in the cache, the proxy MUST request the entire body from the CoAP available in the cache, the proxy MUST request the entire body from
server using the information in the cache key. the CoAP server using the information in the cache key.
How long a CoAP endpoint (or proxy) keeps the body in its cache is 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). implementation specific (e.g., it may be based on Max-Age).
9. HTTP-Mapping Considerations 9. HTTP-Mapping Considerations
As a reminder, the basic normative requirements on HTTP/CoAP mappings As a reminder, the basic normative requirements on HTTP/CoAP mappings
are defined in Section 10 of [RFC7252]. The implementation are defined in Section 10 of [RFC7252]. The implementation
guidelines for HTTP/CoAP mappings are elaborated in [RFC8075]. guidelines for HTTP/CoAP mappings are elaborated in [RFC8075].
skipping to change at page 24, line 30 skipping to change at page 25, line 35
to 10 and NON_MAX_RETRANSMIT is set to 4. to 10 and NON_MAX_RETRANSMIT is set to 4.
Figure 2 lists the conventions that are used in the following Figure 2 lists the conventions that are used in the following
subsections. subsections.
T: Token value T: Token value
O: Observe Option value O: Observe Option value
M: Message ID M: Message ID
RT: Request-Tag RT: Request-Tag
ET: ETag ET: ETag
QB1: Q-Block1 Option values NUM/More/SZX QB1: Q-Block1 Option values NUM/More/Size
QB2: Q-Block2 Option values NUM/More/SZX QB2: Q-Block2 Option values NUM/More/Size
Size: Actual block size encoded in SZX
\: Trimming long lines \: Trimming long lines
[[]]: Comments [[]]: Comments
-->X: Message loss (request) -->X: Message loss (request)
X<--: Message loss (response) X<--: Message loss (response)
...: Passage of time ...: Passage of time
Payload N: Corresponds to the CoAP message that conveys Payload N: Corresponds to the CoAP message that conveys
a block number (N-1) of a given block-wise exchange. a block number (N-1) of a given block-wise exchange.
Figure 2: Notations Used in the Figures Figure 2: Notations Used in the Figures
skipping to change at page 25, line 30 skipping to change at page 26, line 37
Option. The number of payloads exceeds MAX_PAYLOADS. All the blocks Option. The number of payloads exceeds MAX_PAYLOADS. All the blocks
are received by the server. are received by the server.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON PUT /path M:0x01 T:0xf1 RT=10 QB1:0/1/1024 +--------->| 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 +--------->| NON PUT /path M:0x02 T:0xf2 RT=10 QB1:1/1/1024
+--------->| [[Payloads 3 - 9 not detailed]] +--------->| [[Payloads 3 - 9 not detailed]]
+--------->| NON PUT /path M:0x0a T:0xfa RT=10 QB1:9/1/1024 +--------->| NON PUT /path M:0x0a T:0xfa RT=10 QB1:9/1/1024
[[MAX_PAYLOADS has been reached]] [[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS blocks receipt acknowledged by server]] | [[MAX_PAYLOADS_SET receipt acknowledged by server]]
|<---------+ NON 2.31 M:0x81 T:0xfa |<---------+ NON 2.31 M:0x81 T:0xfa
+--------->| NON PUT /path M:0x0b T:0xfb RT=10 QB1:10/0/1024 +--------->| NON PUT /path M:0x0b T:0xfb RT=10 QB1:10/0/1024
|<---------+ NON 2.04 M:0x82 T:0xfb |<---------+ NON 2.04 M:0x82 T:0xfb
| ... | | ... |
Figure 4: Example of MAX_PAYLOADS NON Request with Q-Block1 Option Figure 4: Example of MAX_PAYLOADS NON Request with Q-Block1 Option
(Without Loss) (Without Loss)
10.1.3. Handling MAX_PAYLOADS with Recovery 10.1.3. Handling MAX_PAYLOADS with Recovery
skipping to change at page 26, line 13 skipping to change at page 27, line 13
Figure 5. Figure 5.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON PUT /path M:0x11 T:0xe1 RT=11 QB1:0/1/1024 +--------->| 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 +--->X | NON PUT /path M:0x12 T:0xe2 RT=11 QB1:1/1/1024
+--------->| [[Payloads 3 - 8 not detailed]] +--------->| [[Payloads 3 - 8 not detailed]]
+--------->| NON PUT /path M:0x19 T:0xe9 RT=11 QB1:8/1/1024 +--------->| 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 +--->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]] [[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 +--->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 +--------->| 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 Figure 5: Example of MAX_PAYLOADS NON Request with Q-Block1 Option
(With Loss) (With Loss)
On seeing a payload from the next set of payloads, the server On seeing a payload from the next MAX_PAYLOAD_SET, the server
realizes that some blocks are missing from the previous MAX_PAYLOADS realizes that some blocks are missing from the previous
payloads and asks for the missing blocks in one go (Figure 6). It MAX_PAYLOADS_SET and asks for the missing blocks in one go
does so by indicating which blocks from the previous MAX_PAYLOADS (Figure 6). It does so by indicating which blocks from the previous
payloads have not been received in the data portion of the response. MAX_PAYLOADS_SET have not been received in the data portion of the
The token used in the response should be the token that was used in response (Section 5). The token used in the response should be the
the last received payload. The client can then derive the Request- token that was used in the last received payload. The client can
Tag by matching the token with the sent request. then derive the Request-Tag by matching the token with the sent
request.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
|<---------+ NON 4.08 M:0x91 T:0xec [Missing 1,9] |<---------+ NON 4.08 M:0x91 T:0xec [Missing 1,9]
| [[Client responds with missing payloads]] | [[Client responds with missing payloads]]
+--------->| NON PUT /path M:0x1d T:0xed RT=11 QB1:1/1/1024 +--------->| 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 +--------->| 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 PUT /path M:0x1f T:0xef RT=11 QB1:12/0/1024
| ... | | ... |
[[NON_RECEIVE_TIMEOUT (server) delay expires]] [[NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[The server realizes a block is still missing and asks | [[The server realizes a block is still missing and asks
| for the missing one]] | for the missing one]]
|<---------+ NON 4.08 M:0x92 T:0xef [Missing 10] |<---------+ NON 4.08 M:0x92 T:0xef [Missing 10]
+--------->| NON PUT /path M:0x20 T:0xf0 RT=11 QB1:10/1/1024 +--------->| NON PUT /path M:0x20 T:0xf0 RT=11 QB1:10/1/1024
|<---------+ NON 2.04 M:0x93 T:0xf0 |<---------+ NON 2.04 M:0x93 T:0xf0
| ... | | ... |
skipping to change at page 29, line 13 skipping to change at page 31, line 13
experienced. experienced.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024 +--------->| 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: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 |<---------+ NON 2.05 M:0x82 T:0xf0 O:1234 ET=21 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0x8a T:0xf0 O:1234 ET=21 QB2:9/1/1024 |<---------+ NON 2.05 M:0x8a T:0xf0 O:1234 ET=21 QB2:9/1/1024
[[MAX_PAYLOADS has been reached]] [[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS blocks acknowledged by client using | [[MAX_PAYLOADS_SET acknowledged by client using
| 'Continue' Q-Block2]] | 'Continue' Q-Block2]]
+--------->| NON GET /path M:0x02 T:0xf1 QB2:10/1/1024 +--------->| 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 |<---------+ NON 2.05 M:0x8b T:0xf0 O:1234 ET=21 QB2:10/0/1024
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0x91 T:0xf0 O:1235 ET=22 QB2:0/1/1024 |<---------+ 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 |<---------+ NON 2.05 M:0x92 T:0xf0 O:1235 ET=22 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0x9a T:0xf0 O:1235 ET=22 QB2:9/1/1024 |<---------+ NON 2.05 M:0x9a T:0xf0 O:1235 ET=22 QB2:9/1/1024
[[MAX_PAYLOADS has been reached]] [[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS blocks acknowledged by client using | [[MAX_PAYLOADS_SET acknowledged by client using
| 'Continue' Q-Block2]] | 'Continue' Q-Block2]]
+--------->| NON GET /path M:0x03 T:0xf2 QB2:10/1/1024 +--------->| 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 |<---------+ NON 2.05 M:0x9b T:0xf0 O:1235 ET=22 QB2:10/0/1024
[[Body has been received]] [[Body has been received]]
| ... | | ... |
Figure 9: Example of NON Notifications with Q-Block2 Option (Without Figure 9: Example of NON Notifications with Q-Block2 Option (Without
Loss) Loss)
10.2.3. Handling MAX_PAYLOADS with Recovery 10.2.3. Handling MAX_PAYLOADS with Recovery
skipping to change at page 30, line 13 skipping to change at page 32, line 13
Options. Options.
CoAP CoAP CoAP CoAP
Client Server Client Server
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0xa1 T:0xf0 O:1236 ET=23 QB2:0/1/1024 |<---------+ 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 | X<---+ NON 2.05 M:0xa2 T:0xf0 O:1236 ET=23 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
| X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024 | 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]] [[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 2.05 M:0xab T:0xf0 O:1236 ET=23 QB2:10/0/1024
| ... | | [[On seeing a payload from the next MAX_PAYLOAD_SET,
[[NON_RECEIVE_TIMEOUT (client) delay expires]] | Client realizes blocks are missing and asks for the
| [[Client realizes blocks are missing and asks for the
| missing ones in one go]] | missing ones in one go]]
+--------->| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\ +--------->| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\
| | QB2:9/0/1024 | | QB2:9/0/1024
| X<---+ NON 2.05 M:0xac T:0xf3 ET=23 QB2:1/1/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 2.05 M:0xad T:0xf3 ET=23 QB2:9/1/1024
| ... | | ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]] [[NON_RECEIVE_TIMEOUT (client) delay expires]]
| [[Client realizes block is still missing and asks for | [[Client realizes block is still missing and asks for
| missing block]] | missing block]]
+--------->| NON GET /path M:0x05 T:0xf4 QB2:1/0/1024 +--------->| NON GET /path M:0x05 T:0xf4 QB2:1/0/1024
skipping to change at page 31, line 5 skipping to change at page 33, line 5
Figure 10: Example of NON Notifications with Q-Block2 Option (Blocks Figure 10: Example of NON Notifications with Q-Block2 Option (Blocks
Recovery) Recovery)
10.2.4. Handling Recovery using M-bit Set 10.2.4. Handling Recovery using M-bit Set
Figure 11 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 the first two notification blocks reach the client. In order to
retrieve the missing blocks, the client sends a request with a single retrieve the missing blocks, the client sends a request with a single
Q-Block2 Option with the M bit set. Q-Block2 Option with the M bit set.
CoAP CoAP CoAP CoAP
Client Server Client Server
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0xb1 T:0xf0 O:1237 ET=24 QB2:0/1/1024 |<---------+ 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 |<---------+ 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<---+ NON 2.05 M:0xb3 T:0xf0 O:1237 ET=24 QB2:2/1/1024
| X<---+ [[Payloads 4 - 9 not detailed]] | X<---+ [[Payloads 4 - 9 not detailed]]
| X<---+ NON 2.05 M:0xb9 T:0xf0 O:1237 ET=24 QB2:9/1/1024 | 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]] [[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 | X<---+ NON 2.05 M:0xba T:0xf0 O:1237 ET=24 QB2:10/0/1024
| ... | | ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]] [[NON_RECEIVE_TIMEOUT (client) delay expires]]
| [[Client realizes blocks are missing and asks for the | [[Client realizes blocks are missing and asks for the
| missing ones in one go by setting the M bit]] | missing ones in one go by setting the M bit]]
+--------->| NON GET /path M:0x06 T:0xf5 QB2:2/1/1024 +--------->| NON GET /path M:0x06 T:0xf5 QB2:2/1/1024
|<---------+ NON 2.05 M:0xbb T:0xf5 ET=24 QB2:2/1/1024 |<---------+ NON 2.05 M:0xbb T:0xf5 ET=24 QB2:2/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0xc2 T:0xf5 ET=24 QB2:9/1/1024 |<---------+ NON 2.05 M:0xc2 T:0xf5 ET=24 QB2:9/1/1024
[[MAX_PAYLOADS has been reached]] [[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS acknowledged by client using 'Continue' | [[MAX_PAYLOADS_SET acknowledged by client using 'Continue'
| Q-Block2]] | Q-Block2]]
+--------->| NON GET /path M:0x87 T:0xf6 QB2:10/1/1024 +--------->| 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 |<---------+ NON 2.05 M:0xc3 T:0xf0 O:1237 ET=24 QB2:10/0/1024
[[Body has been received]] [[Body has been received]]
| ... | | ... |
Figure 11: 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) Recovery with M bit Set)
10.3. Q-Block1 and Q-Block2 Options 10.3. Q-Block1 and Q-Block2 Options
10.3.1. A Simple Example 10.3.1. A Simple Example
Figure 12 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 Q-Block2 Options along with an Observe Option. No loss is
skipping to change at page 33, line 12 skipping to change at page 35, line 12
(11) payloads in both directions which exceeds MAX_PAYLOADS. There (11) payloads in both directions which exceeds MAX_PAYLOADS. There
is no loss experienced. is no loss experienced.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON FETCH /path M:0x30 T:0xa0 O:0 RT=10 QB1:0/1/1024 +--------->| 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 +--------->| NON FETCH /path M:0x31 T:0xa1 O:0 RT=10 QB1:1/1/1024
+--------->| [[Payloads 3 - 9 not detailed]] +--------->| [[Payloads 3 - 9 not detailed]]
+--------->| NON FETCH /path M:0x39 T:0xa9 O:0 RT=10 QB1:9/1/1024 +--------->| NON FETCH /path M:0x39 T:0xa9 O:0 RT=10 QB1:9/1/1024
[[MAX_PAYLOADS has been reached]] [[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS blocks receipt acknowledged by server]] | [[MAX_PAYLOADS_SET acknowledged by server]]
|<---------+ NON 2.31 M:0x80 T:0xa9 |<---------+ NON 2.31 M:0x80 T:0xa9
+--------->| NON FETCH /path M:0x3a T:0xaa O:0 RT=10 QB1:10/0/1024 +--------->| 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: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 |<---------+ NON 2.05 M:0x82 T:0xaa O:1334 ET=21 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0x8a T:0xaa O:1334 ET=21 QB2:9/1/1024 |<---------+ NON 2.05 M:0x8a T:0xaa O:1334 ET=21 QB2:9/1/1024
[[MAX_PAYLOADS has been reached]] [[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS blocks acknowledged by client using | [[MAX_PAYLOADS_SET acknowledged by client using
| 'Continue' Q-Block2]] | 'Continue' Q-Block2]]
+--------->| NON FETCH /path M:0x3b T:0xab QB2:10/1/1024 +--------->| 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 |<---------+ NON 2.05 M:0x8b T:0xaa O:1334 ET=21 QB2:10/0/1024
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0x8c T:0xaa O:1335 ET=22 QB2:0/1/1024 |<---------+ 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 |<---------+ NON 2.05 M:0x8d T:0xaa O:1335 ET=22 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0x95 T:0xaa O:1335 ET=22 QB2:9/1/1024 |<---------+ NON 2.05 M:0x95 T:0xaa O:1335 ET=22 QB2:9/1/1024
[[MAX_PAYLOADS has been reached]] [[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS blocks acknowledged by client using | [[MAX_PAYLOADS_SET acknowledged by client using
| 'Continue' Q-Block2]] | 'Continue' Q-Block2]]
+--------->| NON FETCH /path M:0x3c T:0xac QB2:10/1/1024 +--------->| 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 |<---------+ NON 2.05 M:0x96 T:0xaa O:1335 ET=22 QB2:10/0/1024
[[Body has been received]] [[Body has been received]]
| ... | | ... |
Figure 13: 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) (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 10.3.3. Handling Recovery
Consider now a scenario where some blocks are lost in transmission as Consider now a scenario where some blocks are lost in transmission as
illustrated in Figure 14. illustrated in Figure 14.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON FETCH /path M:0x50 T:0xc0 O:0 RT=31 QB1:0/1/1024 +--------->| 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:0x51 T:0xc1 O:0 RT=31 QB1:1/1/1024
skipping to change at page 36, line 10 skipping to change at page 38, line 10
OSCORE provides end-to-end protection of all information that is not OSCORE provides end-to-end protection of all information that is not
required for proxy operations and requires that a security context is 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 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, endpoint is legitimate even if NoSec security mode is used. However,
an intermediary node can modify the unprotected outer Q-Block1 and/or 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 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 requesting all the blocks by setting the M bit and, thus, causing
attack amplification. As discussed in Section 12.1 of [RFC8613], attack amplification. As discussed in Section 12.1 of [RFC8613],
applications need to consider that certain message fields and applications need to consider that certain message fields and
messages types are not protected end-to-end and may be spoofed or messages types are not protected end-to-end and may be spoofed or
manipulated. It is NOT RECOMMENDED that the NoSec security mode is manipulated. Therefore, it is NOT RECOMMENDED to use the NoSec
used if the Q-Block1 and Q-Block2 Options are to be used. security mode if either the Q-Block1 or Q-Block2 Options is used.
Security considerations related to the use of Request-Tag are Security considerations related to the use of Request-Tag are
discussed in Section 5 of [I-D.ietf-core-echo-request-tag]. discussed in Section 5 of [I-D.ietf-core-echo-request-tag].
12. IANA Considerations 12. IANA Considerations
RFC Editor Note: Please replace [RFCXXXX] with the RFC number to be RFC Editor Note: Please replace [RFCXXXX] with the RFC number to be
assigned to this document. assigned to this document.
12.1. CoAP Option Numbers Registry 12.1. CoAP Option Numbers Registry
skipping to change at page 38, line 18 skipping to change at page 40, line 18
o Reference: [RFCXXXX] o Reference: [RFCXXXX]
This document suggests 272 (TBA3) as a value to be assigned for the This document suggests 272 (TBA3) as a value to be assigned for the
new content format number. new content format number.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-core-echo-request-tag] [I-D.ietf-core-echo-request-tag]
Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, Amsuess, C., Mattsson, J. P., and G. Selander, "CoAP:
Request-Tag, and Token Processing", draft-ietf-core-echo- Echo, Request-Tag, and Token Processing", draft-ietf-core-
request-tag-11 (work in progress), November 2020. echo-request-tag-12 (work in progress), February 2021.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
skipping to change at page 39, line 47 skipping to change at page 41, line 47
core-parameters/core-parameters.xhtml#content-formats>. core-parameters/core-parameters.xhtml#content-formats>.
[I-D.bosh-dots-quick-blocks] [I-D.bosh-dots-quick-blocks]
Boucadair, M. and J. Shallow, "Distributed Denial-of- Boucadair, M. and J. Shallow, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Signal Channel Service Open Threat Signaling (DOTS) Signal Channel
Configuration Attributes for Faster Block Transmission", Configuration Attributes for Faster Block Transmission",
draft-bosh-dots-quick-blocks-01 (work in progress), draft-bosh-dots-quick-blocks-01 (work in progress),
January 2021. January 2021.
[I-D.ietf-dots-telemetry] [I-D.ietf-dots-telemetry]
Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c., Boucadair, M., Reddy, T., Doron, E., Chen, M., and J.
and J. Shallow, "Distributed Denial-of-Service Open Threat Shallow, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15 Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15
(work in progress), December 2020. (work in progress), December 2020.
[IANA-MediaTypes] [IANA-MediaTypes]
IANA, "Media Types", IANA, "Media Types",
<https://www.iana.org/assignments/media-types>. <https://www.iana.org/assignments/media-types>.
[Options] "CoAP Option Numbers", <https://www.iana.org/assignments/ [Options] "CoAP Option Numbers", <https://www.iana.org/assignments/
core-parameters/core-parameters.xhtml#option-numbers>. core-parameters/core-parameters.xhtml#option-numbers>.
skipping to change at page 42, line 11 skipping to change at page 44, line 11
Figure 18: Example of CON Request with Q-Block1 Option (Blocks Figure 18: Example of CON Request with Q-Block1 Option (Blocks
Recovery) Recovery)
It is up to the implementation as to whether the application process It is up to the implementation as to whether the application process
stops trying to send this particular body of data on reaching stops trying to send this particular body of data on reaching
MAX_RETRANSMIT for any payload, or separately tries to initiate the MAX_RETRANSMIT for any payload, or separately tries to initiate the
new transmission of the payloads that have not been acknowledged new transmission of the payloads that have not been acknowledged
under these adverse traffic conditions. 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. then the use of NON should be considered.
A.2. Q-Block2 Option A.2. Q-Block2 Option
An example of the use of Q-Block2 Option with Confirmable messages is An example of the use of Q-Block2 Option with Confirmable messages is
shown in Figure 19. shown in Figure 19.
Client Server Client Server
| | | |
+--------->| CON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024 +--------->| CON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024
skipping to change at page 44, line 11 skipping to change at page 46, line 11
or successfully transmitted.]] or successfully transmitted.]]
Figure 19: 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 It is up to the implementation as to whether the application process
stops trying to send this particular body of data on reaching stops trying to send this particular body of data on reaching
MAX_RETRANSMIT for any payload, or separately tries to initiate the MAX_RETRANSMIT for any payload, or separately tries to initiate the
new transmission of the payloads that have not been acknowledged new transmission of the payloads that have not been acknowledged
under these adverse traffic conditions. 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. then the use of NON should be considered.
Appendix B. Examples with Reliable Transports Appendix B. Examples with Reliable Transports
The notations provided in Figure 2 are used in the following The notations provided in Figure 2 are used in the following
subsections. subsections.
B.1. Q-Block1 Option B.1. Q-Block1 Option
Let's now consider the use of Q-Block1 Option with a reliable Let's now consider the use of Q-Block1 Option with a reliable
skipping to change at page 44, line 37 skipping to change at page 46, line 37
| | | |
+--------->| PUT /path T:0xf0 RT=10 QB1:0/1/1024 +--------->| PUT /path T:0xf0 RT=10 QB1:0/1/1024
+--------->| PUT /path T:0xf1 RT=10 QB1:1/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:0xf2 RT=10 QB1:2/1/1024
+--------->| PUT /path T:0xf3 RT=10 QB1:3/0/1024 +--------->| PUT /path T:0xf3 RT=10 QB1:3/0/1024
|<---------+ 2.04 |<---------+ 2.04
| | | |
Figure 20: Example of Reliable Request with Q-Block1 Option 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. then the use of unreliable transport with NON should be considered.
B.2. Q-Block2 Option B.2. Q-Block2 Option
An example of the use of Q-Block2 Option with a reliable transport is An example of the use of Q-Block2 Option with a reliable transport is
shown in Figure 21. shown in Figure 21.
Client Server Client Server
| | | |
+--------->| GET /path T:0xf0 O:0 QB2:0/1/1024 +--------->| GET /path T:0xf0 O:0 QB2:0/1/1024
skipping to change at page 45, line 35 skipping to change at page 47, line 35
Acknowledgements Acknowledgements
Thanks to Achim Kraus, Jim Schaad, and Michael Richardson for their Thanks to Achim Kraus, Jim Schaad, and Michael Richardson for their
comments. comments.
Special thanks to Christian Amsuess, Carsten Bormann, and Marco Special thanks to Christian Amsuess, Carsten Bormann, and Marco
Tiloca for their suggestions and several reviews, which improved this Tiloca for their suggestions and several reviews, which improved this
specification significantly. Thanks to Francesca Palombini for the specification significantly. Thanks to Francesca Palombini for the
AD review. 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. Some text from [RFC7959] is reused for readers convenience.
Authors' Addresses Authors' Addresses
Mohamed Boucadair Mohamed Boucadair
Orange Orange
Rennes 35000 Rennes 35000
France France
 End of changes. 100 change blocks. 
401 lines changed or deleted 473 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/