CORE M. Boucadair
Internet-Draft Orange
Intended status: Standards Track J. Shallow
Expires: October 16, 2020 April 14, 2020
New Constrained Application Protocol (CoAP) Block-Wise Transfer Options
draft-bosh-core-new-block-00
Abstract
This document specifies new Constrained Application Protocol (CoAP)
Block-Wise transfer options: Block3 and Block4 options. These
options are similar to the CoAP Block1 and Block2 options, but enable
faster transmissions of big blocks of data with less packet
interchanges as well as supporting faster recovery should any of the
Blocks get lost in transmission.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 16, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Boucadair & Shallow Expires October 16, 2020 [Page 1]
Internet-Draft New Block-Wise Transfer Options April 2020
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Existing Block-Wise Transfer Options . . . . . . . . . . 2
1.2. New Block-Wise Transfer Options . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Block3 and Block4 Options . . . . . . . . . . . . . . . . 4
3.1. Properties of Block3 ad Block4 Options . . . . . . . . . 4
3.2. Structure of Block3 and Block4 Options . . . . . . . . . 5
3.3. Working with Observe . . . . . . . . . . . . . . . . . . 8
3.4. Working with Size1 and Size2 Options . . . . . . . . . . 8
3.5. Working with Etag Option . . . . . . . . . . . . . . . . 8
4. Caching Considerations . . . . . . . . . . . . . . . . . . . 9
5. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 9
6. Examples of Selective Block Recovery . . . . . . . . . . . . 9
6.1. Block3 Option: Non-Confirmable Example . . . . . . . . . 10
6.2. Block4 Option: Non-Confirmable Example . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Examples with Confirmable Messages . . . . . . . . . 15
A.1. Block3 Option . . . . . . . . . . . . . . . . . . . . . . 15
A.2. Block4 Option . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
1.1. Existing Block-Wise Transfer Options
The Constrained Application Protocol (CoAP) [RFC7252], although
inspired by HTTP, was designed to use UDP instead of TCP. The
message layer of CoAP over UDP includes support for reliable
delivery, simple congestion control, and flow control. [RFC7959]
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
fragmentation.
The CoAP Block1 and Block2 options work well in environments where
there are no or minimal packet losses. They operate synchronously
where each block has to be requested and can only ask for (or send)
the next block when the request for the previous Block has completed.
Boucadair & Shallow Expires October 16, 2020 [Page 2]
Internet-Draft New Block-Wise Transfer Options April 2020
Packet, and hence Block transmission rate, is controlled by Round
Trip Times.
There is a requirement for these Blocks of data to be transmitted
under network conditions where there may be transient packet loss
such as when a network is subject to a Distributed Denial Of Service
(DDoS) attack and there is a need for DDoS mitigation agents need to
communicate with each other (e.g., [I-D.ietf-dots-telemetry]). As a
reminder, [RFC7959] recommends use of Confirmable (CON) responses to
handle potential packet loss; which does not work with a flooded pipe
DDoS situation.
1.2. New Block-Wise Transfer Options
This document introduces the CoAP Block3 and Block4 options. These
options are similar in operation to the CoAP Block1 and Block2
options respectively, but enable faster transmissions of big blocks
of data with less packet interchanges as well as supporting faster
recovery should any of the Blocks get lost in transmission.
The faster transmissions occur as all the Blocks can be transmitted
serially (as are IP fragmented packets) without having to wait for an
acknowledgement from the remote CoAP peer. Recovery of missing
Blocks is faster in that multiple missing Blocks can be requested in
a single packet.
Non-Confirmable (NON) request usage of Block3 and Non-Confirmable
response usage of Block4 enable the faster transmissions of the
blocks of the body message as there is no need to wait for the
responses. Note that the same performance benefits can be applied to
Confirmable messages if the value of NSTART is increased from 1
(Section 4.7 of [RFC7252]). Some sample examples with Confirmable
messages are provided in Appendix A.
A CoAP endpoint can acknowledge all or a subset of the blocks.
Concretely, the receiving CoAP endpoint informs the CoAP endpoint
sender about all blocks that have been received. The CoAP endpoint
sender will then retransmit only the blocks that have been lost in
transmission.
Only the deviation from Block1 and Block2 options are specified.
Pointers to appropriate [RFC7959] sections are provided.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
Boucadair & Shallow Expires October 16, 2020 [Page 3]
Internet-Draft New Block-Wise Transfer Options April 2020
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
Readers should be familiar with the terms and concepts defined in
[RFC7252].
The terms "payload" and "body" are defined in [RFC7959]. The term
"payload" is thus used for the content of a single CoAP message
(i.e., a single block being transferred), while the term "body" is
used for the entire resource representation that is being transferred
in a block-wise fashion.
3. The Block3 and Block4 Options
3.1. Properties of Block3 ad Block4 Options
The properties of Block3 and Block4 options are shown in Table 1.
The formatting of this table follows the one used in Table 4 of
[RFC7252] (Section 5.10). The C, U, N, and R columns indicate the
properties Critical, Unsafe, NoCacheKey, and Repeatable defined in
Section 5.4 of [RFC7252]. Only C and R columns are marked for Block3
and Block4 options.
+--------+---+---+---+---+-----------+--------+--------+---------+
| Number | C | U | N | R | Name | Format | Length | Default |
+========+===+===+===+===+===========+========+========+=========+
| TBA1 | x | | | x | Block3 | uint | 0-7 | (none) |
| TBA2 | x | | | x | Block4 | uint | 0-7 | (none) |
+--------+---+---+---+---+-----------+--------+--------+---------+
Table 1: CoAP Block3 and Block4 Option Properties
The Block3 option pertains to the request payload, and the Block4
option pertains to the response payload. The Content-Format option
applies to the body, not to the payload.
For the methods defined in [RFC7252] and [RFC8132], Block3 is useful
with the payload-bearing POST, PUT, and PATCH requests and their
responses. Block4 is useful with GET, POST, PUT, and FETCH requests
and their payload-bearing responses (2.01, 2.02, 2.04, and 2.05)
(Section 5.5 of [RFC7252]).
To indicate support for Block4 responses, the CoAP client MUST
include the Block4 option in a GET or FETCH request so that the
server knows that the client supports this functionality. Otherwise,
the server would use the Block2 option (if supported) to send back a
message body that is larger than can fit into a single IP packet
[RFC7959].
Boucadair & Shallow Expires October 16, 2020 [Page 4]
Internet-Draft New Block-Wise Transfer Options April 2020
Where Block3 option is present in a request or Block4 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
(referred to as "descriptive usage"). Where it is present in the
opposite direction, it provides additional control on how that
payload will be formed or was processed (referred to as "control
usage").
Implementation of either block option is intended to be optional.
However, when it is present in a CoAP message, it MUST be processed
(or the message rejected); therefore, it is identified as a Critical
option.
The Block3 and Block4 options are safe to forward. That is, a CoAP
proxy that does not understand the Block3 and Block4 options should
forward the options on.
Both Block3 and Block4 options are repeatable when requesting re-
transmissions of missing Blocks but not otherwise. Otherwise, any
request carrying multiple Block3 (or Block4) options MUST be handled
following the procedure specified in Section 5.4.5 of [RFC7252].
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
that does not respond. The body of blocks will be subjected to
probing rate.
3.2. Structure of Block3 and Block4 Options
The structure of Block3 and Block4 options follows the structure
defined in Section 2.2 of [RFC7959] with two additional fields:
o The Block ID (BID) which associates all the Blocks that make up
the large item of data that is being transferred.
o The "All" bit (called, A-bit) used when acknowledging all the
blocks.
As such, five items of information may need to be transferred in a
Block3 or Block4 option:
o the size of the block (size exponent (SZX)),
o whether more blocks are following (More (M)),
o the relative number of the block (Block Number (NUM)) within a
sequence of blocks with the given size,
Boucadair & Shallow Expires October 16, 2020 [Page 5]
Internet-Draft New Block-Wise Transfer Options April 2020
o whether this is acknowledging all the blocks successfully received
(A), and
o the Block identifier number (BID) that is common to the sequence
of blocks with the same given size. The BID is different for each
set of sequence of blocks.
The value of the Block3 or Block4 option is a variable-size (0 to 7
byte) unsigned integer (uint) (Section 3.2 of [RFC7252]). This
integer value encodes the aforementioned five fields as shown in
Figure 1. Note that, due to the CoAP uint-encoding rules, when all
of NUM, M, SZX, A, and BID happen to be zero, a zero-byte integer
will be sent.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BID |A| NUM |M| SZX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BID |A| NUM
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NUM |M| SZX |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BID |A| NUM
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NUM |M| SZX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BID |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUM |M| SZX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Structure of Block3 and Block4 Options
Boucadair & Shallow Expires October 16, 2020 [Page 6]
Internet-Draft New Block-Wise Transfer Options April 2020
The twenty-fourth least significant bit is the A-bit ("val &
0x1000000").
The option value shifted right by 25 ("(val >> 25)")(the BID field)
is the Block identifier that identifies which sequence of blocks this
particular block is in.
The current transfer is about the "size" bytes starting at byte "NUM
<< (SZX + 4)".
Within the option value of a Block3 or Block4 option, the meaning of
the option fields is defined below. Note that the block size (SZX,
size exponent), the M-bit, and the NUM fields are defined in
Section 2.2 of [RFC7959], but are provided below for the reader's
convenience:
A: All Flag. This bit is only set in a response packet to indicate
that this response refers to all of the blocks in the body. The
A-bit MUST be unset in all other cases.
BID: Block Identifier. This block identifier is the same for all
of the blocks in the body of data that is being transferred. It
is used when a particular block needs to be re-transmitted.
This value MUST be different for distinct sets of blocks of data
and SHOULD be incremented whenever a new body of data is being
transmitted for a CoAP session between peers. The initial BID
value SHOULD be randomly generated.
NUM: Block Number, indicating the block number being requested or
provided. Block number '0' indicates the first block of a body
(i.e., starting with the first byte of the body).
M: More Flag ("not last block"). For descriptive usage, this flag,
if unset, indicates that the payload in this message is the last
block in the body; when set, it indicates that there are one or
more additional blocks available.
When a Block4 option is used in a request to retrieve a specific
block number ("control usage"), the M-bit MUST be sent as zero and
ignored on reception. In a Block3 option in a response, the M-bit
is used to indicate atomicity, similar to Block1 option
([RFC7959]).
SZX: Block Size. The block size is represented as a three-bit
unsigned integer indicating the size of a block to the power of
two. Thus, block size = 2**(SZX + 4). The allowed values of SZX
are 0 to 6, i.e., the minimum block size is 2**(0+4) = 16 and the
Boucadair & Shallow Expires October 16, 2020 [Page 7]
Internet-Draft New Block-Wise Transfer Options April 2020
maximum is 2**(6+4) = 1024. The value 7 for SZX (which would
indicate a block size of 2048) is used as a BERT option in
[RFC8323].
There is no default value for the Block3 and Block4 options. Absence
of one of these options is equivalent to an option value of 0 with
respect to the value of NUM, M, A, and BID that could be given in the
option, i.e., it indicates that the current block is the first and
only block of the transfer (block number is set to 0, M-bit is unset,
A-bit is unset, and BID is set to 0). However, in contrast to the
explicit value 0, which would indicate an SZX of 0, and thus a size
value of 16 bytes, there is no specific explicit size implied by the
absence of the option -- the size is left unspecified. (As for any
uint, the explicit value 0 is efficiently indicated by a zero-length
option; this, therefore, is different in semantics from the absence
of the option).
3.3. Working with Observe
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.
Likewise, the Tokens MUST all have the same value for all the blocks
of the same body. This is so that if any of the blocks gets lost
during transmission (including the first one), the receiving CoAP
endpoint can take the appropriate decisions (implementation-
specific).
3.4. Working with Size1 and Size2 Options
[RFC7959] defines two CoAP options, Size1 for indicating the size of
the representation transferred in requests, and Size2 for indicating
the size of the representation transferred in responses.
It is RECOMMENDED that the Size1 option is used with the Block3
option and that the Size2 option is used with the Block4 option.
3.5. Working with Etag Option
The Etag option defined in Section 5.10.6 of [RFC7252] applies to the
whole representation of the resource, and thus to the body of the
response.
Boucadair & Shallow Expires October 16, 2020 [Page 8]
Internet-Draft New Block-Wise Transfer Options April 2020
4. Caching Considerations
The Block3 and Block4 options are part of the cache key. As such, a
CoAP proxy that does not understand the Block3 and Block4 options
must follow the recommendations in Section 5.7.1 of [RFC7252] for
caching.
This specification does not require a proxy to obtain the complete
representation before it serves parts of it to the client.
Otherwise, the considerations discussed in Section 2.10 of [RFC7959]
apply for the Block3 and Block4 options (with Block3 substituted for
Block1 and Block4 substituted for Block2) for proxies that support
Block3 and Block4 options.
A proxy that supports Block3 and Block4 options MUST be prepared to
receive a GET message indicating one or more missing blocks. The
proxy can serve from its cache missing blocks that are available in
its cache. If one more requested blocks are not available locally,
the proxy MUST update the GET request with the blocks that it served
locally, and then forward the request to the next hop. When the
proxy replies from its local cache, it MUST use the same Token value
as in the received request.
How long a CoAP endpoint (or proxy) keeps the body in its cache is
implementation-specific (e.g., it may be based on Max-Age).
5. HTTP-Mapping Considerations
As a reminder, the basic normative requirements on HTTP/CoAP mappings
are defined in Section 10 of [RFC7252]. The implementation
guidelines for HTTP/CoAP mappings are elaborated in [RFC8075].
The rules defined in Section 5 of [RFC7959] are to be followed.
6. Examples of Selective Block Recovery
This section provides some sample flows to illustrate the use of
Block3 and Block4 options. The following conventions are used in the
following sub-sections:
T: Token value
O: Observe Option value
M: Message ID
B3: Block3 option values BID/All/NUM/More/SZX
B4: Block3 option values BID/All/NUM/More/SZX
\: Trimming long lines
[[]]: Comments
---X: Message loss
Boucadair & Shallow Expires October 16, 2020 [Page 9]
Internet-Draft New Block-Wise Transfer Options April 2020
6.1. Block3 Option: Non-Confirmable Example
Figure 2 depicts an example of a NON PUT request conveying Block3
option. All the blocks are received by the server; hence the A-bit
is set in the 2.05 message sent by the server to the client.
CoAP CoAP
Client Server
| |
+--------->| NON PUT /path M:0x01 T:0xf0 B3:10/0/0/1/1024
+--------->| NON PUT /path M:0x02 T:0xf0 B3:10/0/1/1/1024
+--------->| NON PUT /path M:0x03 T:0xf0 B3:10/0/2/1/1024
+--------->| NON PUT /path M:0x04 T:0xf0 B3:10/0/3/0/1024
|<---------+ NON 2.05 M:0xf1 T:0xf0 B3:10/1/0/0/1024
...
Figure 2: Example of NON Request with Block3 Option (Without Loss)
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
Figure 3.
CoAP CoAP
Client Server
| |
+--------->| NON PUT /path M:0x05 T:0xf0 B3:11/0/0/1/1024
+----X | NON PUT /path M:0x06 T:0xf0 B3:11/0/1/1/1024
+----X | NON PUT /path M:0x07 T:0xf0 B3:11/0/2/1/1024
+--------->| NON PUT /path M:0x08 T:0xf0 B3:11/0/3/1/1024
| |
...
Figure 3: Example of NON Request with Block3 Option (With Loss)
The server realizes that some blocks are missing and asks for the
missing ones in one go (Figure 4). It does so by indicating which
blocks have been received.
Boucadair & Shallow Expires October 16, 2020 [Page 10]
Internet-Draft New Block-Wise Transfer Options April 2020
CoAP CoAP
Client Server
| |
...
|<---------+ NON 2.05 M:0xf2 T:0xf0 B3:11/0/0/0/1024\
| | B3:11/0/3/0/1024
+--------->| NON PUT /path M:0x09 T:0xf1 B3:11/0/1/1/1024
+----X | NON PUT /path M:0x0a T:0xf1 B3:11/0/2/1/1024
| |
[[This can be split across several packets if too large]]
|<---------+ NON 2.05 M:0xf3 T:0xf1 B3:11/0/0/0/1024\
| | B3:11/0/1/1/1024\
| | B3:11/0/3/0/1024
+--------->| NON PUT /path M:0x0b T:0xf2 B3:10/0/3/0/1024
|<---------+ NON 2.05 M:0xf4 T:0xf2 B3:10/1/0/0/1024
| |
...
Figure 4: Example of NON Request with Block3 Option (Blocks Recovery)
Under high levels of traffic loss, the client can elect not to retry
sending missing blocks of data. This decision is implementation-
specific.
6.2. Block4 Option: Non-Confirmable Example
Figure 5 illustrates the example of Block4 option. The client sends
a NON GET carrying an Observe and a Block4 options. The Block4
option indciates a size hint (1024 bytes). This request is replied
by the serer using four (4) blocks that are transmitetted to the
client without any loss. Each of these blocks carries a Block4
option. The same process is repeated when an Observe is triggered,
but no loss is experienced by any of of the notification bloks.
Boucadair & Shallow Expires October 16, 2020 [Page 11]
Internet-Draft New Block-Wise Transfer Options April 2020
CoAP CoAP
Client Server
| |
+--------->| NON GET /path M:0x01 T:0xf0 O:0 B4:0/0/0/0/1024
|<---------+ NON 2.05 M:0xf1 T:0xf0 O:1234 B4:21/0/0/1/1024
|<---------+ NON 2.05 M:0xf2 T:0xf0 O:1234 B4:21/0/1/1/1024
|<---------+ NON 2.05 M:0xf3 T:0xf0 O:1234 B4:21/0/2/1/1024
|<---------+ NON 2.05 M:0xf4 T:0xf0 O:1234 B4:21/0/3/0/1024
...
[[Observe triggered]]
|<---------+ NON 2.05 M:0xf5 T:0xf0 O:1235 B4:22/0/0/1/1024
|<---------+ NON 2.05 M:0xf6 T:0xf0 O:1235 B4:22/0/1/1/1024
|<---------+ NON 2.05 M:0xf7 T:0xf0 O:1235 B4:22/0/2/1/1024
|<---------+ NON 2.05 M:0xf8 T:0xf0 O:1235 B4:22/0/3/0/1024
...
Figure 5: Example of NON Notifications with Block4 Option (Without
Loss)
Figure 6 shows the example of an Observe that is triggered but for
which some notification blocks are lost. The client detects the
missing blocks and request their retransmission. It does so by
indicating the blocks that were successfully received.
Boucadair & Shallow Expires October 16, 2020 [Page 12]
Internet-Draft New Block-Wise Transfer Options April 2020
CoAP CoAP
Client Server
| |
...
[[Observe triggered]]
|<---------+ NON 2.05 M:0xf9 T:0xf0 O:1236 B4:23/0/0/1/1024
| X<-----+ NON 2.05 M:0xfa T:0xf0 O:1236 B4:23/0/1/1/1024
| X<-----+ NON 2.05 M:0xfb T:0xf0 O:1236 B4:23/0/2/1/1024
|<---------+ NON 2.05 M:0xfc T:0xf0 O:1236 B4:23/0/3/0/1024
| |
[[Client realises blocks are missing and asks for the missing
ones in one go]]
+--------->| NON GET /path M:0x02 T:0xf1 B4:23/0/1/0/1024\
| | B4:23/0/2/0/1024
| X<-----+ NON 2.05 M:0xfd T:0xf1 B4:23/0/1/1/1024
|<---------+ NON 2.05 M:0xfe T:0xf1 B4:23/0/2/1/1024
| |
[[Get final missing block]]
+--------->| NON GET /path M:0x03 T:0xf2 B4:23/0/1/0/1024
|<---------+ NON 2.05 M:0xff T:0xf2 B4:23/0/1/1/1024
...
Figure 6: Example of NON Notifications with Block4 Option (Blocks
Recovery)
Under high levels of traffic loss, the client can elect not to retry
getting missing blocks of data. This decision is implementation-
specific.
7. IANA Considerations
IANA is requested to add the following entries to the "CoAP Option
Numbers" sub-registry available at https://www.iana.org/assignments/
core-parameters/core-parameters.xhtml#option-numbers:
+--------+------------------+-----------+
| Number | Name | Reference |
+========+==================+===========+
| TBA1 | Block3 | [RFCXXXX] |
| TBA2 | Block4 | [RFCXXXX] |
+--------+------------------+-----------+
Table 2: CoAP Block3 and Block4 Option Numbers
This document suggests XX and XX as a values to be assigned for the
new option numbers.
Boucadair & Shallow Expires October 16, 2020 [Page 13]
Internet-Draft New Block-Wise Transfer Options April 2020
8. Security Considerations
Security considerations discussed in Section 9 of [RFC7959] should be
taken into account.
[[discuss iof any security issues related to the incremental BID
values. Lifetime of a BID (pointer to RFC8200)]]
9. Acknowledgements
Thanks to Achim Kraus, Christian Amsuess, Carsten Bormann, Jim Schaad
for the comments on the mailing list.
Some text from [RFC7959] is reused for readers convenience.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/info/rfc7959>.
[RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
E. Dijk, "Guidelines for Mapping Implementations: HTTP to
the Constrained Application Protocol (CoAP)", RFC 8075,
DOI 10.17487/RFC8075, February 2017,
<https://www.rfc-editor.org/info/rfc8075>.
Boucadair & Shallow Expires October 16, 2020 [Page 14]
Internet-Draft New Block-Wise Transfer Options April 2020
[RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and
FETCH Methods for the Constrained Application Protocol
(CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,
<https://www.rfc-editor.org/info/rfc8132>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>.
10.2. Informative References
[I-D.ietf-dots-telemetry]
Boucadair, M., Reddy.K, T., Doron, E., and c. chenmeiling,
"Distributed Denial-of-Service Open Threat Signaling
(DOTS) Telemetry", draft-ietf-dots-telemetry-06 (work in
progress), April 2020.
Appendix A. Examples with Confirmable Messages
These examples assume NSTART has been increased to at least 4.
A.1. Block3 Option
Let's now consider the use Block3 option with a CON request as shown
in Figure 7. All the blocks are acknowledged (ACK).
CoAP CoAP
Client Server
| |
+--------->| CON PUT /path M:0x01 T:0xf0 B3:10/0/0/1/1024
+--------->| CON PUT /path M:0x02 T:0xf0 B3:10/0/1/1/1024
+--------->| CON PUT /path M:0x03 T:0xf0 B3:10/0/2/1/1024
+--------->| CON PUT /path M:0x04 T:0xf0 B3:10/0/3/0/1024
|<---------+ ACK 0.00 M:0x01
|<---------+ ACK 0.00 M:0x02
|<---------+ ACK 0.00 M:0x03
|<---------+ ACK 0.00 M:0x04
Figure 7: Example of CON Request with Block3 Option (Without Loss)
Boucadair & Shallow Expires October 16, 2020 [Page 15]
Internet-Draft New Block-Wise Transfer Options April 2020
Now, suppose that a new body of data is to sent but with some blocks
dropped in transmission as illustrated in Figure 8. The client will
retry sedning blocks for which no ACK was received.
CoAP CoAP
Client Server
| |
+--------->| NON PUT /path M:0x05 T:0xf0 B3:11/0/0/1/1024
+----X | NON PUT /path M:0x06 T:0xf0 B3:11/0/1/1/1024
+----X | NON PUT /path M:0x07 T:0xf0 B3:11/0/2/1/1024
+--------->| NON PUT /path M:0x08 T:0xf0 B3:11/0/3/1/1024
|<---------+ ACK 0.00 M:0x05
|<---------+ ACK 0.00 M:0x08
| |
[[The client retries sending packets not acknowledged]]
+--------->| NON PUT /path M:0x09 T:0xf0 B3:11/0/1/1/1024
+----X | NON PUT /path M:0x0a T:0xf0 B3:11/0/2/1/1024
|<---------+ ACK 0.00 M:0x09
| |
[[The client retransmits messages not acknowledged
(exponential backoff)]]
+----? | NON PUT /path M:0x0a T:0xf0 B3:11/0/2/1/1024
| |
[[Either transmission failure (acknowledge retry timeout)
or successfully transmitted.]]
Figure 8: Example of CON Request with Block3 Option (Blocks Recovery)
It is implementation dependent as to whether a CoAP session is
terminated following acknowledge retry timeout, or whether the CoAP
session continues to be used under such adverse traffic conditions.
If there is likely to be the possibility of network transient losses,
then the use of Non-Confirmable traffic should be considered.
A.2. Block4 Option
An exmaple of the use of Block4 option with Confirmable messages is
shown in Figure 9.
Boucadair & Shallow Expires October 16, 2020 [Page 16]
Internet-Draft New Block-Wise Transfer Options April 2020
Client Server
| |
+--------->| CON GET /path M:0x01 T:0xf0 O:0 B4:0/0/0/0/1024
|<---------+ ACK 2.05 M:0x01 T:0xf0 O:1234 B4:21/0/0/1/1024
|<---------+ ACK 2.05 M:0xe1 T:0xf0 O:1234 B4:21/0/1/1/1024
|<---------+ ACK 2.05 M:0xe2 T:0xf0 O:1234 B4:21/0/2/1/1024
|<---------+ ACK 2.05 M:0xe3 T:0xf0 O:1235 B4:21/0/3/0/1024
...
[[Observe triggered]]
|<---------+ CON 2.05 M:0xe4 T:0xf0 O:1235 B4:22/0/0/1/1024
|<---------+ CON 2.05 M:0xe5 T:0xf0 O:1235 B4:22/0/1/1/1024
|<---------+ CON 2.05 M:0xe6 T:0xf0 O:1235 B4:22/0/2/1/1024
|<---------+ CON 2.05 M:0xe7 T:0xf0 O:1235 B4:22/0/3/0/1024
|--------->+ ACK 0.00 M:0xe4
|--------->+ ACK 0.00 M:0xe5
|--------->+ ACK 0.00 M:0xe6
|--------->+ ACK 0.00 M:0xe7
...
[[Observe triggered]]
|<---------+ CON 2.05 M:0xe8 T:0xf0 O:1236 B4:23/0/0/1/1024
| X<-----+ CON 2.05 M:0xe9 T:0xf0 O:1236 B4:23/0/1/1/1024
| X<-----+ CON 2.05 M:0xea T:0xf0 O:1236 B4:23/0/2/1/1024
|<---------+ CON 2.05 M:0xeb T:0xf0 O:1236 B4:23/0/3/0/1024
|--------->+ ACK 0.00 M:0xe8
|--------->+ ACK 0.00 M:0xeb
| |
[[Server retransmits messages not acknowledged]]
|?--------+ CON 2.05 M:0xec T:0xf0 O:1236 B4:23/0/1/1/1024
| X<-----+ CON 2.05 M:0xed T:0xf0 O:1236 B4:23/0/2/1/1024
|--------->+ ACK 0.00 M:0xec
| |
[[Server retransmits messages not acknowledged
(exponential backoff)]]
|?--------+ CON 2.05 M:0xee T:0xf0 O:1236 B4:23/0/1/1/1024
| X<-----+ CON 2.05 M:0xee T:0xf0 O:1236 B4:23/0/2/1/1024
| |
[[Either transmission failure (acknowledge retry timeout)
or successfully transmitted.]]
Figure 9: Example of CON Notifications with Block4 Option
It is implementation-dependent as to whether a CoAP session is
terminated following acknowledge retry timeout, or whether the CoAP
session continues to be used under such adverse traffic conditions.
If there is likely to be the possibility of network transient losses,
then the use of Non-Confirmable traffic should be considered.
Boucadair & Shallow Expires October 16, 2020 [Page 17]
Internet-Draft New Block-Wise Transfer Options April 2020
Authors' Addresses
Mohamed Boucadair
Orange
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Jon Shallow
United Kingdom
Email: supjps-ietf@jpshallow.com
Boucadair & Shallow Expires October 16, 2020 [Page 18]