draft-ietf-core-new-block-03.txt   draft-ietf-core-new-block-04.txt 
CORE M. Boucadair CORE M. Boucadair
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track J. Shallow Intended status: Standards Track J. Shallow
Expires: June 25, 2021 December 22, 2020 Expires: July 10, 2021 January 6, 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-03 draft-ietf-core-new-block-04
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, not These options are similar to the CoAP Block1 and Block2 Options, not
a replacement for them, but do enable faster transmission rates for a replacement for them, but do enable faster transmission rates for
large amounts of data with less packet interchanges as well as large amounts of data with less packet interchanges as well as
supporting faster recovery should any of the blocks get lost in supporting faster recovery should any of the blocks get lost in
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 June 25, 2021. This Internet-Draft will expire on July 10, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Alternative CoAP Block-Wise Transfer Options . . . . . . 3 1.1. Alternative CoAP Block-Wise Transfer Options . . . . . . 3
1.2. Updated CoAP Response Code (4.08) . . . . . . . . . . . . 4 1.2. CoAP Response Code (4.08) Usage . . . . . . . . . . . . . 5
1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 5 1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. The Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 6 3. The Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 6
3.1. Properties of Q-Block1 and Q-Block2 Options . . . . . . . 6 3.1. Properties of Q-Block1 and Q-Block2 Options . . . . . . . 6
3.2. Structure of Q-Block1 and Q-Block2 Options . . . . . . . 7 3.2. Structure of Q-Block1 and Q-Block2 Options . . . . . . . 8
3.3. Using the Q-Block1 Option . . . . . . . . . . . . . . . . 8 3.3. Using the Q-Block1 Option . . . . . . . . . . . . . . . . 8
3.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 9 3.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 11
3.5. Working with Observe and Q-Block2 Options . . . . . . . . 11 3.5. Using Observe and Q-Block2 Options . . . . . . . . . . . 13
3.6. Working with Size1 and Size2 Options . . . . . . . . . . 11 3.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 13
3.7. Use of Q-Block1 and Q-Block2 Options Together . . . . . . 12 3.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 13
4. The Use of 4.08 (Request Entity Incomplete) Response Code . . 12 4. The Use of 4.08 (Request Entity Incomplete) Response Code . . 13
5. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 13 5. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 15
6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 13 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 15
7. Caching Considerations . . . . . . . . . . . . . . . . . . . 14 6.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 15
8. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 15 6.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 15
9. Examples of Selective Block Recovery . . . . . . . . . . . . 15 7. Caching Considerations . . . . . . . . . . . . . . . . . . . 18
9.1. Q-Block1 Option: Non-Confirmable Example . . . . . . . . 16 8. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 20
9.2. Q-Block2 Option: Non-Confirmable Example . . . . . . . . 17 9. Examples of Selective Block Recovery . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9.1. Q-Block1 Option: Non-Confirmable Example . . . . . . . . 20
10.1. New CoAP Options . . . . . . . . . . . . . . . . . . . . 20 9.2. Q-Block2 Option: Non-Confirmable Example . . . . . . . . 21
10.2. New Content Format . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10.1. New CoAP Options . . . . . . . . . . . . . . . . . . . . 24
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 10.2. New Media Type . . . . . . . . . . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.3. New Content Format . . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . 23 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Examples with Confirmable Messages . . . . . . . . . 23 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 24 13.1. Normative References . . . . . . . . . . . . . . . . . . 26
A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 25 13.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Examples with Confirmable Messages . . . . . . . . . 29
A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 29
A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
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. [RFC7959]
introduced the CoAP Block1 and Block2 Options to handle data records introduced the CoAP Block1 and Block2 Options to handle data records
that cannot fit in a single IP packet, so not having to rely on IP that cannot fit in a single IP packet, so not having to rely on IP
fragmentation and was further updated by [RFC8323] for use over TCP, fragmentation and was further updated by [RFC8323] for use over TCP,
TLS, and Websockets. 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 where each block has to be requested and can only ask synchronously where each individual block has to be requested and can
for (or send) the next block when the request for the previous block only ask for (or send) the next block when the request for the
has completed. Packet, and hence block transmission rate, is previous block has completed. Packet, and hence block transmission
controlled by Round Trip Times (RTTs). rate, is controlled by Round Trip Times (RTTs).
There is a requirement for these blocks of data to be transmitted at There is a requirement for these blocks of data to be transmitted at
higher rates under network conditions where there may be asymmetrical higher rates under network conditions where there may be asymmetrical
transient packet loss. An example is when a network is subject to a transient packet loss (i.e., responses may get dropped). An example
Distributed Denial of Service (DDoS) attack and there is a need for is when a network is subject to a Distributed Denial of Service
DDoS mitigation agents relying upon CoAP to communicate with each (DDoS) attack and there is a need for DDoS mitigation agents relying
other (e.g., [I-D.ietf-dots-telemetry]). As a reminder, [RFC7959] upon CoAP to communicate with each other (e.g.,
recommends use of Confirmable (CON) responses to handle potential [I-D.ietf-dots-telemetry]). As a reminder, [RFC7959] recommends the
packet loss, which does not work with a flooded pipe DDoS situation. use of Confirmable (CON) responses to handle potential packet loss.
However, such a recommendation does not work with a flooded pipe DDoS
situation.
1.1. Alternative CoAP Block-Wise Transfer Options 1.1. 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 similar in operation to the CoAP Block1 and Block2
Options respectively, they are not a replacement for them, but have Options, respectively. They are not a replacement for them, but have
the following benefits: 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. less 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-confirmable (NON)
without requiring a response from the peer. without requiring a response from the peer.
There are the following disadvantages over using CoAP Block 1 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. o Additional congestion control measures need to be put in place for
NON (Section 6.2).
Using NON messages, the faster transmissions occur as all the Blocks o To reduce the transmission times for CON transmission of large
bodies, NSTART needs to be increased from 1, but this affects
congestion control where other parameters need to be tuned
(Section 4.7 of [RFC7252]). Such tuning is out of scope of this
document.
Using NON messages, the faster transmissions occur as all the blocks
can be transmitted serially (as are IP fragmented packets) without can be transmitted serially (as are IP fragmented packets) without
having to wait for an acknowledgement or next request from the remote having to wait for a response or next request from the remote CoAP
CoAP peer. Recovery of missing Blocks is faster in that multiple peer. Recovery of missing blocks is faster in that multiple missing
missing Blocks can be requested in a single CoAP packet. Even if blocks can be requested in a single CoAP packet. Even if there is
there is asymmetrical packet loss, a body can still be sent and asymmetrical packet loss, a body can still be sent and received by
received by the peer whether the body compromises of a single or the peer whether the body comprises of a single or multiple payloads
multiple payloads assuming no recovery is required. assuming no recovery is required.
Note that the same performance benefits can be applied to Confirmable Note that similar performance benefits can be applied to Confirmable
messages if the value of NSTART is increased from 1 (Section 4.7 of messages if the value of NSTART is increased from 1 (Section 4.7 of
[RFC7252]). However, the asymmetrical packet loss is not a benefit [RFC7252]). However, the use of Confirmable messages will not work
here. Some sample examples with Confirmable messages are provided in if there is asymmetrical packet loss. Some examples with Confirmable
Appendix A. messages are provided in Appendix A.
There is little, if any, benefit of using these options with CoAP There is little, if any, benefit of using these options with CoAP
running over a reliable connection [RFC8323]. In this case, there is running over a reliable connection [RFC8323]. In this case, there is
no differentiation between Confirmable and NON as they are not used. no differentiation between Confirmable and NON as they are not used.
A CoAP endpoint can acknowledge all or a subset of the blocks. A CoAP endpoint can acknowledge all or a subset of the blocks.
Concretely, the receiving CoAP endpoint informs the CoAP sender Concretely, the receiving CoAP endpoint informs the CoAP sender
endpoint either successful receipt or reports on all blocks in the endpoint either successful receipt or reports on all blocks in the
body that have not yet been received. The CoAP sender endpoint will body that have not yet been received. The CoAP sender endpoint will
then retransmit only the blocks that have been lost in transmission. then retransmit only the blocks that have been lost in transmission.
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 respectively when the different transmission semantics Block2 Options when the different transmission properties are
are required. If the option is not supported by a peer, then required. If the new option is not supported by a peer, then
transmissions can fall back to using Block1 and Block2 respectively. transmissions can fall back to using Block1 and Block2 Options,
respectively.
The deviations from Block1 and Block2 Options are specified in The deviations from Block1 and Block2 Options are specified in
Section 3. Pointers to appropriate [RFC7959] sections are provided. Section 3. 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
Section 5.8 of [RFC7252] and the new CoAP methods, FETCH, PATCH, and Section 5.8 of [RFC7252] and the new CoAP methods, FETCH, PATCH, and
iPATCH introduced in [RFC8132]. iPATCH introduced in [RFC8132].
1.2. Updated CoAP Response Code (4.08) Q-Block1 and Q-Block2 Options are designed to work with Non-
confirmable requests and responses, in particular.
This document updates the 4.08 (Request Entity Incomplete) by 1.2. CoAP Response Code (4.08) Usage
defining an additional message format for reporting on payloads using
the Q-Block1 Option that are not received by the server. This document adds a media type for the 4.08 (Request Entity
Incomplete) response defining an additional message format for
reporting on payloads using the Q-Block1 Option that are not received
by the server.
See Section 4 for more details. See Section 4 for more details.
1.3. Applicability Scope 1.3. Applicability Scope
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 additional properties that are tailored towards the intended use case
case. Concretely, this mechanism primarily targets applications such of Non-Confirmable transmission. Concretely, this mechanism
as DDoS Open Threat Signaling (DOTS) that can't use Confirmable (CON) primarily targets applications such as DDoS Open Threat Signaling
responses to handle potential packet loss and that support (DOTS) that can't use Confirmable (CON) responses to handle potential
application-specific mechanisms to assess whether the remote peer is packet loss and that support application-specific mechanisms to
able to handle the messages sent by a CoAP endpoint (e.g., DOTS assess whether the remote peer is able to handle the messages sent by
heartbeats in Section 4.7 of [RFC8782]). 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 6 for more details. Section 6 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
skipping to change at page 6, line 14 skipping to change at page 6, line 31
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.
3. The Q-Block1 and Q-Block2 Options 3. The Q-Block1 and Q-Block2 Options
3.1. Properties of Q-Block1 and Q-Block2 Options 3.1. Properties of Q-Block1 and Q-Block2 Options
The properties of Q-Block1 and Q-Block2 Options are shown in Table 1. The properties of Q-Block1 and Q-Block2 Options are shown in Table 1.
The formatting of this table follows the one used in Table 4 of The formatting of this table follows the one used in Table 4 of
[RFC7252] (Section 5.10). The C, U, N, and R columns indicate the [RFC7252] (Section 5.10). The C, U, N, and R columns indicate the
properties Critical, Unsafe, NoCacheKey, and Repeatable defined in properties Critical, UnSafe, NoCacheKey, and Repeatable defined in
Section 5.4 of [RFC7252]. Only C and U columns are marked for the Section 5.4 of [RFC7252]. Only Critical and UnSafe columns are
Q-Block1 Option. C, U, and R columns are marked for the Q-Block2 marked for the Q-Block1 Option. Critical, UnSafe, and Repeatable
Option. columns are marked for the Q-Block2 Option. As these options are
UnSafe, NoCacheKey has no meaning and so is marked with a dash.
+--------+---+---+---+---+--------------+--------+--------+---------+ +--------+---+---+---+---+--------------+--------+--------+---------+
| Number | C | U | N | R | Name | Format | Length | Default | | Number | C | U | N | R | Name | Format | Length | Default |
+========+===+===+===+===+==============+========+========+=========+ +========+===+===+===+===+==============+========+========+=========+
| TBA1 | x | x | | | Q-Block1 | uint | 0-3 | (none) | | TBA1 | x | x | - | | Q-Block1 | uint | 0-3 | (none) |
| TBA2 | x | x | | x | Q-Block2 | uint | 0-3 | (none) | | TBA2 | x | x | - | x | Q-Block2 | uint | 0-3 | (none) |
+--------+---+---+---+---+--------------+--------+--------+---------+ +--------+---+---+---+---+--------------+--------+--------+---------+
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.
The Content-Format Option applies to the body, not to the payload The Content-Format Option applies to the body, not to the payload
(i.e., it must be the same for all payloads of the same body). (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, PATCH, Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH,
and iPATCH requests and their responses (2.01 and 2.04). PATCH, and iPATCH requests and their responses (2.01 and 2.04).
Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and
iPATCH requests and their payload-bearing responses (2.01, 2.03, iPATCH requests and their payload-bearing responses (2.01, 2.03,
2.04, and 2.05) (Section 5.5 of [RFC7252]). 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.
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, the Q-Block2 include the Q-Block2 Option in a GET or similar request, the Q-Block2
skipping to change at page 7, line 21 skipping to change at page 7, line 40
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.
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 re-transmission 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, are both a class E and a class U in terms of OSCORE Options, are both a class E and a class U in terms of OSCORE
processing (Table 2): The Q-Block1 (or Q-Block2) Option MAY be an processing (Table 2). The Q-Block1 (or Q-Block2) Option MAY be an
Inner or Outer option (see Section 4.1 of [RFC8613]). The Inner and Inner or Outer option (see Section 4.1 of [RFC8613]). The Inner and
Outer values are therefore independent of each other. The Inner Outer values are therefore independent of each other. The Inner
option is encrypted and integrity protected between clients and option is encrypted and integrity protected between clients and
servers, and provides message body identification in case of end-to- servers, and provides message body identification in case of end-to-
end fragmentation of requests. The Outer option is visible to end fragmentation of requests. The Outer option is visible to
proxies and labels message bodies in case of hop-by-hop fragmentation proxies and labels message bodies in case of hop-by-hop fragmentation
of requests. 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: Protection of Q-Block1 and Q-Block2 Options Table 2: OSCORE Protection of Q-Block1 and Q-Block2 Options
3.2. Structure of Q-Block1 and Q-Block2 Options 3.2. Structure of Q-Block1 and Q-Block2 Options
The structure of Q-Block1 and Q-Block2 Options follows the structure 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 8, line 17 skipping to change at page 8, line 36
which would indicate a size of the block (SZX) of 0, and thus a size which would indicate a size of the block (SZX) of 0, and thus a size
value of 16 bytes, there is no specific explicit size implied by the value of 16 bytes, there is no specific explicit size implied by the
absence of the option -- the size is left unspecified. (As for any absence of the option -- the size is left unspecified. (As for any
uint, the explicit value 0 is efficiently indicated by a zero-length uint, the explicit value 0 is efficiently indicated by a zero-length
option; this, therefore, is different in semantics from the absence option; this, therefore, is different in semantics from the absence
of the option). of the option).
3.3. Using the Q-Block1 Option 3.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, PATCH, or iPATCH amount of data to the server using the POST, PUT, FETCH, PATCH, or
methods where the data and headers do not fit into a single packet. iPATCH methods where the data and headers do not fit into a single
packet.
When Q-Block1 Option is used, the client MUST include a single When Q-Block1 Option is used, the client MUST include a Request-Tag
Request-Tag Option [I-D.ietf-core-echo-request-tag]. The Request-Tag Option [I-D.ietf-core-echo-request-tag]. The Request-Tag value MUST
value MUST be the same for all of the blocks in the body of data that be the same for all of the requests for the body of data that is
is being transferred. It is also used to identify a particular block being transferred. It is also used to identify a particular payload
of a body that needs to be re-transmitted. The Request-Tag is opaque of a body that needs to be retransmitted. The Request-Tag is opaque,
in nature, but it is RECOMMENDED that the client treats it as an the server still treats it as opaque but the client SHOULD ensure
unsigned integer of 8 bytes in length. An implementation may want to that it is unique for every different body of transmitted data.
consider limiting this to 4 bytes to reduce packet overhead size.
The server still treats it as an opaque entity. The Request-Tag
value MUST be different for distinct bodies or sets of blocks of data
and SHOULD be incremented whenever a new body of data is being
transmitted between peers. The initial Request-Tag value SHOULD be
randomly generated by the client.
For Confirmable transmission, the server MUST continue to acknowledge Implementation Note: It is suggested that the client treats the
each packet. NSTART will also need to be increased from the default Request-Tag as an unsigned integer of 8 bytes in length. An
(1) to get faster transmission rates. implementation may want to consider limiting this to 4 bytes to
reduce packet overhead size. The initial Request-Tag value should
be randomly generated and then subsequently incremented by the
client whenever a new body of data is being transmitted between
peers.
Section 3.6 discusses the use of Size1 Option.
For Confirmable transmission, the server continues to acknowledge
each packet, but a response is not required (whether separate or
piggybacked) until successful receipt of the body or, if some of the
payloads are sent as Non-confirmable and have not arrived, a
retransmit missing payloads response is needed.
Each individual payload of the body is treated as a new request (see Each individual payload of the body is treated as a new request (see
Section 5). Section 5).
A 2.01 (Created) or 2.04 (Changed) Response Code indicates successful The client MUST send the payloads with the block numbers increasing,
receipt of the entire body. starting from zero, until the body is complete (subject to any
congestion control (Section 6)). Any missing payloads requested by
the server must in addition be separately transmitted with increasing
block numbers.
The 2.31 (Continue) Response is not used in the current version of The following Response Codes are used:
the specification.
A 4.00 (Bad Request) Response Code MUST be returned if the request 2.01 (Created)
does not include a Request-Tag Option but does include a Q-Block1
option.
A 4.02 (Bad Option) Response Code MUST be returned if the server does This Response Code indicates successful receipt of the entire body
not support the Q-Block1 Option. and the resource was created.
A 4.13 (Request Entity Too Large) Response Code can be returned under 2.04 (Changed)
similar conditions to those discussed in Section 2.9.3 of [RFC7959].
A 4.08 (Request Entity Incomplete) Response Code returned without This Response Code indicates successful receipt of the entire body
Content-Type "application/missing-blocks+cbor-seq" (Section 10.2) is and the resource was updated.
handled as in Section 2.9.2 [RFC7959].
A 4.08 (Request Entity Incomplete) Response Code returned with 2.31 (Continue)
Content-Type "application/missing-blocks+cbor-seq" indicates that
some of the payloads are missing and need to be resent. The client This Response Code can be used to indicate that all of the blocks
then re-transmits the missing payloads using the Request-Tag and up to and including the Q-Block1 Option block NUM (all having the
Q-Block1 to specify the block number, SZX, and M bit as appropriate. M bit set) in the response have been successfully received.
The Request-Tag value to use is determined from the payload of the
4.08 (Request Entity Incomplete) Response Code. If the client does A response using this Response Code SHOULD NOT be generated for
not recognize the Request-Tag, the client can ignore this response. every received Q-Block1 Option request. It SHOULD only be
generated when all the payload requests are Non-confirmable and
MAX_PAYLOADS payloads have been received by the server
(Section 6.2).
It SHOULD NOT be generated for CON.
4.00 (Bad Request)
This Response Code MUST be returned if the request does not
include both a Request-Tag Option and a Size1 Option but does
include a Q-Block1 option.
4.02 (Bad Option)
Either this Response Code or a reset message MUST be returned if
the server does not support the Q-Block1 Option.
4.08 (Request Entity Incomplete)
This Response Code returned without Content-Type "application/
missing-blocks+cbor-seq" (Section 10.3) is handled as in
Section 2.9.2 [RFC7959].
This Response Code returned with Content-Type "application/
missing-blocks+cbor-seq" indicates that some of the payloads are
missing and need to be resent. The client then retransmits the
missing payloads using the same Request-Tag, Size1 and Q-Block1 to
specify the block number, SZX, and M bit as appropriate.
The Request-Tag value to use is determined from the token in the
4.08 (Request Entity Incomplete) response and then finding the
matching client request which contains the Request-Tag that is
being used for this Q-Block1 body.
4.13 (Request Entity Too Large)
This Response Code can be returned under similar conditions to
those discussed in Section 2.9.3 of [RFC7959].
This Response Code can be returned if there is insufficient space
to create a response PDU with a block size of 16 bytes (SZX = 0)
to send back all the response options as appropriate. In this
case, the Size1 Option is not included.
If the server has not received all the payloads of a body, but one or If the server has not received all the payloads of a body, but one or
more payloads have been received, it SHOULD wait for up to more NON payloads have been received, it SHOULD wait for up to
MAX_TRANSMIT_SPAN (Section 4.8.2 of [RFC7252]) before sending the NON_RECEIVE_TIMEOUT (Section 6.2) before sending a 4.08 (Request
4.08 (Request Entity Incomplete) Response Code. However, this time Entity Incomplete) response. Further considerations related to the
MAY be reduced to two times ACK_TIMEOUT before sending a 4.08 transmission timings of 4.08 (Request Entity Incomplete) and 2.31
(Request Entity Incomplete) Response Code to cover the situation (Continue) Response Codes are discussed in Section 6.2.
where MAX_PAYLOADS has been triggered by the client causing a break
in transmission.
If the client transmits a new body of data with a new Request-Tag to If a server receives payloads with different Request-Tags for the
the same resource on a server, the server MUST remove any partially same resource, it should continue to process all the bodies as it has
received body held for a previous Request-Tag for that resource. no way of determining which is the latest version, or which body, if
any, the client is terminating the transmission for.
If the client elects to stop the transmission of a complete body, it
SHOULD "forget" all tracked tokens associated with the body's
Request-Tag so that a reset message is generated for the invalid
token in the 4.08 (Request Entity Incomplete) response. The server
on receipt of the reset message SHOULD delete the partial body.
If the server receives a duplicate block with the same Request-Tag, If the server receives a duplicate block with the same Request-Tag,
it SHOULD silently ignore the packet. it SHOULD ignore the payload of the packet, but MUST still respond as
if the block was received for the first time.
A server SHOULD only maintain a partial body (missing payloads) for A server SHOULD only maintain a partial body (missing payloads) for
up to EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). up to NON_PARTIAL_TIMEOUT (Section 6.2).
3.4. Using the Q-Block2 Option 3.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 indicates request is just for that block. If the M bit is set, this indicates
that this is a request for that block and for all of the remaining that this is a request for that block and for all of the remaining
blocks within the body. If the request includes multiple Q-Block2 blocks within the body. If the request includes multiple Q-Block2
Options and these options overlap (e.g., combination of M being set Options and these options overlap (e.g., combination of M being set
(this and all the later blocks) and being unset (this individual (this and all the later blocks) and being unset (this individual
block)) resulting in an individual block being requested multiple block)) resulting in an individual block being requested multiple
times, the server MUST only send back one instance of that block. times, the server MUST only send back one instance of that block.
This behavior is meant to prevent amplification attacks. This behavior is meant to prevent 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 in nature, but it is RECOMMENDED that the server The ETag is opaque, the client still treats it as opaque but the
treats it as an unsigned integer of 8 bytes in length. An server SHOULD ensure that it is unique for every different body of
implementation may want to consider limiting this to 4 bytes to transmitted data.
reduce packet overhead size. The client still treats it as an opaque
entity. The ETag value MUST be different for distinct bodies or sets
of blocks of data and SHOULD be incremented whenever a new body of
data is being transmitted between peers. The initial ETag value
SHOULD be randomly generated by the server.
If the client detects that some of the payloads are missing, the Implementation Note: It is suggested that the server treats the
missing payloads are requested by issuing a new GET, POST, PUT, ETag as an unsigned integer of 8 bytes in length. An
FETCH, PATCH, or iPATCH request that contains one or more Q-Block2 implementation may want to consider limiting this to 4 bytes to
Options that define the missing blocks with the M bit unset. reduce packet overhead size. The initial ETag value should be
randomly generated and then subsequently incremented by the server
whenever a new body of data is being transmitted between peers.
Section 3.6 discusses the use of Size2 Option.
The client may elect to request any detected missing blocks or just
ignore the partial body. This decision is implementation specific.
The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 6.2)
after the last received payload for NON payloads before issuing a
GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or
more Q-Block2 Options that define the missing blocks with the M bit
unset. Further considerations related to the transmission timing for
missing requests are discussed in Section 6.2.
The requested missing block numbers MUST have an increasing block The requested missing block numbers MUST have an increasing block
number in each additional Q-Block2 Option with no duplicates. The number in each additional Q-Block2 Option with no duplicates. The
server SHOULD respond with a 4.00 (Bad Request) to requests not server SHOULD respond with a 4.00 (Bad Request) to requests not
adhering to this behavior. adhering to this behavior.
The ETag Option MUST NOT be used in the request as the server could For Confirmable responses, the client continues to acknowledge each
respond with a 2.03 (Valid Response) with no payload. If the server packet. The server will detect failure to send a packet, but the
responds with a different ETag Option value (as the resource client can issue, after a MAX_TRANSMIT_SPAN delay, a separate GET,
representation has changed), then the client SHOULD drop all the POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as needed.
payloads for the current body that are no longer valid.
The client may elect to request the missing blocks or just ignore the If the client receives a duplicate block with the same ETag, it
partial body. It SHOULD wait for up to MAX_TRANSMIT_SPAN SHOULD silently ignore the packet.
(Section 4.8.2 of [RFC7252]) before issuing a GET, POST, PUT, FETCH,
PATCH, or iPATCH request for the missing blocks. However, this time
MAY be reduced to two times ACK_TIMEOUT before sending the request to
cover the situation where MAX_PAYLOADS has been triggered by the
server causing a break in transmission.
With NON transmission, the client only needs to indicate that some of A client SHOULD only maintain a partial body (missing payloads) for
the payloads are missing by issuing a GET, POST, PUT, FETCH, PATCH, up to NON_PARTIAL_TIMEOUT (Section 6.2) or as defined by the Max-Age
or iPATCH request for the missing blocks. Option (or its default), whichever is the less.
For Confirmable transmission, the client SHOULD continue to The ETag Option should not be used in the request for missing blocks
acknowledge each packet as well as issuing a separate GET, POST, PUT, as the server could respond with a 2.03 (Valid Response) with no
FETCH, PATCH, or iPATCH for the missing blocks. payload. It can be used in the request if the client wants to check
the freshness of the currently cached body response.
If the server transmits a new body of data (e.g., a triggered If the server detects part way through a body transfer that the
Observe) with a new ETag to the same client as an additional resource data has changed and the server is not maintaining a cached
response, the client MUST remove any partially received body held for copy of the old data, then the body response SHOULD be restarted with
a previous ETag. a different ETag Option value. Any subsequent missing block requests
MUST be responded to using the latest ETag Option value.
If the client receives a duplicate block with the same ETag, it If the server responds during a body update with a different ETag
SHOULD silently ignore the packet. Option value (as the resource representation has changed), then the
client should treat the partial body with the old ETag as no longer
being fresh.
A client SHOULD only maintain a partial body (missing payloads) for If the server transmits a new body of data (e.g., a triggered
up to EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) or as defined by Observe) with a new ETag to the same client as an additional
the Max-Age Option, whichever is the less. response, the client should remove any partially received body held
for a previous ETag for that resource as it is unlikely the missing
blocks can be retrieved.
If there is insufficient space to create a response PDU with a block If there is insufficient space to create a response PDU with a block
size of 16 bytes (SZX = 0) to reflect back all the request 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
the Size2 Option. the Size1 Option.
3.5. Working with Observe and Q-Block2 Options 3.5. Using Observe and Q-Block2 Options
As the blocks of the body are sent without waiting for As the blocks of the body are sent without waiting for
acknowledgement of the individual blocks, the Observe value [RFC7641] acknowledgement of the individual blocks, the Observe value [RFC7641]
MUST be the same for all the blocks of the same body. MUST be the same for all the blocks of the same body.
If the client requests missing blocks, this is treated as a new If the client requests missing blocks, this is treated as a new
request. The Observe value may change but MUST still be reported. Request and the Observe Option MUST NOT be included. If the ETag
If the ETag value changes then the previously received partial body value in the response changes, then the previously received partial
should be destroyed and the whole body re-requested. body should be considered as not fresh and the whole body re-
requested.
3.6. Working with Size1 and Size2 Options 3.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 The Size1 or Size2 option values MUST exactly represent the size of
the data on the body so that any missing data can easily be the data on the body so that any missing data can easily be
determined. 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. The Size2 Option MUST be used with the Q-Block2 Option when request. The Size2 Option MUST be used with the Q-Block2 Option when
used in a response. used in a response.
If Size1 or Size2 Options are used, they MUST be used in all payloads If Size1 or Size2 Options are used, they MUST be used in all payloads
of the body and MUST preserve the same value in each of those of the body and MUST preserve the same value in each of those
payloads. payloads.
3.7. Use of Q-Block1 and Q-Block2 Options Together 3.7. Using Q-Block1 and Q-Block2 Options Together
The behavior is similar to the one defined in Section 3.3 of 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. The Use of 4.08 (Request Entity Incomplete) Response Code 4. The Use of 4.08 (Request Entity Incomplete) Response Code
4.08 (Request Entity Incomplete) Response Code has a new Content-Type 4.08 (Request Entity Incomplete) Response Code has a new Content-Type
"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. needs to proceed.
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 The data payload of the 4.08 (Request Entity Incomplete) response is
Code is encoded as a CBOR Sequence [RFC8742]. First is CBOR encoded encoded as a CBOR Sequence [RFC8742]. There are one or more missing
Request-Tag followed by 1 or more missing CBOR encoded missing block CBOR encoded missing block numbers. The missing block numbers MUST
numbers. The missing block numbers MUST be unique in each 4.08 be unique in each 4.08 (Request Entity Incomplete) response when
(Request Entity Incomplete) when created by the server; the client created by the server; the client SHOULD drop any duplicates in the
SHOULD drop any duplicates in the same 4.08 (Request Entity same 4.08 (Request Entity Incomplete) response.
Incomplete) message.
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 Code. It MUST be in the 4.08 (Request Entity Incomplete) response. It MUST be set to
set to "application/missing-blocks+cbor-seq" (see Section 10.2). "application/missing-blocks+cbor-seq" (see Section 10.3).
The Concise Data Definition Language [RFC8610] for the data The Concise Data Definition Language [RFC8610] for the data
describing these missing blocks is as follows: describing these missing blocks is as follows:
; This defines an array, the elements of which are to be used ; This defines an array, the elements of which are to be used
; in a CBOR Sequence: ; in a CBOR Sequence:
payload = [request-tag, + missing-block-number] payload = [+ missing-block-number]
request-tag = bstr
; 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
in the highest block number received payload. The Q-Block1 Option
from the same packet SHOULD be included.
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 missing blocks MUST be limited so that the response can fit into a
single packet. If this is the case, then the server can send single packet. If this is the case, then the server can send
subsequent 4.08 (Request Entity Incomplete) responses containing the subsequent 4.08 (Request Entity Incomplete) responses containing the
missing blocks on receipt of a new request providing a missing missing blocks on receipt of a new request providing a missing
payload with the same Request-Tag. 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: Updating the payload without overflowing the Implementation Note: Updating the payload without overflowing the
overall packet size as each block number can be of varying length overall packet size as each block number can be of varying length
needs consideration. It is possible to use Indefinite-Length needs consideration. It is possible to use Indefinite-Length
Arrays (Section 3.2.2 of [RFC8949]), limit the array count to 23 Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit the
(Undefined value) so that the array data byte can be updated with array count to 23 so that the initial byte with the array major
the overall length once the payload length is confirmed or limited type and data length in the additional information can be updated
to MAX_PAYLOADS count. Limiting the count to MAX_PAYLOADS means with the overall count once the payload count is confirmed.
that Congestion Control is less likely to be invoked on the Further restricting the count to MAX_PAYLOADS means that
server. congestion control is less likely to be invoked on the server.
The 4.08 (Request Entity Incomplete) with Content-Type "application/
missing-blocks+cbor-seq" SHOULD NOT be used when using Confirmable
requests or a reliable connection [RFC8323] as the client will be
able to determine that there is a transmission failure of a
particular payload and hence that the server is missing that payload.
5. The Use of Tokens 5. The Use of Tokens
Each new request MUST use a unique Token (Section 4 of Each new request MUST use a unique Token (Section 4 of
[I-D.ietf-core-echo-request-tag]). Additional responses may use the [I-D.ietf-core-echo-request-tag]). Additional responses may use the
same Token. same Token.
Implementation Note: To minimize on the number of tokens that have Implementation Note: To minimize on the number of tokens that have
to be tracked by clients, it is recommended that the bottom 32 to be tracked by clients, it is recommended that the bottom 32
bits is kept the same for the same body and the upper 32 bits bits is kept the same for the same body and the upper 32 bits
contains the individual payload number. contains the individual payload number.
Servers continue to treat the token as a unique opaque entity. If Servers continue to treat the token as a unique opaque entity. If
an individual payload has to be resent (e.g., requested upon an individual payload has to be resent (e.g., requested upon
packet loss), then the retransmitted packet is treated as a new packet loss), then the retransmitted packet is treated as a new
request (i.e., the bottom 32 bits must change). request (i.e., the bottom 32 bits must change).
6. Congestion Control 6. Congestion Control
The transmission of the payloads of a body either SHOULD all be
Confirmable or all be Non-confirmable. This is meant to simplify the
congestion control procedure.
6.1. Confirmable (CON)
Congestion control for CON requests and responses is specified in
Section 4.7 of [RFC7252]. For faster transmission rates, NSTART will
need to be increased from 1. However, the other CON congestion
control parameters will need to be tuned to cover this change. This
tuning is out of scope of this document as it is expected that all
requests and responses using Q-Block1 and Q-Block2 will be Non-
confirmable.
It is implementation specific as to whether there should be any
further requests for missing data as there will have been significant
transmission failure as individual payloads will have failed after
MAX_TRANSMIT_SPAN.
6.2. Non-confirmable (NON)
This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT,
NON_RECEIVE_TIMEOUT, NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT
primarily for use with NON.
MAX_PAYLOADS should be configurable with a default value of 10. Both
CoAP endpoints SHOULD have the same value (otherwise there will be
transmission delays in one direction) and the value MAY be negotiated
between the endpoints to a common value by using a higher level
protocol (out of scope of this document). This is the maximum number
of payloads that can be transmitted at any one time.
Note: The default value of 10 is chosen for reasons similar to
those discussed in Section 5 of [RFC6928].
NON_TIMEOUT is the maximum period of delay between sending sets of
MAX_PAYLOADS payloads for the same body. NON_TIMEOUT has the same
value as ACK_TIMEOUT (Section 4.8 of [RFC7252]).
NON_RECEIVE_TIMEOUT is the maximum time to wait for a missing payload
before requesting retransmission. NON_RECEIVE_TIMEOUT has a value of
twice NON_TIMEOUT.
NON_PROBING_WAIT is used to limit the potential wait needed
calculated when using PROBING_WAIT. NON_PROBING_WAIT has the same
value as computed for EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).
NON_PARTIAL_TIMEOUT is used for expiring partially received bodies.
NON_PARTIAL_TIMEOUT has the same value as computed for
EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).
+---------------------+---------------+
| Parameter Name | Default Value |
+=====================+===============|
| MAX_PAYLOADS | 10 |
| NON_TIMEOUT | 2 s |
| NON_RECEIVE_TIMEOUT | 4 s |
| NON_PROBING_WAIT | 247 s |
| NON_PARTIAL_TIMEOUT | 247 s |
+---------------------+---------------+
Table 3: Derived Protocol Parameters
PROBING_RATE parameter in CoAP indicates the average data rate that PROBING_RATE parameter in CoAP indicates the average data rate that
must not be exceeded by a CoAP endpoint in sending to a peer endpoint must not be exceeded by a CoAP endpoint in sending to a peer endpoint
that does not respond. The body of blocks will be subjected to that does not respond. The single body of blocks will be subjected
PROBING_RATE (Section 4.7 of [RFC7252]). to PROBING_RATE (Section 4.7 of [RFC7252]), not the individual
packets. If the wait time between sending bodies that are not being
responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the
gap time is limited to NON_PROBING_WAIT.
Each NON 4.08 (Request Entity Incomplete) Response Codes is subjected Note: For the particular DOTS application, PROBING_RATE and other
to PROBING_RATE. transmission parameters are negotiated between peers. Even when
not negotiated, the DOTS application uses customized defaults as
discussed in Section 4.5.2 of [RFC8782].
Each NON GET or similar request using Q-Block2 Option is subjected to Each NON 4.08 (Request Entity Incomplete) response is subject to
PROBING_RATE.
Each NON GET or FETCH request using Q-Block2 Option is subject to
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 set of
MAX_PAYLOADS payloads of a single body, a delay is introduced of MAX_PAYLOADS payloads of a single body, a delay is introduced of
ACK_TIMEOUT (Section 4.8.2 of [RFC7252]) before the next set of NON_TIMEOUT before sending the next set of payloads to manage
payload transmissions to manage potential congestion issues. potential congestion issues.
MAX_PAYLOADS should be configurable with a default value of 10.
Note: The default value is chosen for reasons similar to those If the CoAP peer reports at least one payload has not arrived for
discussed in Section 5 of [RFC6928]. each body for at least a 24 hour period and it is known that there
are no other network issues over that period, then the value of
MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1) and
the situation re-evaluated for another 24 hour period until there is
no report of missing payloads under normal operating conditions.
Note that the CoAP peer will not know about the MAX_PAYLOADS change
until it is reconfigured. As a consequence, the peer may indicate
that there are some missing payloads prior to the actual payload
being transmitted as all of its MAX_PAYLOADS payloads have not
arrived.
For NON transmissions, it is permissible, but not required, to send The sending of a set of missing payloads of a body is subject to
the ultimate payload of a MAX_PAYLOADS set as a Confirmable packet. MAX_PAYLOADS set of payloads.
If a Confirmable packet is used, then the transmitting peer MUST wait
for the ACK to be returned before sending the next set of payloads,
which can be in time terms less than the ACK_TIMEOUT delay.
Also, for NON transmissions, it is permissible, but not required, to For Q-Block1 Option, if the server responds with a 2.31 (Continue)
send a Confirmable packet for the final payload of a body transfer Response Code for the latest payload sent, then the client can
(that is, M bit unset). If a Confirmable packet is used, then the continue to send the next set of payloads without any delay. If the
transmitting peer MUST wait for the appropriate response to be server responds with a 4.08 (Request Entity Incomplete) Response
returned for successful transmission, or respond to requests for the Code, then the missing payloads SHOULD be retransmitted before going
missing blocks (if any). into another NON_TIMEOUT delay prior to sending the next set of
payloads.
The sending of the set of missing blocks is subject to MAX_PAYLOADS. For the server receiving NON Q-Block1 requests, it SHOULD send back a
2.31 (Continue) or 4.08 (Request Entity Incomplete) Response Code on
receipt of the last of the MAX_PAYLOADS payloads to prevent the
client unnecessarily delaying. If the last of the MAX_PAYLOADS
payloads does not arrive (or the final payload where the M bit is not
set does not arrive), then the server SHOULD delay for
NON_RECEIVE_TIMEOUT before sending the 4.08 (Request Entity
Incomplete) Response Code.
Note: A delay of ACK_TIMEOUT after every transmission of It is possible that the client may start transmitting the next set of
MAX_PAYLOADS blocks may be observed even if the peer agent is able MAX_PAYLOADS payloads before the server times out on waiting for the
to handle more blocks without experiencing an overload. This last of the previous MAX_PAYLOADS payloads. On receipt of the first
delay can be reduced by using CON for the MAX_PAYLOADS packet to payload from the new set of MAX_PAYLOADS payloads, the server SHOULD
trigger sending the next set of data when the ACK is received. send a 4.08 (Request Entity Incomplete) Response Code indicating any
Nevertheless, this behavior is likely to create other timeout missing payloads from any previous MAX_PAYLOADS payloads. Upon
issues in a lossy environment (e.g., unidirectional loss as in receipt of the 4.08 (Request Entity Incomplete) Response Code, the
DDoS pipe flooding). The use of NON is thus superior but requires client SHOULD send the missing payloads before continuing to send the
an additional signal in the MAX_PAYLOADS packet to seek for a 2.31 remainder of the MAX_PAYLOADS payloads and then go into another
(Continue) from the peer if it is ready to receive the next set of NON_TIMEOUT delay prior to sending the next set of payloads.
blocks.
For the client receiving NON Q-Block2 responses, it SHOULD send a
request for the next set of payloads or a request for the missing
payloads upon receipt of the last of the MAX_PAYLOADS payloads to
prevent the server unnecessarily delaying the transmission of the
body. If the last of the MAX_PAYLOADS payloads does not arrive (or
the final payload where the M bit is not set does not arrive), then
the client SHOULD delay for NON_RECEIVE_TIMEOUT before sending the
request for the missing payloads.
The request that the client sends to acknowledge the receipt of all
the current set of MAX_PAYLOADS payloads SHOULD contain a special
case Q-Block2 Option with NUM set to the first block of the next set
of MAX_PAYLOADS payloads and the M bit set to 1. The server SHOULD
recognize this special case as a continue request and just continue
the transmission of the body (including Observe Option, if
appropriate for an unsolicited response) rather than as a request for
missing blocks.
The client does not need to acknowledge the receipt of the entire
body.
Note: If there is asymmetric traffic loss causing responses to
never get received, a delay of NON_TIMEOUT after every
transmission of MAX_PAYLOADS blocks will be observed. The
endpoint receiving the body is still likely to receive the entire
body.
7. Caching Considerations 7. 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, it is expected that the proxy will For Q-Block1 and Q-Block2 Options, for simplicity it is expected that
reassemble the body (using any appropriate recovery options for the proxy will reassemble the body (using any appropriate recovery
packet loss) before passing on the body to the appropriate CoAP options for packet loss) before passing on the body to the
endpoint. The onward transmission of the body does not require the appropriate CoAP endpoint. This does not preclude an implementation
use of the Q-Block1 or Q-Block2 Options as these options may not be doing a more complex per payload caching, but how to do this is out
supported in that link. This means that the proxy must fully support of the scope of this document. The onward transmission of the body
the Q-Block1 and Q-Block2 Options. does not require the use of the Q-Block1 or Q-Block2 Options as these
options may not be supported in that link. This means that the proxy
must fully support the Q-Block1 and Q-Block2 Options.
How the body is cached in the initial CoAP client (Q-Block1) or How the body is cached in the CoAP client (for Q-Block1
ultimate CoAP server (Q-Block2) is implementation specific. transmissions) or the CoAP server (for Q-Block2 transmissions) is
implementation specific.
As the entire body is being cached in the proxy, the Q-Block1 and As the entire body is being cached in the proxy, the Q-Block1 and
Q-Block2 Options are not part of the cache key. Q-Block2 Options are removed as part of the block assembly and thus
do not reach the cache.
For Q-Block2 responses, the ETag Option value is associated with the For Q-Block2 responses, the ETag Option value is associated with the
data (and onward transmitted to the CoAP client), but is not part of data (and onward transmitted to the CoAP client), but is not part of
the cache key. the cache key.
For requests with Q-Block1 Option, the Request-Tag Option is For requests with Q-Block1 Option, the Request-Tag Option is
associated with the build up of the body from successive payloads, associated with the build up of the body from successive payloads,
but is not part of the cache key. For the onward transmission of the but is not part of the cache key. For the onward transmission of the
body using CoAP, a new Request-Tag SHOULD be generated and used. body using CoAP, a new Request-Tag SHOULD be generated and used.
Ideally this new Request-Tag should replace the client's request
Request-Tag.
It is possible that two or more CoAP clients are concurrently It is possible that two or more CoAP clients are concurrently
updating the same resource through a common proxy to the same CoAP updating the same resource through a common proxy to the same CoAP
server using Q-Block1 (or Block1) Option. If this is the case, the server using Q-Block1 (or Block1) Option. If this is the case, the
first client to complete building the body causes that body to start first client to complete building the body causes that body to start
transmitting to the CoAP server with an appropriate Request-Tag transmitting to the CoAP server with an appropriate Request-Tag
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. Request-Tag value. Note that it cannot be assumed that the proxy
will always receive a complete body from a client.
A proxy that supports Q-Block2 Option MUST be prepared to receive a A proxy that supports Q-Block2 Option MUST be prepared to receive a
GET or similar message 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-Block2s. If the cache key matching body is not available in the Q-Block2s. If the cache key matching body is not available in the
cache, the proxy MUST request the entire body from the CoAP server cache, the proxy MUST request the entire body from the CoAP server
using the information in the cache key. 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).
8. HTTP-Mapping Considerations 8. HTTP-Mapping Considerations
skipping to change at page 16, line 14 skipping to change at page 20, line 28
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/SZX
QB2: Q-Block2 Option values NUM/More/SZX QB2: Q-Block2 Option values NUM/More/SZX
\: Trimming long lines \: Trimming long lines
[[]]: Comments [[]]: Comments
-->X: Message loss -->X: Message loss (request)
X<--: Message loss X<--: Message loss (response)
...: Passage of time
Figure 2: Notations Used in the Figures Figure 2: Notations Used in the Figures
9.1. Q-Block1 Option: Non-Confirmable Example 9.1. Q-Block1 Option: Non-Confirmable Example
Figure 3 depicts an example of a NON PUT request conveying Q-Block1 Figure 3 depicts an example of a NON PUT request conveying Q-Block1
Option. All the blocks are received by the server. Option. All the blocks are received by the server.
CoAP CoAP CoAP CoAP
Client Server Client Server
skipping to change at page 16, line 47 skipping to change at page 21, line 15
client, but some blocks are dropped in transmission as illustrated in client, but some blocks are dropped in transmission as illustrated in
Figure 4. Figure 4.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON PUT /path M:0x05 T:0xe0 RT=11 QB1:0/1/1024 +--------->| NON PUT /path M:0x05 T:0xe0 RT=11 QB1:0/1/1024
+--->X | NON PUT /path M:0x06 T:0xe1 RT=11 QB1:1/1/1024 +--->X | NON PUT /path M:0x06 T:0xe1 RT=11 QB1:1/1/1024
+--->X | NON PUT /path M:0x07 T:0xe2 RT=11 QB1:2/1/1024 +--->X | NON PUT /path M:0x07 T:0xe2 RT=11 QB1:2/1/1024
+--------->| NON PUT /path M:0x08 T:0xe3 RT=11 QB1:3/0/1024 +--------->| NON PUT /path M:0x08 T:0xe3 RT=11 QB1:3/0/1024
| |
| ... | | ... |
Figure 4: Example of NON Request with Q-Block1 Option (With Loss) Figure 4: Example of NON Request with Q-Block1 Option (With Loss)
The server realizes that some blocks are missing and asks for the The server realizes that some blocks are missing and asks for the
missing ones in one go (Figure 5). It does so by indicating which missing ones in one go (Figure 5). It does so by indicating which
blocks have been received in the data portion of the response. blocks have been received in the data portion of the response. The
Token just needs to be one of those that have been received for this
Request-Tag, so the client can derive the Request-Tag.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | ... |
| ... | |<---------+ NON 4.08 M:0xf2 T:0xe3 [Missing 1,2 [for RT=11]]
|<---------+ NON 4.08 M:0xf2 T:0xe3 [Missing 1,2 for RT=11] +--------->| NON PUT /path M:0x09 T:0xe4 RT=11 QB1:1/1/1024
+--------->| NON PUT /path M:0x09 T:0xe4 RT=11 QB1:1/1/1024 +--->X | NON PUT /path M:0x0a T:0xe5 RT=11 QB1:2/1/1024
+--->X | NON PUT /path M:0x0a T:0xe5 RT=11 QB1:2/1/1024 | ... |
| | [[Server realizes a block is still missing and asks for the missing
|<---------+ NON 4.08 M:0xf3 T:0xe4 [Missing 2 for RT=11] one]]
+--------->| NON PUT /path M:0x0b T:0xe6 RT=11 QB1:2/1/1024 |<---------+ NON 4.08 M:0xf3 T:0xe4 [Missing 2 [for RT=11]]
|<---------+ NON 2.04 M:0xf4 T:0xe6 +--------->| NON PUT /path M:0x0b T:0xe6 RT=11 QB1:2/1/1024
| | |<---------+ NON 2.04 M:0xf4 T:0xe6
| ... | | ... |
Figure 5: Example of NON Request with Q-Block1 Option (Blocks Figure 5: Example of NON Request with Q-Block1 Option (Blocks
Recovery) Recovery)
Under high levels of traffic loss, the client can elect not to retry Under high levels of traffic loss, the client can elect not to retry
sending missing blocks of data. This decision is implementation sending missing blocks of data by "forgetting" all the tracked tokens
specific. for this Request-Tag. This decision is implementation specific.
9.2. Q-Block2 Option: Non-Confirmable Example 9.2. Q-Block2 Option: Non-Confirmable Example
Figure 6 illustrates the example of Q-Block2 Option. The client Figure 6 illustrates the example of Q-Block2 Option. The client
sends a NON GET carrying an Observe and a Q-Block2 Options. The sends a NON GET carrying an Observe and a Q-Block2 Options. The
Q-Block2 Option indicates a size hint (1024 bytes). This request is Q-Block2 Option indicates a block size hint (1024 bytes). This
replied by the server using four (4) blocks that are transmitted to request is replied to by the server using four (4) blocks that are
the client without any loss. Each of these blocks carries a Q-Block2 transmitted to the client without any loss. Each of these blocks
Option. The same process is repeated when an Observe is triggered, carries a Q-Block2 Option. The same process is repeated when an
but no loss is experienced by any of the notification blocks. Observe is triggered, but no loss is experienced by any of the
notification blocks.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/0/1024 +--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/0/1024
|<---------+ NON 2.05 M:0xf1 T:0xf0 O:1234 ET=21 QB2:0/1/1024 |<---------+ NON 2.05 M:0xf1 T:0xf0 O:1234 ET=21 QB2:0/1/1024
|<---------+ NON 2.05 M:0xf2 T:0xf0 O:1234 ET=21 QB2:1/1/1024 |<---------+ NON 2.05 M:0xf2 T:0xf0 O:1234 ET=21 QB2:1/1/1024
|<---------+ NON 2.05 M:0xf3 T:0xf0 O:1234 ET=21 QB2:2/1/1024 |<---------+ NON 2.05 M:0xf3 T:0xf0 O:1234 ET=21 QB2:2/1/1024
|<---------+ NON 2.05 M:0xf4 T:0xf0 O:1234 ET=21 QB2:3/0/1024 |<---------+ NON 2.05 M:0xf4 T:0xf0 O:1234 ET=21 QB2:3/0/1024
| ... | | ... |
skipping to change at page 19, line 7 skipping to change at page 23, line 7
Figure 6: Example of NON Notifications with Q-Block2 Option (Without Figure 6: Example of NON Notifications with Q-Block2 Option (Without
Loss) Loss)
Figure 7 shows the example of an Observe that is triggered but for Figure 7 shows the example of an Observe that is triggered but for
which some notification blocks are lost. The client detects the which some notification blocks are lost. The client detects the
missing blocks and requests their retransmission. It does so by missing blocks and requests their retransmission. It does so by
indicating the blocks that were successfully received. indicating the blocks that were successfully received.
CoAP CoAP CoAP CoAP
Client Server Client Server
| |
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0xf9 T:0xf0 O:1236 ET=23 QB2:0/1/1024 |<---------+ NON 2.05 M:0xf9 T:0xf0 O:1236 ET=23 QB2:0/1/1024
| X<---+ NON 2.05 M:0xfa T:0xf0 O:1236 ET=23 QB2:1/1/1024 | X<---+ NON 2.05 M:0xfa T:0xf0 O:1236 ET=23 QB2:1/1/1024
| X<---+ NON 2.05 M:0xfb T:0xf0 O:1236 ET=23 QB2:2/1/1024 | X<---+ NON 2.05 M:0xfb T:0xf0 O:1236 ET=23 QB2:2/1/1024
|<---------+ NON 2.05 M:0xfc T:0xf0 O:1236 ET=23 QB2:3/0/1024 |<---------+ NON 2.05 M:0xfc T:0xf0 O:1236 ET=23 QB2:3/0/1024
| | | ... |
[[Client realizes blocks are missing and asks for the missing [[Client realizes blocks are missing and asks for the missing
ones in one go]] ones in one go]]
+--------->| NON GET /path M:0x02 T:0xf1 QB2:1/0/1024\ +--------->| NON GET /path M:0x02 T:0xf1 QB2:1/0/1024\
| | QB2:2/0/1024 | | QB2:2/0/1024
| X<---+ NON 2.05 M:0xfd T:0xf1 ET=23 QB2:1/1/1024 | X<---+ NON 2.05 M:0xfd T:0xf1 ET=23 QB2:1/1/1024
|<---------+ NON 2.05 M:0xfe T:0xf1 ET=23 QB2:2/1/1024 |<---------+ NON 2.05 M:0xfe T:0xf1 ET=23 QB2:2/1/1024
| | | ... |
[[Get the final missing block]] [[Get the final missing block]]
+--------->| NON GET /path M:0x03 T:0xf2 QB2:1/0/1024 +--------->| NON GET /path M:0x03 T:0xf2 QB2:1/0/1024
|<---------+ NON 2.05 M:0xff T:0xf2 ET=23 QB2:1/1/1024 |<---------+ NON 2.05 M:0xff T:0xf2 ET=23 QB2:1/1/1024
| ... | | ... |
Figure 7: Example of NON Notifications with Q-Block2 Option (Blocks Figure 7: Example of NON Notifications with Q-Block2 Option (Blocks
Recovery) Recovery)
Under high levels of traffic loss, the client can elect not to retry Under high levels of traffic loss, the client can elect not to retry
getting missing blocks of data. This decision is implementation getting missing blocks of data. This decision is implementation
specific. specific.
Figure 8 shows the example of an Observe that is triggered but only Figure 8 shows the example of an Observe that is triggered but only
the first two notification blocks reaches the client. In order to the first two notification blocks reaches 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:0x123 T:0xf0 O:1237 ET=24 QB2:0/1/1024 |<---------+ NON 2.05 M:0x123 T:0xf0 O:1237 ET=24 QB2:0/1/1024
|<---------+ NON 2.05 M:0x124 T:0xf0 O:1237 ET=24 QB2:1/1/1024 |<---------+ NON 2.05 M:0x124 T:0xf0 O:1237 ET=24 QB2:1/1/1024
| X<---+ NON 2.05 M:0x125 T:0xf0 O:1237 ET=24 QB2:2/1/1024 | X<---+ NON 2.05 M:0x125 T:0xf0 O:1237 ET=24 QB2:2/1/1024
| X<---+ NON 2.05 M:0x126 T:0xf0 O:1237 ET=24 QB2:3/0/1024 | X<---+ NON 2.05 M:0x126 T:0xf0 O:1237 ET=24 QB2:3/0/1024
| | | ... |
[[Client realizes blocks are missing and asks for the remaining missing [[Client realizes blocks are missing and asks for the remaining missing
ones in one go by setting the M bit]] ones in one go by setting the M bit]]
+--------->| NON GET /path M:0x03 T:0xf3 QB2:2/1/1024 +--------->| NON GET /path M:0x03 T:0xf3 QB2:2/1/1024
|<---------+ NON 2.05 M:0x127 T:0xf3 ET=24 QB2:2/1/1024 |<---------+ NON 2.05 M:0x127 T:0xf3 ET=24 QB2:2/1/1024
|<---------+ NON 2.05 M:0x128 T:0xf3 ET=24 QB2:3/0/1024 |<---------+ NON 2.05 M:0x128 T:0xf3 ET=24 QB2:3/0/1024
| ... | | ... |
Figure 8: Example of NON Notifications with Q-Block2 Option (Blocks Figure 8: Example of NON Notifications with Q-Block2 Option (Blocks
Recovery with M bit Set) Recovery with M bit Set)
skipping to change at page 20, line 39 skipping to change at page 24, line 38
IANA is requested to add the following entries to the "CoAP Option IANA is requested to add the following entries to the "CoAP Option
Numbers" sub-registry [Options]: Numbers" sub-registry [Options]:
+--------+------------------+-----------+ +--------+------------------+-----------+
| Number | Name | Reference | | Number | Name | Reference |
+========+==================+===========+ +========+==================+===========+
| TBA1 | Q-Block1 | [RFCXXXX] | | TBA1 | Q-Block1 | [RFCXXXX] |
| TBA2 | Q-Block2 | [RFCXXXX] | | TBA2 | Q-Block2 | [RFCXXXX] |
+--------+------------------+-----------+ +--------+------------------+-----------+
Table 3: CoAP Q-Block1 and Q-Block2 Option Numbers Table 4: CoAP Q-Block1 and Q-Block2 Option Numbers
This document suggests 19 (TBA1) and 51 (TBA2) as a values to be This document suggests 19 (TBA1) and 51 (TBA2) as a values to be
assigned for the new option numbers. assigned for the new option numbers.
10.2. New Content Format 10.2. New Media Type
This document requests IANA to register the "application/missing-
blocks+cbor-seq" media type in the "Media Types" registry
[IANA-MediaTypes]:
Type name: application
Subtype name: missing-blocks+cbor-seq
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary
Security considerations: See the Security Considerations Section of
[This_Document].
Interoperability considerations: N/A
Published specification: [This_Document]
Applications that use this media type: Data serialization and deserialization.
Fragment identifier considerations: N/A
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information: IETF,
iesg@ietf.org
Intended usage: COMMON
Restrictions on usage: none
Author: See Authors' Addresses section.
Change controller: IESG
Provisional registration? No
10.3. New Content Format
This document requests IANA to register the CoAP Content-Format ID This document requests IANA to register the CoAP Content-Format ID
for the "application/missing-blocks+cbor-seq" media type in the "CoAP for the "application/missing-blocks+cbor-seq" media type in the "CoAP
Content-Formats" registry [Format]: Content-Formats" registry [Format]:
o Media Type: application/missing-blocks+cbor-seq o Media Type: application/missing-blocks+cbor-seq
o Encoding: - o Encoding: -
o Id: TBD3 o Id: TBD3
o Reference: [RFCXXXX] o Reference: [RFCXXXX]
skipping to change at page 23, line 25 skipping to change at page 28, line 25
[Format] , <https://www.iana.org/assignments/core-parameters/core- [Format] , <https://www.iana.org/assignments/core-parameters/core-
parameters.xhtml#content-formats>. parameters.xhtml#content-formats>.
[I-D.ietf-dots-telemetry] [I-D.ietf-dots-telemetry]
Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c., Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c.,
and J. Shallow, "Distributed Denial-of-Service Open Threat and J. 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, "Media Types",
<https://www.iana.org/assignments/media-types>.
[Options] , <https://www.iana.org/assignments/core-parameters/core- [Options] , <https://www.iana.org/assignments/core-parameters/core-
parameters.xhtml#option-numbers>. parameters.xhtml#option-numbers>.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928, "Increasing TCP's Initial Window", RFC 6928,
DOI 10.17487/RFC6928, April 2013, DOI 10.17487/RFC6928, April 2013,
<https://www.rfc-editor.org/info/rfc6928>. <https://www.rfc-editor.org/info/rfc6928>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
skipping to change at page 24, line 37 skipping to change at page 30, line 14
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| CON PUT /path M:0x05 T:0xf4 RT=11 QB1:0/1/1024 +--------->| CON PUT /path M:0x05 T:0xf4 RT=11 QB1:0/1/1024
+--->X | CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 +--->X | CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024
+--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
+--------->| CON PUT /path M:0x08 T:0xf7 RT=11 QB1:3/1/1024 +--------->| CON PUT /path M:0x08 T:0xf7 RT=11 QB1:3/1/1024
|<---------+ ACK 0.00 M:0x05 |<---------+ ACK 0.00 M:0x05
|<---------+ ACK 0.00 M:0x08 |<---------+ ACK 0.00 M:0x08
| | | ... |
[[The client retries sending packets not acknowledged]] [[The client retries sending packets not acknowledged]]
+--------->| CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 +--------->| CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024
+--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
|<---------+ ACK 0.00 M:0x06 |<---------+ ACK 0.00 M:0x06
| | | ... |
[[The client retransmits messages not acknowledged [[The client retransmits messages not acknowledged
(exponential backoff)]] (exponential backoff)]]
+--->? | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 +--->? | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
| | | ... |
[[Either transmission failure (acknowledge retry timeout) [[Either body transmission failure (acknowledge retry timeout)
or successfully transmitted.]] or successfully transmitted.]]
Figure 10: Example of CON Request with Q-Block1 Option (Blocks Figure 10: Example of CON Request with Q-Block1 Option (Blocks
Recovery) Recovery)
It is implementation dependent as to whether the application process It is up to the implementation as to whether the application process
is terminated on reaching MAX_RETRANSMIT or stops trying to send this stops trying to send this particular body of data on reaching
particular body of data and continues to run under such adverse MAX_RETRANSMIT for any payload, or separately tries to initiate the
traffic conditions. new transmission of the payloads that have not been acknowledged
under these adverse traffic conditions.
If there is likely to be the possibility of network transient losses, If there is likely to be the possibility of network transient losses,
then the use of Non-confirmable traffic 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 11. shown in Figure 11.
Client Server Client Server
| | | |
+--------->| CON GET /path M:0x01 T:0xf0 O:0 QB2:0/0/1024 +--------->| CON GET /path M:0x01 T:0xf0 O:0 QB2:0/0/1024
|<---------+ ACK 2.05 M:0x01 T:0xf0 O:1234 ET=21 QB2:0/1/1024 |<---------+ ACK 2.05 M:0x01 T:0xf0 O:1234 ET=21 QB2:0/1/1024
|<---------+ ACK 2.05 M:0xe1 T:0xf0 O:1234 ET=21 QB2:1/1/1024 |<---------+ ACK 2.05 M:0xe1 T:0xf0 O:1234 ET=21 QB2:1/1/1024
|<---------+ ACK 2.05 M:0xe2 T:0xf0 O:1234 ET=21 QB2:2/1/1024 |<---------+ ACK 2.05 M:0xe2 T:0xf0 O:1234 ET=21 QB2:2/1/1024
|<---------+ ACK 2.05 M:0xe3 T:0xf0 O:1234 ET=21 QB2:3/0/1024 |<---------+ ACK 2.05 M:0xe3 T:0xf0 O:1234 ET=21 QB2:3/0/1024
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ CON 2.05 M:0xe4 T:0xf0 O:1235 ET=22 QB2:0/1/1024 |<---------+ CON 2.05 M:0xe4 T:0xf0 O:1235 ET=22 QB2:0/1/1024
|<---------+ CON 2.05 M:0xe5 T:0xf0 O:1235 ET=22 QB2:1/1/1024 |<---------+ CON 2.05 M:0xe5 T:0xf0 O:1235 ET=22 QB2:1/1/1024
|<---------+ CON 2.05 M:0xe6 T:0xf0 O:1235 ET=22 QB2:2/1/1024 |<---------+ CON 2.05 M:0xe6 T:0xf0 O:1235 ET=22 QB2:2/1/1024
|<---------+ CON 2.05 M:0xe7 T:0xf0 O:1235 ET=22 QB2:3/0/1024 |<---------+ CON 2.05 M:0xe7 T:0xf0 O:1235 ET=22 QB2:3/0/1024
|--------->+ ACK 0.00 M:0xe4 |--------->+ ACK 0.00 M:0xe4
|--------->+ ACK 0.00 M:0xe5 |--------->+ ACK 0.00 M:0xe5
|--------->+ ACK 0.00 M:0xe6 |--------->+ ACK 0.00 M:0xe6
|--------->+ ACK 0.00 M:0xe7 |--------->+ ACK 0.00 M:0xe7
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ CON 2.05 M:0xe8 T:0xf0 O:1236 ET=23 QB2:0/1/1024 |<---------+ CON 2.05 M:0xe8 T:0xf0 O:1236 ET=23 QB2:0/1/1024
| X<---+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 | X<---+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024
| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
|<---------+ CON 2.05 M:0xeb T:0xf0 O:1236 ET=23 QB2:3/0/1024 |<---------+ CON 2.05 M:0xeb T:0xf0 O:1236 ET=23 QB2:3/0/1024
|--------->+ ACK 0.00 M:0xe8 |--------->+ ACK 0.00 M:0xe8
|--------->+ ACK 0.00 M:0xeb |--------->+ ACK 0.00 M:0xeb
| | | ... |
| [[Server retransmits messages not acknowledged]] | [[Server retransmits messages not acknowledged]]
|<---------+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 |<---------+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024
| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
|--------->+ ACK 0.00 M:0xe9 |--------->+ ACK 0.00 M:0xe9
| | | ... |
| [[Server retransmits messages not acknowledged | [[Server retransmits messages not acknowledged
| (exponential backoff)]] | (exponential backoff)]]
| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
| | | ... |
[[Either transmission failure (acknowledge retry timeout) [[Either body transmission failure (acknowledge retry timeout)
or successfully transmitted.]] or successfully transmitted.]]
Figure 11: Example of CON Notifications with Q-Block2 Option Figure 11: Example of CON Notifications with Q-Block2 Option
It is up to the implementation as to whether the application process
stops trying to send this particular body of data on reaching
MAX_RETRANSMIT for any payload, or separately tries to initiate the
new transmission of the payloads that have not been acknowledged
under these adverse traffic conditions.
If there is likely to be the possibility of network transient losses, If there is likely to be the possibility of network transient losses,
then the use of Non-confirmable traffic should be considered. then the use of NON should be considered.
Authors' Addresses Authors' Addresses
Mohamed Boucadair Mohamed Boucadair
Orange Orange
Rennes 35000 Rennes 35000
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Jon Shallow Jon Shallow
United Kingdom United Kingdom
 End of changes. 103 change blocks. 
329 lines changed or deleted 595 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/