draft-ietf-core-new-block-05.txt   draft-ietf-core-new-block-06.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 17, 2021 January 13, 2021 Expires: July 23, 2021 January 19, 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-05 draft-ietf-core-new-block-06
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 17, 2021. This Internet-Draft will expire on July 23, 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 18 skipping to change at page 2, line 18
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 . . . . . . . 9
3.3. Using the Q-Block1 Option . . . . . . . . . . . . . . . . 9 3.3. Using the Q-Block1 Option . . . . . . . . . . . . . . . . 9
3.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 12 3.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 13
3.5. Using Observe and Q-Block1 Options . . . . . . . . . . . 14 3.5. Using Observe Option . . . . . . . . . . . . . . . . . . 15
3.6. Using Observe and Q-Block2 Options . . . . . . . . . . . 15 3.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 15
3.7. Using Size1 and Size2 Options . . . . . . . . . . . . . . 15 3.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 15
3.8. Using Q-Block1 and Q-Block2 Options Together . . . . . . 15 3.8. Using Q-Block2 Option With Multicast . . . . . . . . . . 16
4. The Use of 4.08 (Request Entity Incomplete) Response Code . . 15 4. The Use of 4.08 (Request Entity Incomplete) Response Code . . 16
5. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 17 5. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 17
6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 17 6. Congestion Control for Unreliable Transports . . . . . . . . 18
6.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 17 6.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 18
6.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 18 6.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 18
7. Caching Considerations . . . . . . . . . . . . . . . . . . . 21 7. Caching Considerations . . . . . . . . . . . . . . . . . . . 22
8. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 22 8. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 23
9. Examples with Non-confirmable Messages . . . . . . . . . . . 22 9. Examples with Non-confirmable Messages . . . . . . . . . . . 23
9.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 23 9.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 23
9.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 23 9.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 23
9.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 23 9.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 24
9.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . . 24 9.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . . 24
9.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 25 9.1.4. Handling Recovery with Failure . . . . . . . . . . . 26
9.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 25 9.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 26
9.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 26 9.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 27
9.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . . 27 9.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 27
9.2.4. Handling Recovery using M-bit Set . . . . . . . . . . 28 9.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . . 28
9.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 29 9.2.4. Handling Recovery using M-bit Set . . . . . . . . . . 29
9.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 29 9.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 30
9.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 30 9.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 30
9.3.3. Handling Recovery . . . . . . . . . . . . . . . . . . 31 9.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 31
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 9.3.3. Handling Recovery . . . . . . . . . . . . . . . . . . 32
10.1. New CoAP Options . . . . . . . . . . . . . . . . . . . . 33 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
10.2. New Media Type . . . . . . . . . . . . . . . . . . . . . 34 10.1. New CoAP Options . . . . . . . . . . . . . . . . . . . . 34
10.3. New Content Format . . . . . . . . . . . . . . . . . . . 35 10.2. New Media Type . . . . . . . . . . . . . . . . . . . . . 35
11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 10.3. New Content Format . . . . . . . . . . . . . . . . . . . 36
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 10.4. New CoAP Signaling Option Number . . . . . . . . . . . . 37
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
13.1. Normative References . . . . . . . . . . . . . . . . . . 36 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37
13.2. Informative References . . . . . . . . . . . . . . . . . 38 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
Appendix A. Examples with Confirmable Messages . . . . . . . . . 39 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 39 13.1. Normative References . . . . . . . . . . . . . . . . . . 38
A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 40 13.2. Informative References . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Appendix A. Examples with Confirmable Messages . . . . . . . . . 40
A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 40
A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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 4, line 29 skipping to change at page 4, line 29
o Additional congestion control measures need to be put in place for o Additional congestion control measures need to be put in place for
NON (Section 6.2). NON (Section 6.2).
o To reduce the transmission times for CON transmission of large o To reduce the transmission times for CON transmission of large
bodies, NSTART needs to be increased from 1, but this affects bodies, NSTART needs to be increased from 1, but this affects
congestion control where other parameters need to be tuned congestion control where other parameters need to be tuned
(Section 4.7 of [RFC7252]). Such tuning is out of scope of this (Section 4.7 of [RFC7252]). Such tuning is out of scope of this
document. document.
o There is no multicast support.
Using NON messages, the faster transmissions occur as all the blocks Using NON messages, the faster transmissions occur as all the blocks
can be transmitted serially (as are IP fragmented packets) without can be transmitted serially (as are IP fragmented packets) without
having to wait for a response or next request from the remote CoAP having to wait for a response or next request from the remote CoAP
peer. Recovery of missing blocks is faster in that multiple missing peer. Recovery of missing blocks is faster in that multiple missing
blocks can be requested in a single CoAP packet. Even if there is blocks can be requested in a single CoAP packet. Even if there is
asymmetrical packet loss, a body can still be sent and received by asymmetrical packet loss, a body can still be sent and received by
the peer whether the body comprises of a single or multiple payloads the peer whether the body comprises of a single or multiple payloads
assuming no recovery is required. assuming no recovery is required.
Note that similar performance benefits can be applied to Confirmable Note that similar performance benefits can be applied to Confirmable
skipping to change at page 5, line 18 skipping to change at page 5, line 20
transmissions can fall back to using Block1 and Block2 Options, transmissions can fall back to using Block1 and Block2 Options,
respectively. respectively.
The deviations from Block1 and Block2 Options are specified in The deviations from Block1 and Block2 Options are specified in
Section 3. Pointers to appropriate [RFC7959] sections are provided. Section 3. Pointers to appropriate [RFC7959] sections are provided.
The specification refers to the base CoAP methods defined in The specification refers to the base CoAP methods defined in
Section 5.8 of [RFC7252] and the new CoAP methods, FETCH, PATCH, and Section 5.8 of [RFC7252] and the new CoAP methods, FETCH, PATCH, and
iPATCH introduced in [RFC8132]. iPATCH introduced in [RFC8132].
Q-Block1 and Q-Block2 Options are designed to work with Non- Q-Block1 and Q-Block2 Options are designed to work in particular with
confirmable requests and responses, in particular. Non-confirmable requests and responses.
1.2. CoAP Response Code (4.08) Usage 1.2. CoAP Response Code (4.08) Usage
This document adds a media type for the 4.08 (Request Entity This document adds a media type for the 4.08 (Request Entity
Incomplete) response defining an additional message format for Incomplete) response defining an additional message format for
reporting on payloads using the Q-Block1 Option that are not received reporting on payloads using the Q-Block1 Option that are not received
by the server. by the server.
See Section 4 for more details. See Section 4 for more details.
skipping to change at page 7, line 27 skipping to change at page 7, line 27
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. 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.02, iPATCH requests and their payload-bearing responses (2.01, 2.02,
2.03, 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 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), response (i.e., in that message to the payload of which it pertains),
it indicates a block-wise transfer and describes how this specific it indicates a block-wise transfer and describes how this specific
block-wise payload forms part of the entire body being transferred. block-wise payload forms part of the entire body being transferred.
If it is present in the opposite direction, it provides additional If it is present in the opposite direction, it provides additional
control on how that payload will be formed or was processed. 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].
Alternatively, with CoAP over reliable transports, Capabilities and
Settings Messages (CSMs) can be used to indicate support of Q-Block
Options by means of the Q-Block-Wise-Transfer Capability Option
(Table 2). The behavior of CoAP peers is similar to the one
specified in Section 5.3.2 of [RFC8323], except that it indicates
support of Q-Block Options.
+----+---+---+---------+---------------+--------+--------+--------+
| # | C | R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+====+===+===+=========+===============+========+========+========+
|TBA4| | | CSM | Q-Block-Wise- | empty | 0 | (none) |
| | | | | Transfer | | | |
+----+---+---+---------+---------------+--------+--------+--------+
C=Critical, R=Repeatable
Table 2: The Q-Block-Wise-Transfer Capability Option
Implementation of the Q-Block1 and Q-Block2 Options is intended to be Implementation of the Q-Block1 and Q-Block2 Options is intended to be
optional. However, when it is present in a CoAP message, it MUST be optional. However, when it is present in a CoAP message, it MUST be
processed (or the message rejected). Therefore, Q-Block1 and processed (or the message rejected). Therefore, Q-Block1 and
Q-Block2 Options are identified as Critical options. Q-Block2 Options are identified as Critical options.
With CoAP over UDP, the way a request message is rejected for With CoAP over UDP, the way a request message is rejected for
critical options depends on the message type. A Confirmable message critical options depends on the message type. A Confirmable message
with an unrecognized critical option is rejected with a 4.02 (Bad with an unrecognized critical option is rejected with a 4.02 (Bad
Option) response (Section 5.4.1 of [RFC7252]). A Non-confirmable Option) response (Section 5.4.1 of [RFC7252]). A Non-confirmable
message with an unrecognized critical option is either rejected with message with an unrecognized critical option is either rejected with
skipping to change at page 8, line 29 skipping to change at page 8, line 41
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].
Note that if Q-Block1 (or Q-Block2) Option is included in a packet,
Block1 (or Block2) Option MUST NOT be included.
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 3). The Q-Block1 (or Q-Block2) Option MAY be an
Inner or Outer option (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 |
+========+=================+===+===+ +========+=================+===+===+
| TBA1 | Q-Block1 | x | x | | TBA1 | Q-Block1 | x | x |
| TBA2 | Q-Block2 | x | x | | TBA2 | Q-Block2 | x | x |
+--------+-----------------+---+---+ +--------+-----------------+---+---+
Table 2: OSCORE Protection of Q-Block1 and Q-Block2 Options Table 3: OSCORE Protection of Q-Block1 and Q-Block2 Options
3.2. Structure of Q-Block1 and Q-Block2 Options 3.2. Structure of Q-Block1 and Q-Block2 Options
The structure of Q-Block1 and Q-Block2 Options follows the structure The structure of Q-Block1 and Q-Block2 Options follows the structure
defined in Section 2.2 of [RFC7959]. defined in Section 2.2 of [RFC7959].
There is no default value for the Q-Block1 and Q-Block2 Options. There is no default value for the Q-Block1 and Q-Block2 Options.
Absence of one of these options is equivalent to an option value of 0 Absence of one of these options is equivalent to an option value of 0
with respect to the value of block number (NUM) and more bit (M) that with respect to the value of block number (NUM) and more bit (M) that
could be given in the option, i.e., it indicates that the current could be given in the option, i.e., it indicates that the current
skipping to change at page 9, line 41 skipping to change at page 10, line 8
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.7 discusses the use of Size1 Option. Section 3.6 discusses the use of Size1 Option.
For Confirmable transmission, the server continues to acknowledge For Confirmable transmission, the server continues to acknowledge
each packet, but a response is not required (whether separate or each packet, but a response is not required (whether separate or
piggybacked) until successful receipt of the body or, if some of the piggybacked) until successful receipt of the body by the server. For
payloads are sent as Non-confirmable and have not arrived, a Non-confirmable transmission, no response is required until the
retransmit missing payloads response is needed. successful receipt of the body by the server or some of the payloads
have not arrived after a timeout and a retransmit missing payloads
response is needed. For reliable transports (e.g., [RFC8323]), a
response is not required until successful receipt of the body by the
server.
Each individual payload of the body is treated as a new request 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.
skipping to change at page 10, line 39 skipping to change at page 11, line 9
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. The token used SHOULD be from the and the resource was updated. The token used SHOULD be from the
last received payload. The client should then release all of the last received payload. The client should then release all of the
tokens used for this body. tokens used for this body.
2.05 (Content) 2.05 (Content)
This Response Code indicates successful receipt of the entire This Response Code indicates successful receipt of the entire
FETCH request body (Section 2 of [RFC8132]) and the appropriate FETCH request body (Section 2 of [RFC8132]) and the appropriate
representation of the resource has been returned. The token used representation of the resource is being returned. The token used
in the response MUST be the one in the FETCH request that has the 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 Q-Block1 with the M bit unset. If the FETCH request includes the
Observe Option, then the server MUST use the same token for Observe Option, then the server MUST use the same token for
returning any Observe triggered responses. The client should then returning any Observe triggered responses. The client should then
release all of the tokens used for this body unless a resource is release all of the tokens used for this body unless a resource is
being observed. 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
skipping to change at page 11, line 21 skipping to change at page 11, line 40
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 (in case of Confirmable request) or a
the server does not support the Q-Block1 Option. reset message (in case of Non-confirmable request) MUST be
returned if the server does not support the Q-Block1 Option.
4.08 (Request Entity Incomplete) 4.08 (Request Entity Incomplete)
This Response Code returned without Content-Type "application/ This Response Code returned without Content-Type "application/
missing-blocks+cbor-seq" (Section 10.3) is handled as in missing-blocks+cbor-seq" (Section 10.3) is handled as in
Section 2.9.2 [RFC7959]. Section 2.9.2 [RFC7959].
This Response Code returned with Content-Type "application/ This Response Code returned with Content-Type "application/
missing-blocks+cbor-seq" indicates that some of the payloads are missing-blocks+cbor-seq" indicates that some of the payloads are
missing and need to be resent. The client then retransmits the missing and need to be resent. The client then retransmits the
missing payloads using the same Request-Tag, Size1 and Q-Block1 to 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 NUM, 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 by taking the token in
4.08 (Request Entity Incomplete) response and then finding the the 4.08 (Request Entity Incomplete) response, locating the
matching client request which contains the Request-Tag that is matching client request, and then using its Request-Tag.
being used for this Q-Block1 body.
The token used in the response SHOULD be from the last received The token used in the response SHOULD be from the last received
payload. See Section 4 for further information. 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 in the response.
If the server has not received all the payloads of a body, but one or If the server has not received all the payloads of a body, but one or
more NON payloads have been received, it SHOULD wait for up to more NON payloads have been received, it SHOULD wait for up to
NON_RECEIVE_TIMEOUT (Section 6.2) before sending a 4.08 (Request NON_RECEIVE_TIMEOUT (Section 6.2) before sending a 4.08 (Request
Entity Incomplete) response. Further considerations related to the Entity Incomplete) response. Further considerations related to the
transmission timings of 4.08 (Request Entity Incomplete) and 2.31 transmission timings of 4.08 (Request Entity Incomplete) and 2.31
(Continue) Response Codes are discussed in Section 6.2. (Continue) Response Codes are discussed in Section 6.2.
If a server receives payloads with different Request-Tags for the If a server receives payloads with different Request-Tags for the
same resource, it should continue to process all the bodies as it has same resource, it should continue to process all the bodies as it has
skipping to change at page 12, line 38 skipping to change at page 13, line 13
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 has request is just for that block. If the M bit is set, this has
different meanings based on the NUM value: different meanings based on the NUM value:
NUM is zero: This is a request for the entire body. NUM is zero: This is a request for the entire body.
'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero: 'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero: This is
used to confirm that the current set of MAX_PAYLOADS payloads (the
This is used to confirm that the current set of MAX_PAYLOADS latest one having block number NUM-1) has been successfully
payloads (the latest one having block number NUM-1) has been received and that, upon receipt of this request, the server can
successfully received and that, upon receipt of this request, the continue to send the next set of payloads (the first one having
server can continue to send the next set of payloads (the first block number NUM). This is the 'Continue' Q-Block-2 and
one having block number NUM). This is the 'Continue' Q-Block-2. conceptually has the same usage (i.e., continue sending the next
set of data) as the use of 2.31 (Continue) for Q-Block1.
Any other value of NUM: This is a request for that block and for all Any other value of NUM: This is a request for that block and for all
of the remaining blocks in the current MAX_PAYLOADS set. of the remaining blocks in the current MAX_PAYLOADS set.
If the request includes multiple Q-Block2 Options and these options If the request includes multiple Q-Block2 Options and these options
overlap (e.g., combination of M being set (this and later blocks) and overlap (e.g., combination of M being set (this and later blocks) and
being unset (this individual block)) resulting in an individual block being unset (this individual block)) resulting in an individual block
being requested multiple times, the server MUST only send back one being requested multiple times, the server MUST only send back one
instance of that block. This behavior is meant to prevent instance of that block. This behavior is meant to prevent
amplification attacks. amplification attacks.
skipping to change at page 13, line 23 skipping to change at page 13, line 48
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.7 discusses the use of Size2 Option. Section 3.6 discusses the use of Size2 Option.
The client may elect to request any detected missing blocks or just The client may elect to request any detected missing blocks or just
ignore the partial body. This decision is implementation specific. ignore the partial body. This decision is implementation specific.
The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 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. It is permissible to set the M bit to request this and unset. It is permissible to set the M bit to request this and
missing blocks from this MAX_PAYLOADS set. Further considerations missing blocks from this MAX_PAYLOADS set. Further considerations
skipping to change at page 14, line 7 skipping to change at page 14, line 29
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.
If the client receives a duplicate block with the same ETag, it If the client receives a duplicate block with the same ETag, it
SHOULD silently ignore the packet. SHOULD silently ignore the packet.
A client SHOULD only maintain a partial body (missing payloads) for A client SHOULD only maintain a partial body (missing payloads) for
up to NON_PARTIAL_TIMEOUT (Section 6.2) or as defined by the Max-Age up to NON_PARTIAL_TIMEOUT (Section 6.2) or as defined by the Max-Age
Option (or its default), whichever is the less. Option (or its default of 60 seconds (Section 5.6.1 of [RFC7252])),
whichever is the less.
The ETag Option should not be used in the request for missing blocks The ETag Option should not be used in the request for missing blocks
as the server could respond with a 2.03 (Valid Response) with no as the server could respond with a 2.03 (Valid Response) with no
payload. It can be used in the request if the client wants to check payload. It can be used in the request if the client wants to check
the freshness of the currently cached body response. the freshness of the locally cached body response.
It is RECOMMENDED that the server maintains a cached copy of the body
when using the Q-Block2 Option to facilitate retransmission of any
missing payloads.
If the server detects part way through a body transfer that the If the server detects part way through a body transfer that the
resource data has changed and the server is not maintaining a cached resource data has changed and the server is not maintaining a cached
copy of the old data, then the body response SHOULD be restarted with copy of the old data, then the body response SHOULD be restarted with
a different ETag Option value. Any subsequent missing block requests a different ETag Option value. Any subsequent missing block requests
MUST be responded to using the latest ETag Option value. MUST be responded to using the latest ETag Option value.
If the server responds during a body update with a different ETag If the server responds during a body update with a different ETag
Option value (as the resource representation has changed), then the Option value (as the resource representation has changed), then the
client should treat the partial body with the old ETag as no longer client should treat the partial body with the old ETag as no longer
skipping to change at page 14, line 36 skipping to change at page 15, line 16
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-Block1 Options 3.5. Using Observe Option
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 For a request that uses Q-Block1, the Observe value [RFC7641] MUST be
acknowledgement of the individual blocks, the Observe value [RFC7641] the same for all the payloads of the same body. This includes any
MUST be the same for all the blocks of the same body. missing payloads that are retransmitted.
If the client requests missing blocks, this is treated as a new For a response that uses Q-Block2, the Observe value MUST be the same
Request and the Observe Option MUST NOT be included in either the for all the payloads of the same body. This includes payloads
request or response. If the ETag value in the response changes, then transmitted following receipt of the 'Continue' Q-Block2 Option
the previously received partial body should be considered as not (Section 3.4) by the server. If a missing payload is requested, then
fresh and the whole body re-requested. both the request and response MUST NOT include the Observe Option.
3.7. Using Size1 and Size2 Options 3.6. Using Size1 and Size2 Options
Section 4 of [RFC7959] defines two CoAP options: Size1 for indicating Section 4 of [RFC7959] defines two CoAP options: Size1 for indicating
the size of the representation transferred in requests and Size2 for the size of the representation transferred in requests and Size2 for
indicating the size of the representation transferred in responses. indicating the size of the representation transferred in responses.
The Size1 or Size2 option values MUST exactly represent the size of The Size1 or Size2 option values MUST exactly represent the size of
the data on the body so that any missing data can easily be the data on the body so that any missing data can easily be
determined. determined.
The Size1 Option MUST be used with the Q-Block1 Option when used in a The Size1 Option MUST be used with the Q-Block1 Option when used in a
request. The Size2 Option MUST be used with the Q-Block2 Option when request. The Size2 Option MUST be used with the Q-Block2 Option when
used in a response. used in a response.
If Size1 or Size2 Options are used, they MUST be used in all payloads If Size1 or Size2 Options are used, they MUST be used in all payloads
of the body and MUST preserve the same value in each of those of the body and MUST preserve the same value in each of those
payloads. payloads.
3.8. Using Q-Block1 and Q-Block2 Options Together 3.7. Using Q-Block1 and Q-Block2 Options Together
The behavior is similar to the one defined in Section 3.3 of The behavior is similar to the one defined in Section 3.3 of
[RFC7959] with Q-Block1 substituted for Block1 and Q-Block2 for [RFC7959] with Q-Block1 substituted for Block1 and Q-Block2 for
Block2. Block2.
3.8. Using Q-Block2 Option With Multicast
Servers MUST ignore multicast requests that contain the Q-Block2
Option. As a reminder, Block2 Option can be used as stated in
Section 2.8 of [RFC7959].
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.
skipping to change at page 16, line 32 skipping to change at page 16, line 49
; 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 last block number received so far with the same Request-Tag in the last block number received so far with the same Request-Tag
value. Note that the use of any received token with the same value. Note that the use of any received token with the same
Request-Tag would work, but providing the one used in the last Request-Tag would work, but providing the one used in the last
received block number will aid any troubleshooting. The client will received block number will aid any troubleshooting. The client will
use the token to determine what is the previously sent request to use the token to determine what was the previously sent request to
obtain the Request-Tag value to be used. 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 other 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.
skipping to change at page 17, line 23 skipping to change at page 17, line 42
5. The Use of Tokens 5. The Use of Tokens
Each new request MUST use a unique Token (Section 4 of Each new request MUST use a unique Token (Section 4 of
[I-D.ietf-core-echo-request-tag]). Additional responses may use the [I-D.ietf-core-echo-request-tag]). Additional responses may use the
same Token. same Token.
Implementation Note: To minimize on the number of tokens that have Implementation Note: To minimize on the number of tokens that have
to be tracked by clients, it is recommended that the bottom 32 to be tracked by clients, it is recommended that the bottom 32
bits is kept the same for the same body and the upper 32 bits bits is kept the same for the same body and the upper 32 bits
contains the individual payload number. contains the individual payload number. This allows the client to
be alleviated from keeping all the per-request-state, e.g., in
Section 3 of [RFC8974].
Servers continue to treat the token as a unique opaque entity. If Servers continue to treat the token as a unique opaque entity. If
an individual payload has to be resent (e.g., requested upon an individual payload has to be resent (e.g., requested upon
packet loss), then the retransmitted packet is treated as a new packet loss), then the retransmitted packet is treated as a new
request (i.e., the bottom 32 bits must change). request (i.e., the bottom 32 bits must change).
6. Congestion Control 6. Congestion Control for Unreliable Transports
The transmission of the payloads of a body either SHOULD all be The transmission of the payloads of a body over an unreliable
Confirmable or all be Non-confirmable. This is meant to simplify the transport SHOULD either all be Confirmable or all be Non-confirmable.
congestion control procedure. This is meant to simplify the congestion control procedure.
As a reminder, there is no need for CoAP-specific congestion control
for reliable transports [RFC8323].
6.1. Confirmable (CON) 6.1. Confirmable (CON)
Congestion control for CON requests and responses is specified in Congestion control for CON requests and responses is specified in
Section 4.7 of [RFC7252]. For faster transmission rates, NSTART will Section 4.7 of [RFC7252]. For faster transmission rates, NSTART will
need to be increased from 1. However, the other CON congestion need to be increased from 1. However, the other CON congestion
control parameters will need to be tuned to cover this change. This control parameters will need to be tuned to cover this change. This
tuning is out of scope of this document as it is expected that all tuning is out of scope of this document as it is expected that all
requests and responses using Q-Block1 and Q-Block2 will be Non- requests and responses using Q-Block1 and Q-Block2 will be Non-
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_MAX_RETRANSMIT, NON_PROBING_WAIT, and NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and
NON_PARTIAL_TIMEOUT primarily for use with NON. NON_PARTIAL_TIMEOUT primarily for use with NON (Table 4).
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. By default, NON_TIMEOUT has MAX_PAYLOADS payloads for the same body. By default, NON_TIMEOUT has
the same 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 initial maximum time to wait for a missing
before requesting retransmission. NON_RECEIVE_TIMEOUT has a value of payload before requesting retransmission for the first time. Every
twice NON_TIMEOUT. time the missing payload is re-requested, the time to wait value
doubles. The time to wait is calculated as:
Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count - 1))
NON_RECEIVE_TIMEOUT has a default value of twice NON_TIMEOUT.
NON_RECEIVE_TIMEOUT MUST always be greater than NON_TIMEOUT by at
least one second so that the sender of the payloads has the
opportunity to start sending the next set of payloads before the
receiver times out.
NON_MAX_RETRANSMIT is the maximum number of times a request for the NON_MAX_RETRANSMIT is the maximum number of times a request for the
retransmission of missing payloads can occur without a response from retransmission of missing payloads can occur without a response from
the remote peer. After this occurs, the peer SHOULD consider the the remote peer. After this occurs, the local endpoint SHOULD
body stale and remove all references to it. By default, 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 NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT (Section 4.8
of [RFC7252]). of [RFC7252]).
NON_PROBING_WAIT is used to limit the potential wait needed NON_PROBING_WAIT is used to limit the potential wait needed
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]).
skipping to change at page 19, line 16 skipping to change at page 19, line 39
| Parameter Name | Default Value | | Parameter Name | Default Value |
+=====================+===============| +=====================+===============|
| MAX_PAYLOADS | 10 | | MAX_PAYLOADS | 10 |
| NON_MAX_RETRANSMIT | 4 | | NON_MAX_RETRANSMIT | 4 |
| NON_TIMEOUT | 2 s | | NON_TIMEOUT | 2 s |
| NON_RECEIVE_TIMEOUT | 4 s | | NON_RECEIVE_TIMEOUT | 4 s |
| NON_PROBING_WAIT | 247 s | | NON_PROBING_WAIT | 247 s |
| NON_PARTIAL_TIMEOUT | 247 s | | NON_PARTIAL_TIMEOUT | 247 s |
+---------------------+---------------+ +---------------------+---------------+
Table 3: Congestion Control Parameters Table 4: 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
skipping to change at page 20, line 23 skipping to change at page 20, line 46
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) Response Code on receipt of all of the MAX_PAYLOADS 2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS
payloads to prevent the client unnecessarily delaying. Otherwise the payloads to prevent the client unnecessarily delaying. Otherwise the
server SHOULD delay for NON_RECEIVE_TIMEOUT, before sending the 4.08 server SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled
(Request Entity Incomplete) Response Code. The NON_RECEIVE_TIMEOUT based on the repeat request count for a payload), before sending the
delay may be reduced for the first time that this 4.08 (Request 4.08 (Request Entity Incomplete) Response Code for the missing
Entity Incomplete) is sent if either the last of the MAX_PAYLOADS payload(s). If the repeat request count for a missing payload
payloads or the final payload with the M bit unset arrives, but exceeds NON_MAX_RETRANSMIT, the server SHOULD discard the partial
SHOULD NOT be reduced to zero as packets may arrive in the wrong body and stop requesting the missing payloads.
order.
It is possible that the client may start transmitting the next set of It is likely that the client will start transmitting the next set of
MAX_PAYLOADS payloads before the server times out on waiting for the 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
received payload from the new set of MAX_PAYLOADS payloads, the received payload from the new set of MAX_PAYLOADS payloads, the
server SHOULD send a 4.08 (Request Entity Incomplete) Response Code server SHOULD send a 4.08 (Request Entity Incomplete) Response Code
indicating any missing payloads from any previous MAX_PAYLOADS indicating any missing payloads from any previous MAX_PAYLOADS
payloads. Upon receipt of the 4.08 (Request Entity Incomplete) payloads. Upon receipt of the 4.08 (Request Entity Incomplete)
Response Code, the client SHOULD send the missing payloads before Response Code, the client SHOULD send the missing payloads before
continuing to send the remainder of the MAX_PAYLOADS payloads and continuing to send the remainder of the MAX_PAYLOADS payloads and
then go into another NON_TIMEOUT delay prior to sending the next set then go into another NON_TIMEOUT delay prior to sending the next set
of payloads. 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 on receipt of all of the 'Continue' Q-Block2 request (Section 3.4) for the next set of
MAX_PAYLOADS payloads to prevent the server unnecessarily delaying. payloads on receipt of all of the MAX_PAYLOADS payloads to prevent
Otherwise the client SHOULD delay for NON_RECEIVE_TIMEOUT, before the server unnecessarily delaying. Otherwise the client SHOULD delay
sending the request for the missing payloads. The for NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat
NON_RECEIVE_TIMEOUT delay may be reduced for the first time that this request count for a payload), before sending the request for the
request is sent if either the last of the MAX_PAYLOADS payloads or missing payload(s). If the repeat request count for a missing
the final payload with the M bit unset arrives, but SHOULD NOT be payload exceeds NON_MAX_RETRANSMIT, the client SHOULD discard the
reduced to zero as packets may arrive in the wrong order. partial body and stop requesting the missing payloads.
The request that the client sends to acknowledge the receipt of all The server SHOULD recognize the 'Continue' Q-Block2 request as a
the current set of MAX_PAYLOADS payloads is the 'Continue' Q-Block2
Option ('NUM modulo MAX_PAYLOADS' is zero, NUM is not zero, and M bit
is set (Section 3.4)). The server SHOULD recognize this as a
continue request and just continue the transmission of the body continue request and just continue the transmission of the body
(including Observe Option, if appropriate for an unsolicited (including Observe Option, if appropriate for an unsolicited
response) rather than as a request for the remaining missing blocks. response) rather than as a request for the remaining missing blocks.
It is possible that the server may start transmitting the next set of It is likely that the server will start transmitting the next set of
MAX_PAYLOADS payloads before the client times out on waiting for the MAX_PAYLOADS payloads before the client times out on waiting for the
last of the previous MAX_PAYLOADS payloads. Upon receipt of the last of the previous MAX_PAYLOADS payloads. Upon receipt of the
first payload from the new set of MAX_PAYLOADS payloads, the client first payload from the new set of MAX_PAYLOADS payloads, the client
SHOULD send a request indicating any missing payloads from any SHOULD send a request indicating any missing payloads from any
previous set of MAX_PAYLOADS payloads. Upon receipt of such request, previous set of MAX_PAYLOADS payloads. Upon receipt of such request,
the server SHOULD send the missing payloads before continuing to send the server SHOULD send the missing payloads before continuing to send
the remainder of the MAX_PAYLOADS payloads and then go into another the remainder of the MAX_PAYLOADS payloads and then go into another
NON_TIMEOUT delay prior to sending the next set of payloads. 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
skipping to change at page 24, line 50 skipping to change at page 25, line 27
+--->X | NON PUT /path M:0x1b T:0xeb RT=11 QB1:10/1/1024 +--->X | NON PUT /path M:0x1b T:0xeb RT=11 QB1:10/1/1024
+--------->| NON PUT /path M:0x1c T:0xec RT=11 QB1:11/1/1024 +--------->| NON PUT /path M:0x1c T:0xec RT=11 QB1:11/1/1024
| | | |
Figure 5: Example of MAX_PAYLOADS NON Request with Q-Block1 Option Figure 5: Example of MAX_PAYLOADS NON Request with Q-Block1 Option
(With Loss) (With Loss)
On seeing a payload from the next set of payloads, the server On seeing a payload from the next set of payloads, the server
realizes that some blocks are missing from the previous MAX_PAYLOADS realizes that some blocks are missing from the previous MAX_PAYLOADS
payloads and asks for the missing blocks in one go (Figure 6). It payloads and asks for the missing blocks in one go (Figure 6). It
does so by indicating which blocks have not been received in the data does so by indicating which blocks from the previous MAX_PAYLOADS
portion of the response. The token used in the response should be payloads have not been received in the data portion of the response.
the token that was used in the last block number received payload. The token used in the response should be the token that was used in
the last block number received payload. The client can then derive
The client can then derive the Request-Tag by matching the token with the Request-Tag by matching the token with the sent request.
the sent request.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
|<---------+ NON 4.08 M:0x91 T:0xec [Missing 1,9 [for RT=11]] |<---------+ NON 4.08 M:0x91 T:0xec [Missing 1,9 [for RT=11]]
| [[Client responds with missing payloads]] | [[Client responds with missing payloads]]
+--------->| NON PUT /path M:0x1d T:0xed RT=11 QB1:1/1/1024 +--------->| NON PUT /path M:0x1d T:0xed RT=11 QB1:1/1/1024
+--------->| NON PUT /path M:0x1e T:0xee RT=11 QB1:9/1/1024 +--------->| NON PUT /path M:0x1e T:0xee RT=11 QB1:9/1/1024
| [[Client continues sending next set of payloads]] | [[Client continues sending next set of payloads]]
+--------->| NON PUT /path M:0x1f T:0xef RT=11 QB1:12/0/1024 +--------->| NON PUT /path M:0x1f T:0xef RT=11 QB1:12/0/1024
skipping to change at page 25, line 29 skipping to change at page 26, line 5
| [[The server realizes a block is still missing and asks | [[The server realizes a block is still missing and asks
| for the missing one]] | for the missing one]]
|<---------+ NON 4.08 M:0x92 T:0xef [Missing 10 [for RT=11]] |<---------+ 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 PUT /path M:0x20 T:0xf0 RT=11 QB1:10/1/1024
|<---------+ NON 2.04 M:0x93 T:0xf0 |<---------+ NON 2.04 M:0x93 T:0xf0
| ... | | ... |
Figure 6: Example of NON Request with Q-Block1 Option (Blocks 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 9.1.4. Handling Recovery with Failure
sending missing blocks of data by "forgetting" all the tracked tokens
for this Request-Tag. Similarly, the server can elect to not to Figure 7 depicts an example of a NON PUT request conveying Q-Block1
continue asking for missing blocks. Both these decisions are Option where recovery takes place, but eventually fails.
implementation specific.
CoAP CoAP
Client Server
| |
+--------->| NON PUT /path M:0x91 T:0xd0 RT=12 QB1:0/1/1024
+--->X | NON PUT /path M:0x92 T:0xd1 RT=12 QB1:1/1/1024
+--------->| NON PUT /path M:0x93 T:0xd2 RT=12 QB1:2/0/1024
| ... |
[[NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[The server realizes a block is missing and asks
| for the missing one. Retry #1]]
|<---------+ NON 4.08 M:0x01 T:0xd2 [Missing 1 [for RT=12]]
| ... |
[[2 * NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[The server realizes a block is still missing and asks
| for the missing one. Retry #2]]
|<---------+ NON 4.08 M:0x02 T:0xd2 [Missing 1 [for RT=12]]
| ... |
[[4 * NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[The server realizes a block is still missing and asks
| for the missing one. Retry #3]]
|<---------+ NON 4.08 M:0x03 T:0xd2 [Missing 1 [for RT=12]]
| ... |
[[8 * NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[The server realizes a block is still missing and asks
| for the missing one. Retry #4]]
|<---------+ NON 4.08 M:0x04 T:0xd2 [Missing 1 [for RT=12]]
| ... |
[[16 * NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[NON_MAX_RETRANSMIT exceeded. Server stops requesting
| for missing blocks and releases partial body]]
| ... |
Figure 7: Example of NON Request with Q-Block1 Option (With Eventual
Failure)
9.2. Q-Block2 Option 9.2. Q-Block2 Option
These examples include the Observe Option to demonstrate how that
option is used. Note that the Observe Option is not required for
Q-Block2; the observe detail can thus be ignored.
9.2.1. A Simple Example 9.2.1. A Simple Example
Figure 7 illustrates the example of Q-Block2 Option. The client Figure 8 illustrates the example of Q-Block2 Option. The client
sends a NON GET carrying Observe and Q-Block2 Options. The Q-Block2 sends a NON GET carrying Observe and Q-Block2 Options. The Q-Block2
Option indicates a block size hint (1024 bytes). This request is Option indicates a block size hint (1024 bytes). This request is
replied to by the server using four (4) blocks that are transmitted replied to by the server using four (4) blocks that are transmitted
to the client without any loss. Each of these blocks carries a to the client without any loss. Each of these blocks carries a
Q-Block2 Option. The same process is repeated when an Observe is Q-Block2 Option. The same process is repeated when an Observe is
triggered, but no loss is experienced by any of the notification triggered, but no loss is experienced by any of the notification
blocks. blocks.
CoAP CoAP CoAP CoAP
Client Server Client Server
skipping to change at page 26, line 21 skipping to change at page 27, line 32
|<---------+ NON 2.05 M:0xf3 T:0xc0 O:1220 ET=19 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:0xc0 O:1220 ET=19 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:0xc0 O:1221 ET=20 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:0xc0 O:1221 ET=20 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:0xc0 O:1221 ET=20 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:0xc0 O:1221 ET=20 QB2:3/0/1024 |<---------+ NON 2.05 M:0xf8 T:0xc0 O:1221 ET=20 QB2:3/0/1024
| ... | | ... |
Figure 7: Example of NON Notifications with Q-Block2 Option (Without Figure 8: Example of NON Notifications with Q-Block2 Option (Without
Loss) Loss)
9.2.2. Handling MAX_PAYLOADS Limits 9.2.2. Handling MAX_PAYLOADS Limits
Figure 8 illustrates the same as Figure 7 but this time has eleven Figure 9 illustrates the same as Figure 8 but this time has eleven
(11) payloads which exceeds MAX_PAYLOADS. There is no loss (11) payloads which exceeds MAX_PAYLOADS. There is no loss
experienced. experienced.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024 +--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024
|<---------+ NON 2.05 M:0x81 T:0xf0 O:1234 ET=21 QB2:0/1/1024 |<---------+ NON 2.05 M:0x81 T:0xf0 O:1234 ET=21 QB2:0/1/1024
|<---------+ NON 2.05 M:0x82 T:0xf0 O:1234 ET=21 QB2:1/1/1024 |<---------+ NON 2.05 M:0x82 T:0xf0 O:1234 ET=21 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
skipping to change at page 27, line 32 skipping to change at page 28, line 32
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0x9a T:0xf0 O:1235 ET=22 QB2:9/1/1024 |<---------+ NON 2.05 M:0x9a T:0xf0 O:1235 ET=22 QB2:9/1/1024
[[MAX_PAYLOADS has been reached]] [[MAX_PAYLOADS has been reached]]
| [[MAX_PAYLOADS blocks acknowledged by client using | [[MAX_PAYLOADS blocks acknowledged by client using
| 'Continue' Q-Block2]] | 'Continue' Q-Block2]]
+--------->| NON GET /path M:0x03 T:0xf2 QB2:10/1/1024 +--------->| NON GET /path M:0x03 T:0xf2 QB2:10/1/1024
|<---------+ NON 2.05 M:0x9b T:0xf0 O:1235 ET=22 QB2:10/0/1024 |<---------+ NON 2.05 M:0x9b T:0xf0 O:1235 ET=22 QB2:10/0/1024
[[Body has been received]] [[Body has been received]]
| ... | | ... |
Figure 8: Example of NON Notifications with Q-Block2 Option (Without Figure 9: Example of NON Notifications with Q-Block2 Option (Without
Loss) Loss)
9.2.3. Handling MAX_PAYLOADS with Recovery 9.2.3. Handling MAX_PAYLOADS with Recovery
Figure 9 shows the example of an Observe that is triggered but for Figure 10 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 are missing as one or more Q-Block2
Options.
CoAP CoAP CoAP CoAP
Client Server Client Server
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0xa1 T:0xf0 O:1236 ET=23 QB2:0/1/1024 |<---------+ NON 2.05 M:0xa1 T:0xf0 O:1236 ET=23 QB2:0/1/1024
| X<---+ NON 2.05 M:0xa2 T:0xf0 O:1236 ET=23 QB2:1/1/1024 | X<---+ NON 2.05 M:0xa2 T:0xf0 O:1236 ET=23 QB2:1/1/1024
|<---------+ [[Payloads 3 - 8 not detailed]] |<---------+ [[Payloads 3 - 8 not detailed]]
| X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024 | X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024
[[MAX_PAYLOADS has been reached]] [[MAX_PAYLOADS has been reached]]
skipping to change at page 28, line 35 skipping to change at page 29, line 35
|<---------+ NON 2.05 M:0xad T:0xf3 ET=23 QB2:9/1/1024 |<---------+ NON 2.05 M:0xad T:0xf3 ET=23 QB2:9/1/1024
| ... | | ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]] [[NON_RECEIVE_TIMEOUT (client) delay expires]]
| [[Client realizes block is still missing and asks for | [[Client realizes block is still missing and asks for
| missing block]] | missing block]]
+--------->| NON GET /path M:0x05 T:0xf4 QB2:1/0/1024 +--------->| NON GET /path M:0x05 T:0xf4 QB2:1/0/1024
|<---------+ NON 2.05 M:0xae T:0xf4 ET=23 QB2:1/1/1024 |<---------+ NON 2.05 M:0xae T:0xf4 ET=23 QB2:1/1/1024
[[Body has been received]] [[Body has been received]]
| ... | | ... |
Figure 9: Example of NON Notifications with Q-Block2 Option (Blocks Figure 10: Example of NON Notifications with Q-Block2 Option (Blocks
Recovery) Recovery)
Under high levels of traffic loss, the client can elect not to retry
getting missing blocks of data. This decision is implementation
specific.
9.2.4. Handling Recovery using M-bit Set 9.2.4. Handling Recovery using M-bit Set
Figure 10 shows the example of an Observe that is triggered but only Figure 11 shows the example of an Observe that is triggered but only
the first two notification blocks reach the client. In order to the first two notification blocks reach the client. In order to
retrieve the missing blocks, the client sends a request with a single retrieve the missing blocks, the client sends a request with a single
Q-Block2 Option with the M bit set. Q-Block2 Option with the M bit set.
CoAP CoAP CoAP CoAP
Client Server Client Server
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0xb1 T:0xf0 O:1237 ET=24 QB2:0/1/1024 |<---------+ NON 2.05 M:0xb1 T:0xf0 O:1237 ET=24 QB2:0/1/1024
|<---------+ NON 2.05 M:0xb2 T:0xf0 O:1237 ET=24 QB2:1/1/1024 |<---------+ NON 2.05 M:0xb2 T:0xf0 O:1237 ET=24 QB2:1/1/1024
skipping to change at page 29, line 35 skipping to change at page 30, line 35
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0xc2 T:0xf5 ET=24 QB2:9/1/1024 |<---------+ NON 2.05 M:0xc2 T:0xf5 ET=24 QB2:9/1/1024
[[MAX_PAYLOADS has been reached]] [[MAX_PAYLOADS has been reached]]
| [[MAX_PAYLOADS acknowledged by client using 'Continue' | [[MAX_PAYLOADS acknowledged by client using 'Continue'
| Q-Block2]] | Q-Block2]]
+--------->| NON GET /path M:0x87 T:0xf6 QB2:10/1/1024 +--------->| NON GET /path M:0x87 T:0xf6 QB2:10/1/1024
|<---------+ NON 2.05 M:0xc3 T:0xf0 O:1237 ET=24 QB2:10/0/1024 |<---------+ NON 2.05 M:0xc3 T:0xf0 O:1237 ET=24 QB2:10/0/1024
[[Body has been received]] [[Body has been received]]
| ... | | ... |
Figure 10: Example of NON Notifications with Q-Block2 Option (Blocks Figure 11: Example of NON Notifications with Q-Block2 Option (Blocks
Recovery with M bit Set) Recovery with M bit Set)
9.3. Q-Block1 and Q-Block2 Options 9.3. Q-Block1 and Q-Block2 Options
9.3.1. A Simple Example 9.3.1. A Simple Example
Figure 11 illustrates the example of a FETCH using both Q-Block1 and Figure 12 illustrates the example of a FETCH using both Q-Block1 and
Q-Block2 Options along with an Observe Option. No loss is Q-Block2 Options along with an Observe Option. No loss is
experienced. experienced.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON FETCH /path M:0x10 T:0x90 O:0 RT=30 QB1:0/1/1024 +--------->| 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: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 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:0x60 T:0x93 O:1320 ET=90 QB2:0/1/1024
skipping to change at page 30, line 23 skipping to change at page 31, line 23
|<---------+ NON 2.05 M:0x62 T:0x93 O:1320 ET=90 QB2:2/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 |<---------+ NON 2.05 M:0x63 T:0x93 O:1320 ET=90 QB2:3/0/1024
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0x64 T:0x93 O:1321 ET=91 QB2:0/1/1024 |<---------+ 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: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: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 |<---------+ 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 Figure 12: Example of NON FETCH with Q-Block1 and Q-Block2 Options
(Without Loss) (Without Loss)
9.3.2. Handling MAX_PAYLOADS Limits 9.3.2. Handling MAX_PAYLOADS Limits
Figure 12 illustrates the same as Figure 11 but this time has eleven Figure 13 illustrates the same as Figure 12 but this time has eleven
(11) payloads in both directions which exceeds MAX_PAYLOADS. There (11) payloads in both directions which exceeds MAX_PAYLOADS. There
is no loss experienced. is no loss experienced.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON FETCH /path M:0x30 T:0xa0 O:0 RT=10 QB1:0/1/1024 +--------->| NON FETCH /path M:0x30 T:0xa0 O:0 RT=10 QB1:0/1/1024
+--------->| NON FETCH /path M:0x31 T:0xa1 O:0 RT=10 QB1:1/1/1024 +--------->| NON FETCH /path M:0x31 T:0xa1 O:0 RT=10 QB1:1/1/1024
+--------->| [[Payloads 3 - 9 not detailed]] +--------->| [[Payloads 3 - 9 not detailed]]
+--------->| NON FETCH /path M:0x39 T:0xa9 O:0 RT=10 QB1:9/1/1024 +--------->| NON FETCH /path M:0x39 T:0xa9 O:0 RT=10 QB1:9/1/1024
skipping to change at page 31, line 39 skipping to change at page 32, line 39
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0x95 T:0xaa O:1335 ET=22 QB2:9/1/1024 |<---------+ NON 2.05 M:0x95 T:0xaa O:1335 ET=22 QB2:9/1/1024
[[MAX_PAYLOADS has been reached]] [[MAX_PAYLOADS has been reached]]
| [[MAX_PAYLOADS blocks acknowledged by client using | [[MAX_PAYLOADS blocks acknowledged by client using
| 'Continue' Q-Block2]] | 'Continue' Q-Block2]]
+--------->| NON FETCH /path M:0x3c T:0xac QB2:10/1/1024 +--------->| NON FETCH /path M:0x3c T:0xac QB2:10/1/1024
|<---------+ NON 2.05 M:0x96 T:0xaa O:1335 ET=22 QB2:10/0/1024 |<---------+ NON 2.05 M:0x96 T:0xaa O:1335 ET=22 QB2:10/0/1024
[[Body has been received]] [[Body has been received]]
| ... | | ... |
Figure 12: Example of NON FETCH with Q-Block1 and Q-Block2 Options Figure 13: Example of NON FETCH with Q-Block1 and Q-Block2 Options
(Without Loss) (Without Loss)
9.3.3. Handling Recovery 9.3.3. Handling Recovery
Consider now a scenario where there are some blocks are lost in Consider now a scenario where there are some blocks are lost in
transmission as illustrated in Figure 13. transmission as illustrated in Figure 14.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON FETCH /path M:0x50 T:0xc0 O:0 RT=31 QB1:0/1/1024 +--------->| NON FETCH /path M:0x50 T:0xc0 O:0 RT=31 QB1:0/1/1024
+--->X | NON FETCH /path M:0x51 T:0xc1 O:0 RT=31 QB1:1/1/1024 +--->X | NON FETCH /path M:0x51 T:0xc1 O:0 RT=31 QB1:1/1/1024
+--->X | NON FETCH /path M:0x52 T:0xc2 O:0 RT=31 QB1:2/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 FETCH /path M:0x53 T:0xc3 O:0 RT=31 QB1:3/0/1024
| ... | | ... |
[[NON_RECEIVE_TIMEOUT (server) delay expires]] [[NON_RECEIVE_TIMEOUT (server) delay expires]]
Figure 13: Example of NON FETCH with Q-Block1 and Q-Block2 Options Figure 14: Example of NON FETCH with Q-Block1 and Q-Block2 Options
(With Loss) (With Loss)
The server realizes that some blocks are missing and asks for the The server realizes that some blocks are missing and asks for the
missing blocks in one go (Figure 14). It does so by indicating which missing blocks in one go (Figure 15). It does so by indicating which
blocks have not been received in the data portion of the response. 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 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 last block number received payload. The client can then derive the
Request-Tag by matching the token with the sent request. Request-Tag by matching the token with the sent request.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
|<---------+ NON 4.08 M:0xa0 T:0xc3 [Missing 1,2 [for RT=31]] |<---------+ NON 4.08 M:0xa0 T:0xc3 [Missing 1,2 [for RT=31]]
| [[Client responds with missing payloads]] | [[Client responds with missing payloads]]
skipping to change at page 32, line 42 skipping to change at page 33, line 42
| [[Server received FETCH body, | [[Server received FETCH body,
| starts transmitting response body]] | starts transmitting response body]]
|<---------+ NON 2.05 M:0xa1 T:0xc3 O:1236 ET=23 QB2:0/1/1024 |<---------+ 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 | 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 |<---------+ 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 | X<---+ NON 2.05 M:0xa4 T:0xc3 O:1236 ET=23 QB2:3/0/1024
| ... | | ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]] [[NON_RECEIVE_TIMEOUT (client) delay expires]]
| | | |
Figure 14: Example of NON Request with Q-Block1 Option (Server Figure 15: Example of NON Request with Q-Block1 Option (Server
Recovery) Recovery)
The client realizes that not all the payloads of the response have 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 been returned. The client then asks for the missing blocks in one go
(Figure 15). However, because the original request is spread over (Figure 16). Note that, following Section 2.7 of [RFC7959], the
multiple payloads using Q-Block1, the entire FETCH body has to be FETCH request does not include the Q-Block1 or any payload.
used to make the request for the missing payloads.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON FETCH /path M:0x56 T:0xc6 RT=31 QB1:0/1/1024\ +--------->| NON FETCH /path M:0x56 T:0xc6 RT=31 QB2:1/0/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 | | QB2:3/0/1024
| [[Server received FETCH request, | [[Server receives FETCH request for missing payloads,
| starts transmitting missing blocks]] | starts transmitting missing blocks]]
| X<---+ NON 2.05 M:0xa5 T:0xc9 ET=23 QB2:1/1/1024 | X<---+ NON 2.05 M:0xa5 T:0xc6 ET=23 QB2:1/1/1024
|<---------+ NON 2.05 M:0xa6 T:0xc9 ET=23 QB2:3/0/1024 |<---------+ NON 2.05 M:0xa6 T:0xc6 ET=23 QB2:3/0/1024
| ... | | ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]] [[NON_RECEIVE_TIMEOUT (client) delay expires]]
| [[Client realizes block is still missing and asks for | [[Client realizes block is still missing and asks for
| missing block]] | missing block]]
+--------->| NON FETCH /path M:0x5a T:0xca RT=31 QB1:0/1/1024\ +--------->| NON FETCH /path M:0x57 T:0xc7 RT=31 QB2:1/0/1024
| | QB2:1/0/1024 | [[Server receives FETCH request for missing payload,
+--------->| 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]] | starts transmitting missing block]]
|<---------+ NON 2.05 M:0xa7 T:0xcd ET=23 QB2:1/1/1024 |<---------+ NON 2.05 M:0xa7 T:0xc7 ET=23 QB2:1/1/1024
[[Body has been received]]
| ... |
| [[Observe triggered]]
|<---------+ NON 2.05 M:0xa8 T:0xc3 O:1337 ET=24 QB2:0/1/1024
| X<---+ NON 2.05 M:0xa9 T:0xc3 O:1337 ET=24 QB2:1/1/1024
|<---------+ NON 2.05 M:0xaa T:0xc3 O:1337 ET=24 QB2:2/0/1024
[[NON_RECEIVE_TIMEOUT (client) delay expires]]
| [[Client realizes block is still missing and asks for
| missing block]]
+--------->| NON FETCH /path M:0x58 T:0xc8 RT=31 QB2:1/0/1024
| [[Server receives FETCH request for missing payload,
| starts transmitting missing block]]
|<---------+ NON 2.05 M:0xa7 T:0xc8 ET=23 QB2:1/1/1024
[[Body has been received]] [[Body has been received]]
| ... | | ... |
Figure 15: Example of NON Request with Q-Block1 Option (Client Figure 16: Example of NON Request with Q-Block1 Option (Client
Recovery) 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 |
+========+==================+===========+ +========+==================+===========+
| TBA1 | Q-Block1 | [RFCXXXX] | | TBA1 | Q-Block1 | [RFCXXXX] |
| TBA2 | Q-Block2 | [RFCXXXX] | | TBA2 | Q-Block2 | [RFCXXXX] |
+--------+------------------+-----------+ +--------+------------------+-----------+
Table 4: CoAP Q-Block1 and Q-Block2 Option Numbers Table 5: CoAP Q-Block1 and Q-Block2 Option Numbers
This document suggests 19 (TBA1) and 51 (TBA2) as a values to be This document suggests 19 (TBA1) and 51 (TBA2) as 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
skipping to change at page 36, line 7 skipping to change at page 37, line 7
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: TBA3
o Reference: [RFCXXXX] o Reference: [RFCXXXX]
This document suggests 272 (TBA3) as a value to be assigned for the
new content format number.
10.4. New CoAP Signaling Option Number
This document requests IANA to register the following option in the
"CoAP Signaling Option Numbers" registry [CSM].
+------------+--------+-----------------------+-----------+
| Applies to | Number | Name | Reference |
+============+========+=======================+===========+
| 7.01 | TBA4 | Q-Block-Wise-Transfer | [RFCXXXX] |
+------------+--------+-----------------------+-----------+
Table 6: CoAP Signaling Option Codes
This document suggests 8 (TBA4) as a value to be assigned for the new
option number.
11. Security Considerations 11. Security Considerations
Security considerations discussed in Section 7 of [RFC7959] should be Security considerations discussed in Section 7 of [RFC7959] should be
taken into account. taken into account.
Security considerations discussed in Sections 11.3 and 11.4 of Security considerations discussed in Sections 11.3 and 11.4 of
[RFC7252] should be taken into account. [RFC7252] should be taken into account.
OSCORE provides end-to-end protection of all information that is not OSCORE provides end-to-end protection of all information that is not
required for proxy operations and requires that a security context is required for proxy operations and requires that a security context is
skipping to change at page 38, line 16 skipping to change at page 39, line 36
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<https://www.rfc-editor.org/info/rfc8742>. <https://www.rfc-editor.org/info/rfc8742>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [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- [CSM] "CoAP Signaling Option Numbers",
parameters.xhtml#content-formats>. <https://www.iana.org/assignments/core-parameters/core-
parameters.xhtml#signaling-option-numbers>.
[Format] "CoAP Content-Formats", <https://www.iana.org/assignments/
core-parameters/core-parameters.xhtml#content-formats>.
[I-D.bosh-dots-quick-blocks] [I-D.bosh-dots-quick-blocks]
Boucadair, M. and J. Shallow, "Distributed Denial-of- Boucadair, M. and J. Shallow, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Signal Channel Service Open Threat Signaling (DOTS) Signal Channel
Configuration Attributes for Faster Block Transmission", Configuration Attributes for Faster Block Transmission",
draft-bosh-dots-quick-blocks-00 (work in progress), draft-bosh-dots-quick-blocks-00 (work in progress),
January 2021. January 2021.
[I-D.ietf-dots-telemetry] [I-D.ietf-dots-telemetry]
Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c., Boucadair, M., Reddy.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>.
[Options] , <https://www.iana.org/assignments/core-parameters/core- [Options] "CoAP Option Numbers", <https://www.iana.org/assignments/
parameters.xhtml#option-numbers>. core-parameters/core-parameters.xhtml#option-numbers>.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928, "Increasing TCP's Initial Window", RFC 6928,
DOI 10.17487/RFC6928, April 2013, DOI 10.17487/RFC6928, April 2013,
<https://www.rfc-editor.org/info/rfc6928>. <https://www.rfc-editor.org/info/rfc6928>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P.,
Mortensen, A., and N. Teague, "Distributed Denial-of- Mortensen, A., and N. Teague, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Signal Channel Service Open Threat Signaling (DOTS) Signal Channel
Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020,
<https://www.rfc-editor.org/info/rfc8782>. <https://www.rfc-editor.org/info/rfc8782>.
[RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and
Stateless Clients in the Constrained Application Protocol
(CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021,
<https://www.rfc-editor.org/info/rfc8974>.
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 16. All the blocks are acknowledged (ACK). shown in Figure 17. 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 16: Example of CON Request with Q-Block1 Option (Without Loss) Figure 17: Example of CON Request with Q-Block1 Option (Without Loss)
Now, suppose that a new body of data is to be sent but with some Now, suppose that a new body of data is to be sent but with some
blocks dropped in transmission as illustrated in Figure 17. The blocks dropped in transmission as illustrated in Figure 18. The
client will 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
skipping to change at page 40, line 28 skipping to change at page 41, line 47
+--->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
| ... | | ... |
[[ACK_TIMEOUT exponential backoff (client) delay expires]] [[ACK_TIMEOUT exponential backoff (client) delay expires]]
| [[Client retransmits associated packet]] | [[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 17: Example of CON Request with Q-Block1 Option (Blocks Figure 18: Example of CON Request with Q-Block1 Option (Blocks
Recovery) Recovery)
It is up to the implementation as to whether the application process It is up to the implementation as to whether the application process
stops trying to send this particular body of data on reaching stops trying to send this particular body of data on reaching
MAX_RETRANSMIT for any payload, or separately tries to initiate the MAX_RETRANSMIT for any payload, or separately tries to initiate the
new transmission of the payloads that have not been acknowledged new transmission of the payloads that have not been acknowledged
under these adverse traffic conditions. under these adverse traffic conditions.
If there is likely to be the possibility of network transient losses, If there is likely to be the possibility of 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 18. shown in Figure 19.
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]]
skipping to change at page 41, line 44 skipping to change at page 43, line 44
| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
|--------->+ ACK 0.00 M:0xe9 |--------->+ ACK 0.00 M:0xe9
| ... | | ... |
[[ACK_TIMEOUT exponential backoff (server) delay expires]] [[ACK_TIMEOUT exponential backoff (server) delay expires]]
| [[Server retransmits associated packet]] | [[Server retransmits associated packet]]
| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
| ... | | ... |
[[Either body transmission failure (acknowledge retry timeout) [[Either body transmission failure (acknowledge retry timeout)
or successfully transmitted.]] or successfully transmitted.]]
Figure 18: Example of CON Notifications with Q-Block2 Option Figure 19: Example of CON Notifications with Q-Block2 Option
It is up to the implementation as to whether the application process It is up to the implementation as to whether the application process
stops trying to send this particular body of data on reaching stops trying to send this particular body of data on reaching
MAX_RETRANSMIT for any payload, or separately tries to initiate the MAX_RETRANSMIT for any payload, or separately tries to initiate the
new transmission of the payloads that have not been acknowledged new transmission of the payloads that have not been acknowledged
under these adverse traffic conditions. under these adverse traffic conditions.
If there is likely to be the possibility of network transient losses, If there is likely to be the possibility of network transient losses,
then the use of NON should be considered. then the use of NON should be considered.
 End of changes. 87 change blocks. 
205 lines changed or deleted 293 lines changed or added

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