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