draft-ietf-core-new-block-04.txt   draft-ietf-core-new-block-05.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: July 10, 2021 January 6, 2021 Expires: July 17, 2021 January 13, 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-04 draft-ietf-core-new-block-05
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 July 10, 2021. This Internet-Draft will expire on July 17, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Alternative CoAP Block-Wise Transfer Options . . . . . . 3 1.1. Alternative CoAP Block-Wise Transfer Options . . . . . . 3
1.2. CoAP Response Code (4.08) Usage . . . . . . . . . . . . . 5 1.2. CoAP Response Code (4.08) Usage . . . . . . . . . . . . . 5
1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 5 1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . 8 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 . . . . . . . . . . . . . . . . 9
3.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 11 3.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 12
3.5. Using Observe and Q-Block2 Options . . . . . . . . . . . 13 3.5. Using Observe and Q-Block1 Options . . . . . . . . . . . 14
3.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 13 3.6. Using Observe and Q-Block2 Options . . . . . . . . . . . 15
3.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 13 3.7. Using Size1 and Size2 Options . . . . . . . . . . . . . . 15
4. The Use of 4.08 (Request Entity Incomplete) Response Code . . 13 3.8. Using Q-Block1 and Q-Block2 Options Together . . . . . . 15
5. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 15 4. The Use of 4.08 (Request Entity Incomplete) Response Code . . 15
6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 15 5. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 15 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 17
6.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 15 6.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 17
7. Caching Considerations . . . . . . . . . . . . . . . . . . . 18 6.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 18
8. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 20 7. Caching Considerations . . . . . . . . . . . . . . . . . . . 21
9. Examples of Selective Block Recovery . . . . . . . . . . . . 20 8. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 22
9.1. Q-Block1 Option: Non-Confirmable Example . . . . . . . . 20 9. Examples with Non-confirmable Messages . . . . . . . . . . . 22
9.2. Q-Block2 Option: Non-Confirmable Example . . . . . . . . 21 9.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 23
10.1. New CoAP Options . . . . . . . . . . . . . . . . . . . . 24 9.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 23
10.2. New Media Type . . . . . . . . . . . . . . . . . . . . . 24 9.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . . 24
10.3. New Content Format . . . . . . . . . . . . . . . . . . . 25 9.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 25
11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 25
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 9.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . . 27
13.1. Normative References . . . . . . . . . . . . . . . . . . 26 9.2.4. Handling Recovery using M-bit Set . . . . . . . . . . 28
13.2. Informative References . . . . . . . . . . . . . . . . . 28 9.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 29
Appendix A. Examples with Confirmable Messages . . . . . . . . . 29 9.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 29
A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 29 9.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 30
A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 30 9.3.3. Handling Recovery . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
10.1. New CoAP Options . . . . . . . . . . . . . . . . . . . . 33
10.2. New Media Type . . . . . . . . . . . . . . . . . . . . . 34
10.3. New Content Format . . . . . . . . . . . . . . . . . . . 35
11. Security Considerations . . . . . . . . . . . . . . . . . . . 36
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
13.1. Normative References . . . . . . . . . . . . . . . . . . 36
13.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Examples with Confirmable Messages . . . . . . . . . 39
A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 39
A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
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,
skipping to change at page 7, line 6 skipping to change at page 7, line 21
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, FETCH, Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH,
PATCH, and iPATCH requests and their responses (2.01 and 2.04). PATCH, and iPATCH requests and their responses.
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.02,
2.04, and 2.05) (Section 5.5 of [RFC7252]). 2.03, 2.04, and 2.05) (Section 5.5 of [RFC7252]).
However, with methods needing both Q-Block1 for the request and
Q-Block2 for the response, and there is need for recovery following
payload loss, the numbers of packets needed to initiate and complete
the recovery can get very large as a function of the severity of the
experienced loss.
A CoAP endpoint (or proxy) MUST support either both or neither of the A CoAP endpoint (or proxy) MUST support either both or neither of the
Q-Block1 and Q-Block2 Options. Q-Block1 and Q-Block2 Options.
If Q-Block1 Option is present in a request or Q-Block2 Option in a
response (i.e., in that message to the payload of which it pertains),
it indicates a block-wise transfer and describes how this specific
block-wise payload forms part of the entire body being transferred.
If it is present in the opposite direction, it provides additional
control on how that payload will be formed or was processed.
To indicate support for Q-Block2 responses, the CoAP client MUST 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
Option in a PUT or similar request, or the Q-Block1 Option in a PUT Option in a PUT or similar request, or the Q-Block1 Option in a PUT
or similar so that the server knows that the client supports this or similar so that the server knows that the client supports this
Q-Block2 functionality should it need to send back a body that spans Q-Block2 functionality should it need to send back a body that spans
multiple payloads. Otherwise, the server would use the Block2 Option multiple payloads. Otherwise, the server would use the Block2 Option
(if supported) to send back a message body that is too large to fit (if supported) to send back a message body that is too large to fit
into a single IP packet [RFC7959]. into a single IP packet [RFC7959].
If Q-Block1 Option is present in a request or Q-Block2 Option in a
response (i.e., in that message to the payload of which it pertains),
it indicates a block-wise transfer and describes how this specific
block-wise payload forms part of the entire body being transferred.
If it is present in the opposite direction, it provides additional
control on how that payload will be formed or was processed.
Implementation of the Q-Block1 and Q-Block2 Options is intended to be Implementation of the Q-Block1 and Q-Block2 Options is intended to be
optional. However, when it is present in a CoAP message, it MUST be optional. However, when it is present in a CoAP message, it MUST be
processed (or the message rejected). Therefore, Q-Block1 and processed (or the message rejected). Therefore, Q-Block1 and
Q-Block2 Options are identified as Critical options. Q-Block2 Options are identified as Critical options.
With CoAP over UDP, the way a request message is rejected for
critical options depends on the message type. A Confirmable message
with an unrecognized critical option is rejected with a 4.02 (Bad
Option) response (Section 5.4.1 of [RFC7252]). A Non-confirmable
message with an unrecognized critical option is either rejected with
a Reset message or just silently ignored (Sections 5.4.1 and 4.3 of
[RFC7252]). To reliably get a rejection message, it is therefore
REQUIRED that clients use a Confirmable message for determining
support for Q-Block1 and Q-Block2 Options.
The Q-Block1 and Q-Block2 Options are unsafe to forward. That is, a The Q-Block1 and Q-Block2 Options are unsafe to forward. That is, a
CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option
MUST reject the request or response that uses either option. MUST reject the request or response that uses either option.
The Q-Block2 Option is repeatable when requesting retransmission of The Q-Block2 Option is repeatable when requesting retransmission of
missing blocks, but not otherwise. Except that case, any request missing blocks, but not otherwise. Except that case, any request
carrying multiple Q-Block1 (or Q-Block2) Options MUST be handled carrying multiple Q-Block1 (or Q-Block2) Options MUST be handled
following the procedure specified in Section 5.4.5 of [RFC7252]. following the procedure specified in Section 5.4.5 of [RFC7252].
The Q-Block1 and Q-Block2 Options, like the Block1 and Block2 The Q-Block1 and Q-Block2 Options, like the Block1 and Block2
Options, 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 (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 |
+========+=================+===+===+ +========+=================+===+===+
skipping to change at page 9, line 8 skipping to change at page 9, line 41
that it is unique for every different body of transmitted data. that it is unique for every different body of transmitted data.
Implementation Note: It is suggested that the client treats the Implementation Note: It is suggested that the client treats the
Request-Tag as an unsigned integer of 8 bytes in length. An Request-Tag as an unsigned integer of 8 bytes in length. An
implementation may want to consider limiting this to 4 bytes to implementation may want to consider limiting this to 4 bytes to
reduce packet overhead size. The initial Request-Tag value should reduce packet overhead size. The initial Request-Tag value should
be randomly generated and then subsequently incremented by the be randomly generated and then subsequently incremented by the
client whenever a new body of data is being transmitted between client whenever a new body of data is being transmitted between
peers. peers.
Section 3.6 discusses the use of Size1 Option. Section 3.7 discusses the use of Size1 Option.
For Confirmable transmission, the server continues to acknowledge For Confirmable transmission, the server continues to acknowledge
each packet, but a response is not required (whether separate or each packet, but a response is not required (whether separate or
piggybacked) until successful receipt of the body or, if some of the piggybacked) until successful receipt of the body or, if some of the
payloads are sent as Non-confirmable and have not arrived, a payloads are sent as Non-confirmable and have not arrived, a
retransmit missing payloads response is needed. 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
Section 5). (Section 5).
The client MUST send the payloads with the block numbers increasing, The client MUST send the payloads with the block numbers increasing,
starting from zero, until the body is complete (subject to any starting from zero, until the body is complete (subject to any
congestion control (Section 6)). Any missing payloads requested by congestion control (Section 6)). Any missing payloads requested by
the server must in addition be separately transmitted with increasing the server must in addition be separately transmitted with increasing
block numbers. block numbers.
The following Response Codes are used: The following Response Codes are used:
2.01 (Created) 2.01 (Created)
This Response Code indicates successful receipt of the entire body This Response Code indicates successful receipt of the entire body
and the resource was created. and the resource was created. The token used SHOULD be from the
last received payload. The client should then release all of the
tokens used for this body.
2.02 (Deleted)
This Response Code indicates successful receipt of the entire body
and the resource was deleted when using POST (Section 5.8.2
[RFC7252]). The token used SHOULD be from the last received
payload. The client should then release all of the tokens used
for this body.
2.04 (Changed) 2.04 (Changed)
This Response Code indicates successful receipt of the entire body This Response Code indicates successful receipt of the entire body
and the resource was updated. and the resource was updated. The token used SHOULD be from the
last received payload. The client should then release all of the
tokens used for this body.
2.05 (Content)
This Response Code indicates successful receipt of the entire
FETCH request body (Section 2 of [RFC8132]) and the appropriate
representation of the resource has been returned. The token used
in the response MUST be the one in the FETCH request that has the
Q-Block1 with the M bit unset. If the FETCH request includes the
Observe Option, then the server MUST use the same token for
returning any Observe triggered responses. The client should then
release all of the tokens used for this body unless a resource is
being observed.
2.31 (Continue) 2.31 (Continue)
This Response Code can be used to indicate that all of the blocks This Response Code can be used to indicate that all of the blocks
up to and including the Q-Block1 Option block NUM (all having the up to and including the Q-Block1 Option block NUM (all having the
M bit set) in the response have been successfully received. M bit set) in the response have been successfully received. The
token used SHOULD be from the last received payload.
A response using this Response Code SHOULD NOT be generated for A response using this Response Code SHOULD NOT be generated for
every received Q-Block1 Option request. It SHOULD only be every received Q-Block1 Option request. It SHOULD only be
generated when all the payload requests are Non-confirmable and generated when all the payload requests are Non-confirmable and
MAX_PAYLOADS payloads have been received by the server MAX_PAYLOADS (Section 6.2) payloads have been received by the
(Section 6.2). server.
It SHOULD NOT be generated for CON. It SHOULD NOT be generated for CON.
4.00 (Bad Request) 4.00 (Bad Request)
This Response Code MUST be returned if the request does not This Response Code MUST be returned if the request does not
include both a Request-Tag Option and a Size1 Option but does include both a Request-Tag Option and a Size1 Option but does
include a Q-Block1 option. include a Q-Block1 option.
4.02 (Bad Option) 4.02 (Bad Option)
Either this Response Code or a reset message MUST be returned if Either this Response Code or a reset message MUST be returned if
the server does not support the Q-Block1 Option. the server does not support the Q-Block1 Option.
4.08 (Request Entity Incomplete) 4.08 (Request Entity Incomplete)
skipping to change at page 10, line 30 skipping to change at page 11, line 41
missing-blocks+cbor-seq" indicates that some of the payloads are missing-blocks+cbor-seq" indicates that some of the payloads are
missing and need to be resent. The client then retransmits the missing and need to be resent. The client then retransmits the
missing payloads using the same Request-Tag, Size1 and Q-Block1 to missing payloads using the same Request-Tag, Size1 and Q-Block1 to
specify the block number, SZX, and M bit as appropriate. specify the block number, SZX, and M bit as appropriate.
The Request-Tag value to use is determined from the token in the The Request-Tag value to use is determined from the token in the
4.08 (Request Entity Incomplete) response and then finding the 4.08 (Request Entity Incomplete) response and then finding the
matching client request which contains the Request-Tag that is matching client request which contains the Request-Tag that is
being used for this Q-Block1 body. being used for this Q-Block1 body.
The token used in the response SHOULD be from the last received
payload. See Section 4 for further information.
4.13 (Request Entity Too Large) 4.13 (Request Entity Too Large)
This Response Code can be returned under similar conditions to This Response Code can be returned under similar conditions to
those discussed in Section 2.9.3 of [RFC7959]. those discussed in Section 2.9.3 of [RFC7959].
This Response Code can be returned if there is insufficient space This Response Code can be returned if there is insufficient space
to create a response PDU with a block size of 16 bytes (SZX = 0) to create a response PDU with a block size of 16 bytes (SZX = 0)
to send back all the response options as appropriate. In this to send back all the response options as appropriate. In this
case, the Size1 Option is not included. case, the Size1 Option is not included.
skipping to change at page 11, line 21 skipping to change at page 12, line 33
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 ignore the payload of the packet, but MUST still respond as it SHOULD ignore the payload of the packet, but MUST still respond as
if the block was received for the first time. if the block was received for the first time.
A server SHOULD only maintain a partial body (missing payloads) for A server SHOULD only maintain a partial body (missing payloads) for
up to NON_PARTIAL_TIMEOUT (Section 6.2). 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 has
that this is a request for that block and for all of the remaining different meanings based on the NUM value:
blocks within the body. If the request includes multiple Q-Block2
Options and these options overlap (e.g., combination of M being set NUM is zero: This is a request for the entire body.
(this and all the later blocks) and being unset (this individual
block)) resulting in an individual block being requested multiple 'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero:
times, the server MUST only send back one instance of that block.
This behavior is meant to prevent amplification attacks. This is used to confirm that the current set of MAX_PAYLOADS
payloads (the latest one having block number NUM-1) has been
successfully received and that, upon receipt of this request, the
server can continue to send the next set of payloads (the first
one having block number NUM). This is the 'Continue' Q-Block-2.
Any other value of NUM: This is a request for that block and for all
of the remaining blocks in the current MAX_PAYLOADS set.
If the request includes multiple Q-Block2 Options and these options
overlap (e.g., combination of M being set (this and later blocks) and
being unset (this individual block)) resulting in an individual block
being requested multiple times, the server MUST only send back one
instance of that block. This behavior is meant to prevent
amplification attacks.
The payloads sent back from the server as a response MUST all have The payloads sent back from the server as a response MUST all have
the same ETag (Section 5.10.6 of [RFC7252]) for the same body. The the same ETag (Section 5.10.6 of [RFC7252]) for the same body. The
server MUST NOT use the same ETag value for different representations server MUST NOT use the same ETag value for different representations
of a resource. of a resource.
The ETag is opaque, the client still treats it as opaque but the The ETag is opaque, the client still treats it as opaque but the
server SHOULD ensure that it is unique for every different body of server SHOULD ensure that it is unique for every different body of
transmitted data. transmitted data.
Implementation Note: It is suggested that the server treats the Implementation Note: It is suggested that the server treats the
ETag as an unsigned integer of 8 bytes in length. An ETag as an unsigned integer of 8 bytes in length. An
implementation may want to consider limiting this to 4 bytes to implementation may want to consider limiting this to 4 bytes to
reduce packet overhead size. The initial ETag value should be reduce packet overhead size. The initial ETag value should be
randomly generated and then subsequently incremented by the server randomly generated and then subsequently incremented by the server
whenever a new body of data is being transmitted between peers. whenever a new body of data is being transmitted between peers.
Section 3.6 discusses the use of Size2 Option. Section 3.7 discusses the use of Size2 Option.
The client may elect to request any detected missing blocks or just The client may elect to request any detected missing blocks or just
ignore the partial body. This decision is implementation specific. ignore the partial body. This decision is implementation specific.
The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 6.2) The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 6.2)
after the last received payload for NON payloads before issuing a after the last received payload for NON payloads before issuing a
GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or 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 more Q-Block2 Options that define the missing blocks with the M bit
unset. Further considerations related to the transmission timing for unset. It is permissible to set the M bit to request this and
missing requests are discussed in Section 6.2. missing blocks from this MAX_PAYLOADS set. 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.
For Confirmable responses, the client continues to acknowledge each For Confirmable responses, the client continues to acknowledge each
packet. The server will detect failure to send a packet, but the packet. The server will detect failure to send a packet, but the
client can issue, after a MAX_TRANSMIT_SPAN delay, a separate GET, client can issue, after a MAX_TRANSMIT_SPAN delay, a separate GET,
POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as needed. POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as needed.
skipping to change at page 13, line 5 skipping to change at page 14, line 36
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 should remove any partially received body held response, the client should remove any partially received body held
for a previous ETag for that resource as it is unlikely the missing for a previous ETag for that resource as it is unlikely the missing
blocks can be retrieved. blocks can be retrieved.
If there is insufficient space to create a response PDU with a block If there is insufficient space to create a response PDU with a block
size of 16 bytes (SZX = 0) to send back all the response options as size of 16 bytes (SZX = 0) to send back all the response options as
appropriate, a 4.13 (Request Entity Too Large) is returned without appropriate, a 4.13 (Request Entity Too Large) is returned without
the Size1 Option. the Size1 Option.
3.5. Using Observe and Q-Block2 Options 3.5. Using Observe and Q-Block1 Options
As the blocks of the body are sent without waiting for
acknowledgement of the individual blocks, the observe value [RFC7641]
MUST be the same for all the blocks of the same body.
If the server reports any missing payload, the client re-sends the
missing payload(s). Each re-sent payload is treated as a new request
and the Observe Option MUST be included in the request.
If the response (or associated response) uses Q-Block2 Option, and
one of the response payloads is missing, the request for the missing
payload(s) is treated as a new request. The request MUST comprise of
all of the request payloads and the Observe Option MUST NOT be
included in either the request or response.
3.6. Using Observe and Q-Block2 Options
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 and the Observe Option MUST NOT be included. If the ETag Request and the Observe Option MUST NOT be included in either the
value in the response changes, then the previously received partial request or response. If the ETag value in the response changes, then
body should be considered as not fresh and the whole body re- the previously received partial body should be considered as not
requested. fresh and the whole body re-requested.
3.6. Using Size1 and Size2 Options 3.7. 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. Using Q-Block1 and Q-Block2 Options Together 3.8. 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 is The data payload of the 4.08 (Request Entity Incomplete) response is
encoded as a CBOR Sequence [RFC8742]. There are one or more missing encoded as a CBOR Sequence [RFC8742]. It comprises of one or more
CBOR encoded missing block numbers. The missing block numbers MUST CBOR encoded missing block numbers. The missing block numbers MUST
be unique in each 4.08 (Request Entity Incomplete) response when be unique in each 4.08 (Request Entity Incomplete) response when
created by the server; the client SHOULD drop any duplicates in the created by the server; the client SHOULD drop any duplicates in the
same 4.08 (Request Entity Incomplete) response. same 4.08 (Request Entity Incomplete) response.
The Content-Format Option (Section 5.10.3 of [RFC7252]) MUST be used The Content-Format Option (Section 5.10.3 of [RFC7252]) MUST be used
in the 4.08 (Request Entity Incomplete) response. It MUST be set to in the 4.08 (Request Entity Incomplete) response. It MUST be set to
"application/missing-blocks+cbor-seq" (see Section 10.3). "application/missing-blocks+cbor-seq" (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 = [+ missing-block-number] payload = [+ missing-block-number]
; A unique block number not received: ; A unique block number not received:
missing-block-number = uint missing-block-number = uint
Figure 1: Structure of the Missing Blocks Payload Figure 1: Structure of the Missing Blocks Payload
The token to use for the response SHOULD be the token that was used 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 in the last block number received so far with the same Request-Tag
from the same packet SHOULD be included. value. Note that the use of any received token with the same
Request-Tag would work, but providing the one used in the last
received block number will aid any troubleshooting. The client will
use the token to determine what is the previously sent request to
obtain the Request-Tag value to be used.
If the size of the 4.08 (Request Entity Incomplete) response packet If the size of the 4.08 (Request Entity Incomplete) response packet
is larger than that defined by Section 4.6 [RFC7252], then the number is larger than that defined by Section 4.6 [RFC7252], then the number
of missing blocks MUST be limited so that the response can fit into a of 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 other 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]), or alternatively limit the Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit the
skipping to change at page 15, line 51 skipping to change at page 18, line 8
confirmable. confirmable.
It is implementation specific as to whether there should be any It is implementation specific as to whether there should be any
further requests for missing data as there will have been significant further requests for missing data as there will have been significant
transmission failure as individual payloads will have failed after transmission failure as individual payloads will have failed after
MAX_TRANSMIT_SPAN. MAX_TRANSMIT_SPAN.
6.2. Non-confirmable (NON) 6.2. Non-confirmable (NON)
This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT, This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT,
NON_RECEIVE_TIMEOUT, NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and
primarily for use with NON. NON_PARTIAL_TIMEOUT primarily for use with NON.
MAX_PAYLOADS should be configurable with a default value of 10. Both MAX_PAYLOADS should be configurable with a default value of 10. Both
CoAP endpoints SHOULD have the same value (otherwise there will be CoAP endpoints SHOULD have the same value (otherwise there will be
transmission delays in one direction) and the value MAY be negotiated transmission delays in one direction) and the value MAY be negotiated
between the endpoints to a common value by using a higher level between the endpoints to a common value by using a higher level
protocol (out of scope of this document). This is the maximum number protocol (out of scope of this document). This is the maximum number
of payloads that can be transmitted at any one time. of payloads that can be transmitted at any one time.
Note: The default value of 10 is chosen for reasons similar to Note: The default value of 10 is chosen for reasons similar to
those discussed in Section 5 of [RFC6928]. those discussed in Section 5 of [RFC6928].
NON_TIMEOUT is the maximum period of delay between sending sets of NON_TIMEOUT is the maximum period of delay between sending sets of
MAX_PAYLOADS payloads for the same body. NON_TIMEOUT has the same MAX_PAYLOADS payloads for the same body. By default, NON_TIMEOUT has
value as ACK_TIMEOUT (Section 4.8 of [RFC7252]). the same value as ACK_TIMEOUT (Section 4.8 of [RFC7252]).
NON_RECEIVE_TIMEOUT is the maximum time to wait for a missing payload NON_RECEIVE_TIMEOUT is the maximum time to wait for a missing payload
before requesting retransmission. NON_RECEIVE_TIMEOUT has a value of before requesting retransmission. NON_RECEIVE_TIMEOUT has a value of
twice NON_TIMEOUT. twice NON_TIMEOUT.
NON_MAX_RETRANSMIT is the maximum number of times a request for the
retransmission of missing payloads can occur without a response from
the remote peer. After this occurs, the peer SHOULD consider the
body stale and remove all references to it. By default,
NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT (Section 4.8
of [RFC7252]).
NON_PROBING_WAIT is used to limit the potential wait needed NON_PROBING_WAIT is used to limit the potential wait needed
calculated when using PROBING_WAIT. NON_PROBING_WAIT has the same calculated when using PROBING_WAIT. NON_PROBING_WAIT has the same
value as computed for EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). 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 is used for expiring partially received bodies.
NON_PARTIAL_TIMEOUT has the same value as computed for NON_PARTIAL_TIMEOUT has the same value as computed for
EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).
+---------------------+---------------+ +---------------------+---------------+
| Parameter Name | Default Value | | Parameter Name | Default Value |
+=====================+===============| +=====================+===============|
| MAX_PAYLOADS | 10 | | MAX_PAYLOADS | 10 |
| NON_MAX_RETRANSMIT | 4 |
| NON_TIMEOUT | 2 s | | NON_TIMEOUT | 2 s |
| NON_RECEIVE_TIMEOUT | 4 s | | NON_RECEIVE_TIMEOUT | 4 s |
| NON_PROBING_WAIT | 247 s | | NON_PROBING_WAIT | 247 s |
| NON_PARTIAL_TIMEOUT | 247 s | | NON_PARTIAL_TIMEOUT | 247 s |
+---------------------+---------------+ +---------------------+---------------+
Table 3: Derived Protocol Parameters Table 3: Congestion Control 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 single body of blocks will be subjected that does not respond. The single body of blocks will be subjected
to PROBING_RATE (Section 4.7 of [RFC7252]), not the individual to PROBING_RATE (Section 4.7 of [RFC7252]), not the individual
packets. If the wait time between sending bodies that are not being packets. If the wait time between sending bodies that are not being
responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the
gap time is limited to NON_PROBING_WAIT. gap time is limited to NON_PROBING_WAIT.
Note: For the particular DOTS application, PROBING_RATE and other Note: For the particular DOTS application, PROBING_RATE and other
transmission parameters are negotiated between peers. Even when transmission parameters are negotiated between peers. Even when
not negotiated, the DOTS application uses customized defaults as not negotiated, the DOTS application uses customized defaults as
discussed in Section 4.5.2 of [RFC8782]. discussed in Section 4.5.2 of [RFC8782]. Note that MAX_PAYLOADS,
NON_MAX_RETRANSMIT, and NON_TIMEOUT can be negotiated between DOTS
peers as per [I-D.bosh-dots-quick-blocks].
Each NON 4.08 (Request Entity Incomplete) response is subject to Each NON 4.08 (Request Entity Incomplete) response is subject to
PROBING_RATE. PROBING_RATE.
Each NON GET or FETCH request using Q-Block2 Option is subject to Each NON GET or FETCH request using 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
NON_TIMEOUT before sending the next set of payloads to manage NON_TIMEOUT before sending the next set of payloads to manage
potential congestion issues. potential congestion issues.
If the CoAP peer reports at least one payload has not arrived for If the CoAP peer reports at least one payload has not arrived for
each body for at least a 24 hour period and it is known that there 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 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 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 the situation re-evaluated for another 24 hour period until there is
no report of missing payloads under normal operating conditions. no report of missing payloads under normal operating conditions. The
Note that the CoAP peer will not know about the MAX_PAYLOADS change newly derived value for MAX_PAYLOADS should be used for both ends of
until it is reconfigured. As a consequence, the peer may indicate this particular CoAP peer link. Note that the CoAP peer will not
that there are some missing payloads prior to the actual payload know about the MAX_PAYLOADS change until it is reconfigured. As a
being transmitted as all of its MAX_PAYLOADS payloads have not consequence of not being reconfigured, the peer may indicate that
arrived. there are some missing payloads prior to the actual payload being
transmitted as all of its MAX_PAYLOADS payloads have not arrived.
The sending of a set of missing payloads of a body is subject to The sending of a set of missing payloads of a body is subject to
MAX_PAYLOADS set of payloads. MAX_PAYLOADS set of payloads.
For Q-Block1 Option, if the server responds with a 2.31 (Continue) For Q-Block1 Option, if the server responds with a 2.31 (Continue)
Response Code for the latest payload sent, then the client can Response Code for the latest payload sent, then the client can
continue to send the next set of payloads without any delay. If the continue to send the next set of payloads without any delay. If the
server responds with a 4.08 (Request Entity Incomplete) Response server responds with a 4.08 (Request Entity Incomplete) Response
Code, then the missing payloads SHOULD be retransmitted before going Code, then the missing payloads SHOULD be retransmitted before going
into another NON_TIMEOUT delay prior to sending the next set of into another NON_TIMEOUT delay prior to sending the next set of
payloads. payloads.
For the server receiving NON Q-Block1 requests, it SHOULD send back a For the server receiving NON Q-Block1 requests, it SHOULD send back a
2.31 (Continue) or 4.08 (Request Entity Incomplete) Response Code on 2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS
receipt of the last of the MAX_PAYLOADS payloads to prevent the payloads to prevent the client unnecessarily delaying. Otherwise the
client unnecessarily delaying. If the last of the MAX_PAYLOADS server SHOULD delay for NON_RECEIVE_TIMEOUT, before sending the 4.08
payloads does not arrive (or the final payload where the M bit is not (Request Entity Incomplete) Response Code. The NON_RECEIVE_TIMEOUT
set does not arrive), then the server SHOULD delay for delay may be reduced for the first time that this 4.08 (Request
NON_RECEIVE_TIMEOUT before sending the 4.08 (Request Entity Entity Incomplete) is sent if either the last of the MAX_PAYLOADS
Incomplete) Response Code. payloads or the final payload with the M bit unset arrives, but
SHOULD NOT be reduced to zero as packets may arrive in the wrong
order.
It is possible that the client may start transmitting the next set of It is possible that the client may start transmitting the next set of
MAX_PAYLOADS payloads before the server times out on waiting for the MAX_PAYLOADS payloads before the server times out on waiting for the
last of the previous MAX_PAYLOADS payloads. On receipt of the first last of the previous MAX_PAYLOADS payloads. On receipt of the first
payload from the new set of MAX_PAYLOADS payloads, the server SHOULD received payload from the new set of MAX_PAYLOADS payloads, the
send a 4.08 (Request Entity Incomplete) Response Code indicating any server SHOULD send a 4.08 (Request Entity Incomplete) Response Code
missing payloads from any previous MAX_PAYLOADS payloads. Upon indicating any missing payloads from any previous MAX_PAYLOADS
receipt of the 4.08 (Request Entity Incomplete) Response Code, the payloads. Upon receipt of the 4.08 (Request Entity Incomplete)
client SHOULD send the missing payloads before continuing to send the Response Code, the client SHOULD send the missing payloads before
remainder of the MAX_PAYLOADS payloads and then go into another continuing to send the remainder of the MAX_PAYLOADS payloads and
NON_TIMEOUT delay prior to sending the next set of payloads. then go into another NON_TIMEOUT delay prior to sending the next set
of payloads.
For the client receiving NON Q-Block2 responses, it SHOULD send a 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 request for the next set of payloads on receipt of all of the
payloads upon receipt of the last of the MAX_PAYLOADS payloads to MAX_PAYLOADS payloads to prevent the server unnecessarily delaying.
prevent the server unnecessarily delaying the transmission of the Otherwise the client SHOULD delay for NON_RECEIVE_TIMEOUT, before
body. If the last of the MAX_PAYLOADS payloads does not arrive (or sending the request for the missing payloads. The
the final payload where the M bit is not set does not arrive), then NON_RECEIVE_TIMEOUT delay may be reduced for the first time that this
the client SHOULD delay for NON_RECEIVE_TIMEOUT before sending the request is sent if either the last of the MAX_PAYLOADS payloads or
request for the missing payloads. the final payload with the M bit unset arrives, but SHOULD NOT be
reduced to zero as packets may arrive in the wrong order.
The request that the client sends to acknowledge the receipt of all The request that the client sends to acknowledge the receipt of all
the current set of MAX_PAYLOADS payloads SHOULD contain a special the current set of MAX_PAYLOADS payloads is the 'Continue' Q-Block2
case Q-Block2 Option with NUM set to the first block of the next set Option ('NUM modulo MAX_PAYLOADS' is zero, NUM is not zero, and M bit
of MAX_PAYLOADS payloads and the M bit set to 1. The server SHOULD is set (Section 3.4)). The server SHOULD recognize this as a
recognize this special case as a continue request and just continue continue request and just continue the transmission of the body
the transmission of the body (including Observe Option, if (including Observe Option, if appropriate for an unsolicited
appropriate for an unsolicited response) rather than as a request for response) rather than as a request for the remaining missing blocks.
missing blocks.
It is possible that the server may start transmitting the next set of
MAX_PAYLOADS payloads before the client times out on waiting for the
last of the previous MAX_PAYLOADS payloads. Upon receipt of the
first payload from the new set of MAX_PAYLOADS payloads, the client
SHOULD send a request indicating any missing payloads from any
previous set of MAX_PAYLOADS payloads. Upon receipt of such request,
the server SHOULD send the missing payloads before continuing to send
the remainder of the MAX_PAYLOADS payloads and then go into another
NON_TIMEOUT delay prior to sending the next set of payloads.
The client does not need to acknowledge the receipt of the entire The client does not need to acknowledge the receipt of the entire
body. body.
Note: If there is asymmetric traffic loss causing responses to Note: If there is asymmetric traffic loss causing responses to
never get received, a delay of NON_TIMEOUT after every never get received, a delay of NON_TIMEOUT after every
transmission of MAX_PAYLOADS blocks will be observed. The transmission of MAX_PAYLOADS blocks will be observed. The
endpoint receiving the body is still likely to receive the entire endpoint receiving the body is still likely to receive the entire
body. body.
skipping to change at page 20, line 13 skipping to change at page 22, line 46
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
As a reminder, the basic normative requirements on HTTP/CoAP mappings As a reminder, the basic normative requirements on HTTP/CoAP mappings
are defined in Section 10 of [RFC7252]. The implementation are defined in Section 10 of [RFC7252]. The implementation
guidelines for HTTP/CoAP mappings are elaborated in [RFC8075]. guidelines for HTTP/CoAP mappings are elaborated in [RFC8075].
The rules defined in Section 5 of [RFC7959] are to be followed. The rules defined in Section 5 of [RFC7959] are to be followed.
9. Examples of Selective Block Recovery 9. Examples with Non-confirmable Messages
This section provides some sample flows to illustrate the use of This section provides some sample flows to illustrate the use of
Q-Block1 and Q-Block2 Options. Figure 2 lists the conventions that Q-Block1 and Q-Block2 Options with NON. Examples with CON are
are used in the following subsections. provided in Appendix A.
T: Token value Figure 2 lists the conventions that are used in the following
O: Observe Option value subsections.
M: Message ID
RT: Request-Tag T: Token value
ET: ETag O: Observe Option value
QB1: Q-Block1 Option values NUM/More/SZX M: Message ID
QB2: Q-Block2 Option values NUM/More/SZX RT: Request-Tag
\: Trimming long lines ET: ETag
[[]]: Comments QB1: Q-Block1 Option values NUM/More/SZX
-->X: Message loss (request) QB2: Q-Block2 Option values NUM/More/SZX
X<--: Message loss (response) \: Trimming long lines
...: Passage of time [[]]: Comments
-->X: Message loss (request)
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
9.1.1. A Simple 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
| | | |
+--------->| NON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024 +--------->| NON PUT /path M:0x81 T:0xc0 RT=9 QB1:0/1/1024
+--------->| NON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024 +--------->| NON PUT /path M:0x82 T:0xc1 RT=9 QB1:1/1/1024
+--------->| NON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024 +--------->| NON PUT /path M:0x83 T:0xc2 RT=9 QB1:2/1/1024
+--------->| NON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024 +--------->| NON PUT /path M:0x84 T:0xc3 RT=9 QB1:3/0/1024
|<---------+ NON 2.04 M:0xf1 T:0xf3 |<---------+ NON 2.04 M:0xf1 T:0xc3
| ... | | ... |
Figure 3: Example of NON Request with Q-Block1 Option (Without Loss) Figure 3: Example of NON Request with Q-Block1 Option (Without Loss)
9.1.2. Handling MAX_PAYLOADS Limits
Figure 4 depicts an example of a NON PUT request conveying Q-Block1
Option. The number of payloads exceeds MAX_PAYLOADS. All the blocks
are received by the server.
CoAP CoAP
Client Server
| |
+--------->| NON PUT /path M:0x01 T:0xf1 RT=10 QB1:0/1/1024
+--------->| NON PUT /path M:0x02 T:0xf2 RT=10 QB1:1/1/1024
+--------->| [[Payloads 3 - 9 not detailed]]
+--------->| NON PUT /path M:0x0a T:0xfa RT=10 QB1:9/1/1024
[[MAX_PAYLOADS has been reached]]
| [[MAX_PAYLOADS blocks receipt acknowledged by server]]
|<---------+ NON 2.31 M:0x81 T:0xfa
+--------->| NON PUT /path M:0x0b T:0xfb RT=10 QB1:10/0/1024
|<---------+ NON 2.04 M:0x82 T:0xfb
| ... |
Figure 4: Example of MAX_PAYLOADS NON Request with Q-Block1 Option
(Without Loss)
9.1.3. Handling MAX_PAYLOADS with Recovery
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 5.
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:0x11 T:0xe1 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:0x12 T:0xe2 RT=11 QB1:1/1/1024
+--->X | NON PUT /path M:0x07 T:0xe2 RT=11 QB1:2/1/1024 +--------->| [[Payloads 3 - 8 not detailed]]
+--------->| NON PUT /path M:0x08 T:0xe3 RT=11 QB1:3/0/1024 +--------->| NON PUT /path M:0x19 T:0xe9 RT=11 QB1:8/1/1024
+--->X | NON PUT /path M:0x1a T:0xea RT=11 QB1:9/1/1024
[[MAX_PAYLOADS has been reached]]
| ... | | ... |
[[NON_TIMEOUT (client) delay expires]]
| [[Client starts sending next set of payloads]]
+--->X | NON PUT /path M:0x1b T:0xeb RT=11 QB1:10/1/1024
+--------->| NON PUT /path M:0x1c T:0xec RT=11 QB1:11/1/1024
| |
Figure 4: Example of NON Request with Q-Block1 Option (With Loss) Figure 5: Example of MAX_PAYLOADS NON Request with Q-Block1 Option
(With Loss)
The server realizes that some blocks are missing and asks for the On seeing a payload from the next set of payloads, the server
missing ones in one go (Figure 5). It does so by indicating which realizes that some blocks are missing from the previous MAX_PAYLOADS
blocks have been received in the data portion of the response. The payloads and asks for the missing blocks in one go (Figure 6). It
Token just needs to be one of those that have been received for this does so by indicating which blocks have not been received in the data
Request-Tag, so the client can derive the Request-Tag. portion of the response. The token used in the response should be
the token that was used in the last block number received payload.
CoAP CoAP The client can then derive the Request-Tag by matching the token with
Client Server the sent request.
| ... |
|<---------+ 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
+--->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
one]]
|<---------+ 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 2.04 M:0xf4 T:0xe6
| ... |
Figure 5: Example of NON Request with Q-Block1 Option (Blocks CoAP CoAP
Client Server
| |
|<---------+ NON 4.08 M:0x91 T:0xec [Missing 1,9 [for RT=11]]
| [[Client responds with missing payloads]]
+--------->| NON PUT /path M:0x1d T:0xed RT=11 QB1:1/1/1024
+--------->| NON PUT /path M:0x1e T:0xee RT=11 QB1:9/1/1024
| [[Client continues sending next set of payloads]]
+--------->| NON PUT /path M:0x1f T:0xef RT=11 QB1:12/0/1024
| ... |
[[NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[The server realizes a block is still missing and asks
| for the missing one]]
|<---------+ NON 4.08 M:0x92 T:0xef [Missing 10 [for RT=11]]
+--------->| NON PUT /path M:0x20 T:0xf0 RT=11 QB1:10/1/1024
|<---------+ NON 2.04 M:0x93 T:0xf0
| ... |
Figure 6: Example of NON Request with Q-Block1 Option (Blocks
Recovery) 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 by "forgetting" all the tracked tokens sending missing blocks of data by "forgetting" all the tracked tokens
for this Request-Tag. This decision is implementation specific. for this Request-Tag. Similarly, the server can elect to not to
continue asking for missing blocks. Both these decisions are
implementation specific.
9.2. Q-Block2 Option: Non-Confirmable Example 9.2. Q-Block2 Option
Figure 6 illustrates the example of Q-Block2 Option. The client 9.2.1. A Simple Example
sends a NON GET carrying an Observe and a Q-Block2 Options. The
Q-Block2 Option indicates a block size hint (1024 bytes). This Figure 7 illustrates the example of Q-Block2 Option. The client
request is replied to by the server using four (4) blocks that are sends a NON GET carrying Observe and Q-Block2 Options. The Q-Block2
transmitted to the client without any loss. Each of these blocks Option indicates a block size hint (1024 bytes). This request is
carries a Q-Block2 Option. The same process is repeated when an replied to by the server using four (4) blocks that are transmitted
Observe is triggered, but no loss is experienced by any of the to the client without any loss. Each of these blocks carries a
notification blocks. Q-Block2 Option. The same process is repeated when an Observe is
triggered, but no loss is experienced by any of the notification
blocks.
CoAP CoAP 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:0xc0 O:0 QB2:0/1/1024
|<---------+ NON 2.05 M:0xf1 T:0xf0 O:1234 ET=21 QB2:0/1/1024 |<---------+ NON 2.05 M:0xf1 T:0xc0 O:1220 ET=19 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:0xc0 O:1220 ET=19 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:0xc0 O:1220 ET=19 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:0xc0 O:1220 ET=19 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:0xc0 O:1221 ET=20 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:0xc0 O:1221 ET=20 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:0xc0 O:1221 ET=20 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:0xc0 O:1221 ET=20 QB2:3/0/1024
| ... | | ... |
Figure 6: Example of NON Notifications with Q-Block2 Option (Without Figure 7: Example of NON Notifications with Q-Block2 Option (Without
Loss) Loss)
Figure 7 shows the example of an Observe that is triggered but for 9.2.2. Handling MAX_PAYLOADS Limits
Figure 8 illustrates the same as Figure 7 but this time has eleven
(11) payloads which exceeds MAX_PAYLOADS. There is no loss
experienced.
CoAP CoAP
Client Server
| |
+--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024
|<---------+ NON 2.05 M:0x81 T:0xf0 O:1234 ET=21 QB2:0/1/1024
|<---------+ NON 2.05 M:0x82 T:0xf0 O:1234 ET=21 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0x8a T:0xf0 O:1234 ET=21 QB2:9/1/1024
[[MAX_PAYLOADS has been reached]]
| [[MAX_PAYLOADS blocks acknowledged by client using
| 'Continue' Q-Block2]]
+--------->| NON GET /path M:0x02 T:0xf1 QB2:10/1/1024
|<---------+ NON 2.05 M:0x8b T:0xf0 O:1234 ET=21 QB2:10/0/1024
| ... |
| [[Observe triggered]]
|<---------+ NON 2.05 M:0x91 T:0xf0 O:1235 ET=22 QB2:0/1/1024
|<---------+ NON 2.05 M:0x92 T:0xf0 O:1235 ET=22 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0x9a T:0xf0 O:1235 ET=22 QB2:9/1/1024
[[MAX_PAYLOADS has been reached]]
| [[MAX_PAYLOADS blocks acknowledged by client using
| 'Continue' Q-Block2]]
+--------->| NON GET /path M:0x03 T:0xf2 QB2:10/1/1024
|<---------+ NON 2.05 M:0x9b T:0xf0 O:1235 ET=22 QB2:10/0/1024
[[Body has been received]]
| ... |
Figure 8: Example of NON Notifications with Q-Block2 Option (Without
Loss)
9.2.3. Handling MAX_PAYLOADS with Recovery
Figure 9 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:0xa1 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:0xa2 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 |<---------+ [[Payloads 3 - 8 not detailed]]
|<---------+ NON 2.05 M:0xfc T:0xf0 O:1236 ET=23 QB2:3/0/1024 | X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024
| ... | [[MAX_PAYLOADS has been reached]]
[[Client realizes blocks are missing and asks for the missing | ... |
ones in one go]] [[NON_TIMEOUT (server) delay expires]]
+--------->| NON GET /path M:0x02 T:0xf1 QB2:1/0/1024\ | [[Server sends next set of payloads]]
| | QB2:2/0/1024 |<---------+ NON 2.05 M:0xab T:0xf0 O:1236 ET=23 QB2:10/0/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_RECEIVE_TIMEOUT (client) delay expires]]
| ... | | [[Client realizes blocks are missing and asks for the
[[Get the final missing block]] | missing ones in one go]]
+--------->| NON GET /path M:0x03 T:0xf2 QB2:1/0/1024 +--------->| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\
|<---------+ NON 2.05 M:0xff T:0xf2 ET=23 QB2:1/1/1024 | | QB2:9/0/1024
| ... | | X<---+ NON 2.05 M:0xac T:0xf3 ET=23 QB2:1/1/1024
|<---------+ NON 2.05 M:0xad T:0xf3 ET=23 QB2:9/1/1024
| ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]]
| [[Client realizes block is still missing and asks for
| missing block]]
+--------->| NON GET /path M:0x05 T:0xf4 QB2:1/0/1024
|<---------+ NON 2.05 M:0xae T:0xf4 ET=23 QB2:1/1/1024
[[Body has been received]]
| ... |
Figure 7: Example of NON Notifications with Q-Block2 Option (Blocks Figure 9: 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 9.2.4. Handling Recovery using M-bit Set
the first two notification blocks reaches the client. In order to
Figure 10 shows the example of an Observe that is triggered but only
the first two notification blocks reach the client. In order to
retrieve the missing blocks, the client sends a request with a single 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:0xb1 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:0xb2 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:0xb3 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<---+ [[Payloads 4 - 9 not detailed]]
| ... | | X<---+ NON 2.05 M:0xb9 T:0xf0 O:1237 ET=24 QB2:9/1/1024
[[Client realizes blocks are missing and asks for the remaining missing [[MAX_PAYLOADS has been reached]]
ones in one go by setting the M bit]] | ... |
+--------->| NON GET /path M:0x03 T:0xf3 QB2:2/1/1024 [[NON_TIMEOUT (server) delay expires]]
|<---------+ NON 2.05 M:0x127 T:0xf3 ET=24 QB2:2/1/1024 | [[Server sends next set of payloads]]
|<---------+ NON 2.05 M:0x128 T:0xf3 ET=24 QB2:3/0/1024 | X<---+ NON 2.05 M:0xba T:0xf0 O:1237 ET=24 QB2:10/0/1024
| ... | | ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]]
| [[Client realizes blocks are missing and asks for the
| missing ones in one go by setting the M bit]]
+--------->| NON GET /path M:0x06 T:0xf5 QB2:2/1/1024
|<---------+ NON 2.05 M:0xbb T:0xf5 ET=24 QB2:2/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0xc2 T:0xf5 ET=24 QB2:9/1/1024
[[MAX_PAYLOADS has been reached]]
| [[MAX_PAYLOADS acknowledged by client using 'Continue'
| Q-Block2]]
+--------->| NON GET /path M:0x87 T:0xf6 QB2:10/1/1024
|<---------+ NON 2.05 M:0xc3 T:0xf0 O:1237 ET=24 QB2:10/0/1024
[[Body has been received]]
| ... |
Figure 8: Example of NON Notifications with Q-Block2 Option (Blocks Figure 10: Example of NON Notifications with Q-Block2 Option (Blocks
Recovery with M bit Set) Recovery with M bit Set)
9.3. Q-Block1 and Q-Block2 Options
9.3.1. A Simple Example
Figure 11 illustrates the example of a FETCH using both Q-Block1 and
Q-Block2 Options along with an Observe Option. No loss is
experienced.
CoAP CoAP
Client Server
| |
+--------->| NON FETCH /path M:0x10 T:0x90 O:0 RT=30 QB1:0/1/1024
+--------->| NON FETCH /path M:0x11 T:0x91 O:0 RT=30 QB1:1/1/1024
+--------->| NON FETCH /path M:0x12 T:0x93 O:0 RT=30 QB1:2/0/1024
|<---------+ NON 2.05 M:0x60 T:0x93 O:1320 ET=90 QB2:0/1/1024
|<---------+ NON 2.05 M:0x61 T:0x93 O:1320 ET=90 QB2:1/1/1024
|<---------+ NON 2.05 M:0x62 T:0x93 O:1320 ET=90 QB2:2/1/1024
|<---------+ NON 2.05 M:0x63 T:0x93 O:1320 ET=90 QB2:3/0/1024
| ... |
| [[Observe triggered]]
|<---------+ NON 2.05 M:0x64 T:0x93 O:1321 ET=91 QB2:0/1/1024
|<---------+ NON 2.05 M:0x65 T:0x93 O:1321 ET=91 QB2:1/1/1024
|<---------+ NON 2.05 M:0x66 T:0x93 O:1321 ET=91 QB2:2/1/1024
|<---------+ NON 2.05 M:0x67 T:0x93 O:1321 ET=91 QB2:3/0/1024
| ... |
Figure 11: Example of NON FETCH with Q-Block1 and Q-Block2 Options
(Without Loss)
9.3.2. Handling MAX_PAYLOADS Limits
Figure 12 illustrates the same as Figure 11 but this time has eleven
(11) payloads in both directions which exceeds MAX_PAYLOADS. There
is no loss experienced.
CoAP CoAP
Client Server
| |
+--------->| NON FETCH /path M:0x30 T:0xa0 O:0 RT=10 QB1:0/1/1024
+--------->| NON FETCH /path M:0x31 T:0xa1 O:0 RT=10 QB1:1/1/1024
+--------->| [[Payloads 3 - 9 not detailed]]
+--------->| NON FETCH /path M:0x39 T:0xa9 O:0 RT=10 QB1:9/1/1024
[[MAX_PAYLOADS has been reached]]
| [[MAX_PAYLOADS blocks receipt acknowledged by server]]
|<---------+ NON 2.31 M:0x80 T:0xa9
+--------->| NON FETCH /path M:0x3a T:0xaa O:0 RT=10 QB1:10/0/1024
|<---------+ NON 2.05 M:0x81 T:0xaa O:1334 ET=21 QB2:0/1/1024
|<---------+ NON 2.05 M:0x82 T:0xaa O:1334 ET=21 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0x8a T:0xaa O:1334 ET=21 QB2:9/1/1024
[[MAX_PAYLOADS has been reached]]
| [[MAX_PAYLOADS blocks acknowledged by client using
| 'Continue' Q-Block2]]
+--------->| NON FETCH /path M:0x3b T:0xab QB2:10/1/1024
|<---------+ NON 2.05 M:0x8b T:0xaa O:1334 ET=21 QB2:10/0/1024
| ... |
| [[Observe triggered]]
|<---------+ NON 2.05 M:0x8c T:0xaa O:1335 ET=22 QB2:0/1/1024
|<---------+ NON 2.05 M:0x8d T:0xaa O:1335 ET=22 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0x95 T:0xaa O:1335 ET=22 QB2:9/1/1024
[[MAX_PAYLOADS has been reached]]
| [[MAX_PAYLOADS blocks acknowledged by client using
| 'Continue' Q-Block2]]
+--------->| NON FETCH /path M:0x3c T:0xac QB2:10/1/1024
|<---------+ NON 2.05 M:0x96 T:0xaa O:1335 ET=22 QB2:10/0/1024
[[Body has been received]]
| ... |
Figure 12: Example of NON FETCH with Q-Block1 and Q-Block2 Options
(Without Loss)
9.3.3. Handling Recovery
Consider now a scenario where there are some blocks are lost in
transmission as illustrated in Figure 13.
CoAP CoAP
Client Server
| |
+--------->| NON FETCH /path M:0x50 T:0xc0 O:0 RT=31 QB1:0/1/1024
+--->X | NON FETCH /path M:0x51 T:0xc1 O:0 RT=31 QB1:1/1/1024
+--->X | NON FETCH /path M:0x52 T:0xc2 O:0 RT=31 QB1:2/1/1024
+--------->| NON FETCH /path M:0x53 T:0xc3 O:0 RT=31 QB1:3/0/1024
| ... |
[[NON_RECEIVE_TIMEOUT (server) delay expires]]
Figure 13: Example of NON FETCH with Q-Block1 and Q-Block2 Options
(With Loss)
The server realizes that some blocks are missing and asks for the
missing blocks in one go (Figure 14). It does so by indicating which
blocks have not been received in the data portion of the response.
The token used in the response is be the token that was used in the
last block number received payload. The client can then derive the
Request-Tag by matching the token with the sent request.
CoAP CoAP
Client Server
| |
|<---------+ NON 4.08 M:0xa0 T:0xc3 [Missing 1,2 [for RT=31]]
| [[Client responds with missing payloads]]
+--------->| NON FETCH /path M:0x54 T:0xc4 O:0 RT=31 QB1:1/1/1024
+--------->| NON FETCH /path M:0x55 T:0xc5 O:0 RT=31 QB1:2/1/1024
| [[Server received FETCH body,
| starts transmitting response body]]
|<---------+ NON 2.05 M:0xa1 T:0xc3 O:1236 ET=23 QB2:0/1/1024
| X<---+ NON 2.05 M:0xa2 T:0xc3 O:1236 ET=23 QB2:1/1/1024
|<---------+ NON 2.05 M:0xa3 T:0xc3 O:1236 ET=23 QB2:2/1/1024
| X<---+ NON 2.05 M:0xa4 T:0xc3 O:1236 ET=23 QB2:3/0/1024
| ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]]
| |
Figure 14: Example of NON Request with Q-Block1 Option (Server
Recovery)
The client realizes that not all the payloads of the response have
been returned. The client then asks for the missing blocks in one go
(Figure 15). However, because the original request is spread over
multiple payloads using Q-Block1, the entire FETCH body has to be
used to make the request for the missing payloads.
CoAP CoAP
Client Server
| |
+--------->| NON FETCH /path M:0x56 T:0xc6 RT=31 QB1:0/1/1024\
| | QB2:1/0/1024\
| | QB2:3/0/1024
+--------->| NON FETCH /path M:0x57 T:0xc7 RT=31 QB1:1/1/1024\
| | QB2:1/0/1024\
| | QB2:3/0/1024
+--------->| NON FETCH /path M:0x58 T:0xc8 RT=31 QB1:2/1/1024\
| | QB2:1/0/1024\
| | QB2:3/0/1024
+--------->| NON FETCH /path M:0x59 T:0xc9 RT=31 QB1:3/0/1024\
| | QB2:1/0/1024\
| | QB2:3/0/1024
| [[Server received FETCH request,
| starts transmitting missing blocks]]
| X<---+ NON 2.05 M:0xa5 T:0xc9 ET=23 QB2:1/1/1024
|<---------+ NON 2.05 M:0xa6 T:0xc9 ET=23 QB2:3/0/1024
| ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]]
| [[Client realizes block is still missing and asks for
| missing block]]
+--------->| NON FETCH /path M:0x5a T:0xca RT=31 QB1:0/1/1024\
| | QB2:1/0/1024
+--------->| NON FETCH /path M:0x5b T:0xcb RT=31 QB1:1/1/1024\
| | QB2:1/0/1024
+--------->| NON FETCH /path M:0x5c T:0xcc RT=31 QB1:2/1/1024\
| | QB2:1/0/1024
+--------->| NON FETCH /path M:0x5d T:0xcd RT=31 QB1:3/0/1024\
| | QB2:1/0/1024
| [[Server received FETCH request,
| starts transmitting missing block]]
|<---------+ NON 2.05 M:0xa7 T:0xcd ET=23 QB2:1/1/1024
[[Body has been received]]
| ... |
Figure 15: Example of NON Request with Q-Block1 Option (Client
Recovery)
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 |
+========+==================+===========+ +========+==================+===========+
skipping to change at page 25, line 5 skipping to change at page 35, line 5
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 Media Type 10.2. New Media Type
This document requests IANA to register the "application/missing- This document requests IANA to register the "application/missing-
blocks+cbor-seq" media type in the "Media Types" registry blocks+cbor-seq" media type in the "Media Types" registry
[IANA-MediaTypes]: [IANA-MediaTypes]:
Type name: application Type name: application
Subtype name: missing-blocks+cbor-seq Subtype name: missing-blocks+cbor-seq
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: binary Encoding considerations: binary
Security considerations: See the Security Considerations Section of Security considerations: See the Security Considerations Section of
[This_Document]. [This_Document].
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: [This_Document] Published specification: [This_Document]
Applications that use this media type: Data serialization and deserialization. Applications that use this media type: Data serialization and
deserialization.
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Additional information:
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
Magic number(s): N/A Magic number(s): N/A
File extension(s): N/A File extension(s): N/A
Macintosh file type code(s): N/A Macintosh file type code(s): N/A
Person & email address to contact for further information: IETF, Person & email address to contact for further information: IETF,
iesg@ietf.org iesg@ietf.org
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author: See Authors' Addresses section. Author: See Authors' Addresses section.
Change controller: IESG Change controller: IESG
Provisional registration? No Provisional registration? No
10.3. New Content Format 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
skipping to change at page 26, line 36 skipping to change at page 36, line 36
applications need to consider that certain message fields and applications need to consider that certain message fields and
messages types are not protected end-to-end and may be spoofed or messages types are not protected end-to-end and may be spoofed or
manipulated. It is NOT RECOMMENDED that the NoSec security mode is manipulated. It is NOT RECOMMENDED that the NoSec security mode is
used if the Q-Block1 and Q-Block2 Options are to be used. 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, Michael Richardson, and Marco Thanks to Achim Kraus, Jim Schaad, and Michael Richardson for their
Tiloca for the comments. comments.
Special thanks to Christian Amsuess and Carsten Bormann for their Special thanks to Christian Amsuess, Carsten Bormann, and Marco
suggestions and several reviews, which improved this specification Tiloca for their suggestions and several reviews, which improved this
significantly. specification 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-
skipping to change at page 28, line 19 skipping to change at page 38, line 19
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <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.bosh-dots-quick-blocks]
Boucadair, M. and J. Shallow, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Signal Channel
Configuration Attributes for Faster Block Transmission",
draft-bosh-dots-quick-blocks-00 (work in progress),
January 2021.
[I-D.ietf-dots-telemetry] [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-MediaTypes]
IANA, "Media Types", IANA, "Media Types",
<https://www.iana.org/assignments/media-types>. <https://www.iana.org/assignments/media-types>.
skipping to change at page 29, line 15 skipping to change at page 39, line 21
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 9. All the blocks are acknowledged (ACK). shown in Figure 16. 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 9: Example of CON Request with Q-Block1 Option (Without Loss) Figure 16: 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 be sent but with some
dropped in transmission as illustrated in Figure 10. The client will blocks dropped in transmission as illustrated in Figure 17. The
retry sending blocks for which no ACK was received. client will 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
|<---------+ ACK 0.00 M:0x08 |<---------+ ACK 0.00 M:0x08
| ... | | ... |
[[The client retries sending packets not acknowledged]] [[ACK_TIMEOUT (client) delay expires]]
| [[Client retransmits associated packet]]
+--------->| 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 [[ACK_TIMEOUT exponential backoff (client) delay expires]]
(exponential backoff)]] | [[Client retransmits associated packet]]
+--->? | 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 body 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 17: Example of CON Request with Q-Block1 Option (Blocks
Recovery) Recovery)
It is up to the implementation as to whether the application process It is up to the implementation as to whether the application process
stops trying to send this particular body of data on reaching stops trying to send this particular body of data on reaching
MAX_RETRANSMIT for any payload, or separately tries to initiate the MAX_RETRANSMIT for any payload, or separately tries to initiate the
new transmission of the payloads that have not been acknowledged new transmission of the payloads that have not been acknowledged
under these adverse traffic conditions. under these adverse traffic conditions.
If there is likely to be the possibility of network transient losses, If there is likely to be the possibility of network transient losses,
then the use of NON should be considered. then the use of NON should be considered.
A.2. Q-Block2 Option A.2. Q-Block2 Option
An example of the use of Q-Block2 Option with Confirmable messages is An example of the use of Q-Block2 Option with Confirmable messages is
shown in Figure 11. shown in Figure 18.
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]] [[ACK_TIMEOUT (server) delay expires (twice in this example)]]
|<---------+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 | [[Server retransmits associated packet]]
| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 |<---------+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024
|--------->+ ACK 0.00 M:0xe9 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
| ... | |--------->+ ACK 0.00 M:0xe9
| [[Server retransmits messages not acknowledged | ... |
| (exponential backoff)]] [[ACK_TIMEOUT exponential backoff (server) delay expires]]
| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 | [[Server retransmits associated packet]]
| ... | | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
[[Either body transmission failure (acknowledge retry timeout) | ... |
or successfully transmitted.]] [[Either body transmission failure (acknowledge retry timeout)
or successfully transmitted.]]
Figure 11: Example of CON Notifications with Q-Block2 Option Figure 18: Example of CON Notifications with Q-Block2 Option
It is up to the implementation as to whether the application process It is up to the implementation as to whether the application process
stops trying to send this particular body of data on reaching stops trying to send this particular body of data on reaching
MAX_RETRANSMIT for any payload, or separately tries to initiate the MAX_RETRANSMIT for any payload, or separately tries to initiate the
new transmission of the payloads that have not been acknowledged new transmission of the payloads that have not been acknowledged
under these adverse traffic conditions. under these adverse traffic conditions.
If there is likely to be the possibility of network transient losses, If there is likely to be the possibility of network transient losses,
then the use of NON should be considered. then the use of NON should be considered.
 End of changes. 98 change blocks. 
297 lines changed or deleted 702 lines changed or added

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