draft-ietf-core-new-block-02.txt   draft-ietf-core-new-block-03.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: May 2, 2021 October 29, 2020 Expires: June 25, 2021 December 22, 2020
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-02 draft-ietf-core-new-block-03
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 May 2, 2021. This Internet-Draft will expire on June 25, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Existing CoAP Block-Wise Transfer Options . . . . . . . . 3 1.1. Alternative CoAP Block-Wise Transfer Options . . . . . . 3
1.2. Alternative CoAP Block-Wise Transfer Options . . . . . . 3 1.2. Updated CoAP Response Code (4.08) . . . . . . . . . . . . 4
1.3. Updated CoAP Response Code (4.08) . . . . . . . . . . . . 4 1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 5
1.4. Applicability Scope . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . 7
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 . . . . . . . . . . . . . . . . 9
3.5. Working with Observe and Q-Block2 Options . . . . . . . . 11 3.5. Working with Observe and Q-Block2 Options . . . . . . . . 11
3.6. Working with Size1 and Size2 Options . . . . . . . . . . 11 3.6. Working with Size1 and Size2 Options . . . . . . . . . . 11
3.7. Use of Q-Block1 and Q-Block2 Options Together . . . . . . 11 3.7. Use of Q-Block1 and Q-Block2 Options Together . . . . . . 12
4. The Use of 4.08 (Request Entity Incomplete) Response Code . . 11 4. The Use of 4.08 (Request Entity Incomplete) Response Code . . 12
5. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 13 5. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 13
6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 13 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 13
7. Caching Considerations . . . . . . . . . . . . . . . . . . . 14 7. Caching Considerations . . . . . . . . . . . . . . . . . . . 14
8. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 15 8. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 15
9. Examples of Selective Block Recovery . . . . . . . . . . . . 15 9. Examples of Selective Block Recovery . . . . . . . . . . . . 15
9.1. Q-Block1 Option: Non-Confirmable Example . . . . . . . . 16 9.1. Q-Block1 Option: Non-Confirmable Example . . . . . . . . 16
9.2. Q-Block2 Option: Non-Confirmable Example . . . . . . . . 17 9.2. Q-Block2 Option: Non-Confirmable Example . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10.1. New CoAP Options . . . . . . . . . . . . . . . . . . . . 19 10.1. New CoAP Options . . . . . . . . . . . . . . . . . . . . 20
10.2. New Content Format . . . . . . . . . . . . . . . . . . . 20 10.2. New Content Format . . . . . . . . . . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 20 13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 22 13.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Examples with Confirmable Messages . . . . . . . . . 22 Appendix A. Examples with Confirmable Messages . . . . . . . . . 23
A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 22 A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 24
A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 24 A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
1.1. Existing CoAP Block-Wise Transfer Options
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 further updated by [RFC8323] for use over TCP, TLS, fragmentation and was further updated by [RFC8323] for use over TCP,
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 block has to be requested and can only ask
for (or send) the next block when the request for the previous block for (or send) the next block when the request for the previous block
has completed. Packet, and hence block transmission rate, is has completed. Packet, and hence block transmission rate, is
controlled by Round Trip Times (RTTs). 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. An example is when a network is subject to a
Distributed Denial of Service (DDoS) attack and there is a need for Distributed Denial of Service (DDoS) attack and there is a need for
DDoS mitigation agents relying upon CoAP to communicate with each DDoS mitigation agents relying upon CoAP to communicate with each
other (e.g., [I-D.ietf-dots-telemetry]). As a reminder, [RFC7959] other (e.g., [I-D.ietf-dots-telemetry]). As a reminder, [RFC7959]
recommends use of Confirmable (CON) responses to handle potential recommends use of Confirmable (CON) responses to handle potential
packet loss; which does not work with a flooded pipe DDoS situation. packet loss, which does not work with a flooded pipe DDoS situation.
1.2. 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
skipping to change at page 4, line 30 skipping to change at page 4, line 25
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 asymmetrical packet loss is not a benefit
here. Some sample examples with Confirmable messages are provided in here. Some sample examples with Confirmable messages are provided in
Appendix A. 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 endpoint Concretely, the receiving CoAP endpoint informs the CoAP sender
sender either successful receipt or reports on all blocks in the body endpoint either successful receipt or reports on all blocks in the
that have been not yet been received. The CoAP endpoint sender 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 respectively when the different transmission semantics
are required. If the option is not supported by a peer, then are required. If the 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 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.3. Updated CoAP Response Code (4.08) 1.2. Updated CoAP Response Code (4.08)
This document updates the 4.08 (Request Entity Incomplete) by This document updates the 4.08 (Request Entity Incomplete) by
defining an additional message format for reporting on payloads using defining an additional message format for reporting on payloads using
the Q-Block1 Option that are not received by the server. the Q-Block1 Option that are not received by the server.
See Section 4 for more details. See Section 4 for more details.
1.4. 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. Concretely, this mechanism primarily targets applications such case. Concretely, this mechanism primarily targets applications such
as DDoS Open Threat Signaling (DOTS) that can't use Confirmable (CON) as DDoS Open Threat Signaling (DOTS) that can't use Confirmable (CON)
responses to handle potential packet loss and that support responses to handle potential packet loss and that support
application-specific mechanisms to assess whether the remote peer is application-specific mechanisms to assess whether the remote peer is
skipping to change at page 5, line 31 skipping to change at page 5, line 29
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
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 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. trusted. Using OSCORE [RFC8613] does provide a security context and,
hence, a trust of the source endpoint. However, using a NoSec
security mode may still be inadequate for reasons discussed in
Section 11.
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
skipping to change at page 7, line 28 skipping to change at page 7, line 28
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 re-transmission 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 (see Section 4.1 of [RFC8613]): The Q-Block1 (or Q-Block2) processing (Table 2): The Q-Block1 (or Q-Block2) Option MAY be an
Option MAY be an Inner or Outer option. The Inner and Outer values Inner or Outer option (see Section 4.1 of [RFC8613]). The Inner and
are therefore independent of each other. The Inner option is Outer values are therefore independent of each other. The Inner
encrypted and integrity protected between clients and servers, and option is encrypted and integrity protected between clients and
provides message body identification in case of end-to-end servers, and provides message body identification in case of end-to-
fragmentation of requests. The Outer option is visible to proxies end fragmentation of requests. The Outer option is visible to
and labels message bodies in case of hop-by-hop fragmentation of proxies and labels message bodies in case of hop-by-hop fragmentation
requests. of requests.
+--------+-----------------+---+---+
| Number | Name | E | U |
+========+=================+===+===+
| TBA1 | Q-Block1 | x | x |
| TBA2 | Q-Block2 | x | x |
+--------+-----------------+---+---+
Table 2: 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 24 skipping to change at page 8, line 31
Request-Tag Option [I-D.ietf-core-echo-request-tag]. The Request-Tag Request-Tag Option [I-D.ietf-core-echo-request-tag]. The Request-Tag
value MUST be the same for all of the blocks in the body of data that value MUST be the same for all of the blocks in the body of data that
is being transferred. It is also used to identify a particular block is being transferred. It is also used to identify a particular block
of a body that needs to be re-transmitted. The Request-Tag is opaque of a body that needs to be re-transmitted. The Request-Tag is opaque
in nature, but it is RECOMMENDED that the client treats it as an in nature, but it is RECOMMENDED that the client treats it as an
unsigned integer of 8 bytes in length. An implementation may want to unsigned integer of 8 bytes in length. An implementation may want to
consider limiting this to 4 bytes to reduce packet overhead size. consider limiting this to 4 bytes to reduce packet overhead size.
The server still treats it as an opaque entity. The Request-Tag 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 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 and SHOULD be incremented whenever a new body of data is being
transmitted for a CoAP session between peers. The initial Request- transmitted between peers. The initial Request-Tag value SHOULD be
Tag value SHOULD be randomly generated by the client. randomly generated by the client.
For Confirmable transmission, the server MUST continue to acknowledge For Confirmable transmission, the server MUST continue to acknowledge
each packet. NSTART will also need to be increased from the default each packet. NSTART will also need to be increased from the default
(1) to get faster transmission rates. (1) to get faster transmission rates.
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 A 2.01 (Created) or 2.04 (Changed) Response Code indicates successful
receipt of the entire body. receipt of the entire body.
skipping to change at page 9, line 41 skipping to change at page 9, line 47
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 silently ignore the packet.
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 EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).
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 this 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 server receives multiple requests blocks within the body. If the request includes multiple Q-Block2
(implied or otherwise) for the same block, it MUST only send back one Options and these options overlap (e.g., combination of M being set
instance of that block. (this and all the later blocks) and being unset (this individual
block)) resulting in an individual block being requested multiple
times, the server MUST only send back one instance of that block.
This behavior is meant to prevent amplification attacks.
The payloads sent back from the server as a response MUST all have The 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 in nature, but it is RECOMMENDED that the server
treats it as an unsigned integer of 8 bytes in length. An treats it 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 client still treats it as an opaque reduce packet overhead size. The client still treats it as an opaque
entity. The ETag value MUST be different for distinct bodies or sets 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 of blocks of data and SHOULD be incremented whenever a new body of
data is being transmitted for a CoAP session between peers. The data is being transmitted between peers. The initial ETag value
initial ETag value SHOULD be randomly generated by the server. SHOULD be randomly generated by the server.
If the client detects that some of the payloads are missing, the If the client detects that some of the payloads are missing, the
missing payloads are requested by issuing a new GET, POST, PUT, missing payloads are requested by issuing a new GET, POST, PUT,
FETCH, PATCH, or iPATCH request that contains one or more Q-Block2 FETCH, PATCH, or iPATCH request that contains one or more Q-Block2
Options that define the missing blocks with the M bit unset. Options that define the missing blocks with the M bit unset.
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) if this is the case. server SHOULD respond with a 4.00 (Bad Request) to requests not
adhering to this behavior.
The ETag Option MUST NOT be used in the request as the server could The ETag Option MUST NOT be used in the request as the server could
respond with a 2.03 (Valid Response) with no payload. If the server respond with a 2.03 (Valid Response) with no payload. If the server
responds with a different ETag Option value (as the resource responds with a different ETag Option value (as the resource
representation has changed), then the client SHOULD drop all the representation has changed), then the client SHOULD drop all the
payloads for the current body that are no longer valid. payloads for the current body that are no longer valid.
The client may elect to request the missing blocks or just ignore the The client may elect to request the missing blocks or just ignore the
partial body. It SHOULD wait for up to MAX_TRANSMIT_SPAN partial body. It SHOULD wait for up to MAX_TRANSMIT_SPAN
(Section 4.8.2 of [RFC7252]) before issuing a GET, POST, PUT, FETCH, (Section 4.8.2 of [RFC7252]) before issuing a GET, POST, PUT, FETCH,
skipping to change at page 11, line 7 skipping to change at page 11, line 15
If the server transmits a new body of data (e.g., a triggered If the server transmits a new body of data (e.g., a triggered
Observe) with a new ETag to the same client as an additional Observe) with a new ETag to the same client as an additional
response, the client MUST remove any partially received body held for response, the client MUST remove any partially received body held for
a previous ETag. a previous ETag.
If the client receives a duplicate block with the same ETag, it If the client receives a duplicate block with the same ETag, it
SHOULD silently ignore the packet. SHOULD silently ignore the packet.
A client SHOULD only maintain a partial body (missing payloads) for A client SHOULD only maintain a partial body (missing payloads) for
up to EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) or as defined by up to EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) or as defined by
the Max-Age Option whichever is the less. the Max-Age Option, whichever is the less.
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 reflect back all the request 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 Size2 Option.
3.5. Working with Observe and Q-Block2 Options 3.5. Working with 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]
skipping to change at page 11, line 40 skipping to change at page 11, line 48
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 have the same value. of the body and MUST preserve the same value in each of those
payloads.
3.7. Use of Q-Block1 and Q-Block2 Options Together 3.7. Use of 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
skipping to change at page 12, line 50 skipping to change at page 13, line 12
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 2.2.1 of [RFC7049]), limit the array count to 23 Arrays (Section 3.2.2 of [RFC8949]), limit the array count to 23
(Undefined value) so that the array data byte can be updated with (Undefined value) so that the array data byte can be updated with
the overall length once the payload length is confirmed or limited the overall length once the payload length is confirmed or limited
to MAX_PAYLOADS count. Limiting the count to MAX_PAYLOADS means to MAX_PAYLOADS count. Limiting the count to MAX_PAYLOADS means
that Congestion Control is less likely to be invoked on the that Congestion Control is less likely to be invoked on the
server. server.
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
skipping to change at page 16, line 32 skipping to change at page 16, line 32
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
| | | |
+--------->| NON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024 +--------->| NON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024
+--------->| NON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024 +--------->| NON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024
+--------->| NON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024 +--------->| NON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024
+--------->| NON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024 +--------->| NON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024
|<---------+ NON 2.04 M:0xf1 T:0xf3 |<---------+ NON 2.04 M:0xf1 T:0xf3
... | ... |
Figure 3: Example of NON Request with Q-Block1 Option (Without Loss) Figure 3: Example of NON Request with Q-Block1 Option (Without Loss)
Consider now a scenario where a new body of data is to be sent by the Consider now a scenario where a new body of data is to be sent by the
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.
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
| | | |
|<---------+ NON 4.08 M:0xf3 T:0xe4 [Missing 2 for RT=11] |<---------+ NON 4.08 M:0xf3 T:0xe4 [Missing 2 for RT=11]
+--------->| NON PUT /path M:0x0b T:0xe6 RT=11 QB1:2/1/1024 +--------->| NON PUT /path M:0x0b T:0xe6 RT=11 QB1:2/1/1024
|<---------+ NON 2.04 M:0xf4 T:0xe6 |<---------+ 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. This decision is implementation
specific. specific.
9.2. Q-Block2 Option: Non-Confirmable Example 9.2. Q-Block2 Option: Non-Confirmable Example
skipping to change at page 18, line 13 skipping to change at page 18, line 13
but no loss is experienced by any of the notification blocks. 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
... | ... |
[[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0xf5 T:0xf0 O:1235 ET=22 QB2:0/1/1024 |<---------+ NON 2.05 M:0xf5 T:0xf0 O:1235 ET=22 QB2:0/1/1024
|<---------+ NON 2.05 M:0xf6 T:0xf0 O:1235 ET=22 QB2:1/1/1024 |<---------+ NON 2.05 M:0xf6 T:0xf0 O:1235 ET=22 QB2:1/1/1024
|<---------+ NON 2.05 M:0xf7 T:0xf0 O:1235 ET=22 QB2:2/1/1024 |<---------+ NON 2.05 M:0xf7 T:0xf0 O:1235 ET=22 QB2:2/1/1024
|<---------+ NON 2.05 M:0xf8 T:0xf0 O:1235 ET=22 QB2:3/0/1024 |<---------+ NON 2.05 M:0xf8 T:0xf0 O:1235 ET=22 QB2:3/0/1024
... | ... |
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 request 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
the first two notification blocks reaches the client. In order to
retrieve the missing blocks, the client sends a request with a single
Q-Block2 Option with the M bit set.
CoAP CoAP
Client Server
| |
| ... |
| [[Observe triggered]]
|<---------+ NON 2.05 M: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
| 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
| |
[[Client realizes blocks are missing and asks for the remaining missing
ones in one go by setting the M bit]]
+--------->| 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:0x128 T:0xf3 ET=24 QB2:3/0/1024
| ... |
Figure 8: Example of NON Notifications with Q-Block2 Option (Blocks
Recovery with M bit Set)
10. IANA Considerations 10. IANA Considerations
10.1. New CoAP Options 10.1. New CoAP Options
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 2: CoAP Q-Block1 and Q-Block2 Option Numbers Table 3: 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 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]:
skipping to change at page 20, line 22 skipping to change at page 21, line 16
o Encoding: - o Encoding: -
o Id: TBD3 o Id: TBD3
o Reference: [RFCXXXX] o Reference: [RFCXXXX]
11. Security Considerations 11. Security Considerations
Security considerations discussed in Section 7 of [RFC7959] should be Security considerations discussed in Section 7 of [RFC7959] should be
taken into account. taken into account.
Security considerations discussed in Sections 11.3 and 11.4 of Security considerations discussed in Sections 11.3 and 11.4 of
[RFC7252] should be taken into account. In particular, it is NOT [RFC7252] should be taken into account.
RECOMMENDED that the NoSec security mode is used if the Q-Block1 and
Q-Block2 Options are to be used. OSCORE provides end-to-end protection of all information that is not
required for proxy operations and requires that a security context is
set up (Section 3.1 of [RFC8613]). It can be trusted that the source
endpoint is legitimate even if NoSec security mode is used. However,
an intermediary node can modify the unprotected outer Q-Block1 and/or
Q-Block2 Options to cause a Q-Block transfer to fail or keep
requesting all the blocks by setting the M bit and, thus, causing
attack amplification. As discussed in Section 12.1 of [RFC8613],
applications need to consider that certain message fields and
messages types are not protected end-to-end and may be spoofed or
manipulated. It is NOT RECOMMENDED that the NoSec security mode is
used if the Q-Block1 and Q-Block2 Options are to be used.
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. Acknowledgements 12. Acknowledgements
Thanks to Achim Kraus, Jim Schaad, and Michael Richardson for the Thanks to Achim Kraus, Jim Schaad, Michael Richardson, and Marco
comments on the mailing list. Tiloca for the comments.
Special thanks to Christian Amsuess and Carsten Bormann for their Special thanks to Christian Amsuess and Carsten Bormann for their
suggestions and several reviews, which improved this specification suggestions and several reviews, which improved this specification
significantly. significantly.
Some text from [RFC7959] is reused for readers convenience. Some text from [RFC7959] is reused for readers convenience.
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., and G. Selander, "CoAP: Echo,
Request-Tag, and Token Processing", draft-ietf-core-echo- Request-Tag, and Token Processing", draft-ietf-core-echo-
request-tag-10 (work in progress), July 2020. request-tag-11 (work in progress), November 2020.
[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>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>. <https://www.rfc-editor.org/info/rfc7641>.
skipping to change at page 22, line 5 skipping to change at page 23, line 9
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<https://www.rfc-editor.org/info/rfc8742>. <https://www.rfc-editor.org/info/rfc8742>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
13.2. Informative References 13.2. Informative References
[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-13 Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15
(work in progress), October 2020. (work in progress), December 2020.
[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
skipping to change at page 22, line 46 skipping to change at page 24, line 8
Appendix A. Examples with Confirmable Messages Appendix A. Examples with Confirmable Messages
These examples assume NSTART has been increased to at least 4. These examples assume NSTART has been increased to at least 4.
The notations provided in Figure 2 are used in the following The notations provided in Figure 2 are used in the following
subsections. subsections.
A.1. Q-Block1 Option A.1. Q-Block1 Option
Let's now consider the use Q-Block1 Option with a CON request as Let's now consider the use Q-Block1 Option with a CON request as
shown in Figure 8. All the blocks are acknowledged (ACK). shown in Figure 9. All the blocks are acknowledged (ACK).
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| CON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024 +--------->| CON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024
+--------->| CON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024 +--------->| CON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024
+--------->| CON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024 +--------->| CON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024
+--------->| CON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024 +--------->| CON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024
|<---------+ ACK 0.00 M:0x01 |<---------+ ACK 0.00 M:0x01
|<---------+ ACK 0.00 M:0x02 |<---------+ ACK 0.00 M:0x02
|<---------+ ACK 0.00 M:0x03 |<---------+ ACK 0.00 M:0x03
|<---------+ ACK 2.04 M:0x04 |<---------+ ACK 2.04 M:0x04
Figure 8: Example of CON Request with Q-Block1 Option (Without Loss) Figure 9: Example of CON Request with Q-Block1 Option (Without Loss)
Now, suppose that a new body of data is to sent but with some blocks Now, suppose that a new body of data is to sent but with some blocks
dropped in transmission as illustrated in Figure 9. The client will dropped in transmission as illustrated in Figure 10. The client will
retry sending blocks for which no ACK was received. retry sending blocks for which no ACK was received.
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
skipping to change at page 23, line 45 skipping to change at page 24, line 50
+--->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 transmission failure (acknowledge retry timeout)
or successfully transmitted.]] or successfully transmitted.]]
Figure 9: 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 a CoAP session is It is implementation dependent as to whether the application process
terminated following acknowledge retry timeout, or whether the CoAP is terminated on reaching MAX_RETRANSMIT or stops trying to send this
session continues to be used under such adverse traffic conditions. particular body of data and continues to run under such 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-confirmable traffic 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 10. 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 transmission failure (acknowledge retry timeout)
or successfully transmitted.]] or successfully transmitted.]]
Figure 10: Example of CON Notifications with Q-Block2 Option Figure 11: Example of CON Notifications with Q-Block2 Option
It is implementation-dependent as to whether a CoAP session is
terminated following acknowledge retry timeout, or whether the CoAP
session continues to be used under such 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-confirmable traffic 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. 53 change blocks. 
97 lines changed or deleted 144 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/