draft-ietf-core-new-block-12.txt   draft-ietf-core-new-block-13.txt 
CoRE Working Group M. Boucadair CoRE Working Group M. Boucadair
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track J. Shallow Intended status: Standards Track J. Shallow
Expires: November 12, 2021 May 11, 2021 Expires: November 22, 2021 May 21, 2021
Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Constrained Application Protocol (CoAP) Block-Wise Transfer Options
Faster Transmission Supporting Robust Transmission
draft-ietf-core-new-block-12 draft-ietf-core-new-block-13
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, but distinct from, the CoAP Block1 and These options are similar to, but distinct from, the CoAP Block1 and
Block2 Options defined in RFC 7959. Q-Block1 and Q-Block2 Options Block2 Options defined in RFC 7959. Q-Block1 and Q-Block2 Options
are not intended to replace Block1 and Block2 Options, but rather are not intended to replace Block1 and Block2 Options, but rather
have the goal of enabling faster transmission rates for large amounts have the goal of supporting Non-confirmable messages for large
of data with fewer packet interchanges. Also, the Q-Block1 and amounts of data with fewer packet interchanges. Also, the Q-Block1
Q-Block2 Options support faster recovery should any of the blocks get and Q-Block2 Options support faster recovery should any of the blocks
lost in transmission. get lost in transmission.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 12, 2021. This Internet-Draft will expire on November 22, 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 21 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Alternative CoAP Block-Wise Transfer Options . . . . . . . . 5 3. Alternative CoAP Block-Wise Transfer Options . . . . . . . . 5
3.1. CoAP Response Code (4.08) Usage . . . . . . . . . . . . . 7 3.1. CoAP Response Code (4.08) Usage . . . . . . . . . . . . . 7
3.2. Applicability Scope . . . . . . . . . . . . . . . . . . . 7 3.2. Applicability Scope . . . . . . . . . . . . . . . . . . . 7
4. The Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 8 4. The Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 8
4.1. Properties of Q-Block1 and Q-Block2 Options . . . . . . . 8 4.1. Properties of Q-Block1 and Q-Block2 Options . . . . . . . 8
4.2. Structure of Q-Block1 and Q-Block2 Options . . . . . . . 10 4.2. Structure of Q-Block1 and Q-Block2 Options . . . . . . . 10
4.3. Using the Q-Block1 Option . . . . . . . . . . . . . . . . 10 4.3. Using the Q-Block1 Option . . . . . . . . . . . . . . . . 11
4.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 14 4.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 15
4.5. Using Observe Option . . . . . . . . . . . . . . . . . . 17 4.5. Using Observe Option . . . . . . . . . . . . . . . . . . 17
4.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 17 4.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 17
4.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 17 4.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 18
4.8. Using Q-Block2 Option With Multicast . . . . . . . . . . 17 4.8. Using Q-Block2 Option With Multicast . . . . . . . . . . 18
5. The Use of 4.08 (Request Entity Incomplete) Response Code . . 17 5. The Use of 4.08 (Request Entity Incomplete) Response Code . . 18
6. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 19 6. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 19
7. Congestion Control for Unreliable Transports . . . . . . . . 19 7. Congestion Control for Unreliable Transports . . . . . . . . 20
7.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 19 7.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 20
7.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 20 7.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 20
8. Caching Considerations . . . . . . . . . . . . . . . . . . . 24 8. Caching Considerations . . . . . . . . . . . . . . . . . . . 24
9. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 25 9. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 25
10. Examples with Non-confirmable Messages . . . . . . . . . . . 25 10. Examples with Non-confirmable Messages . . . . . . . . . . . 25
10.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . 26 10.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . 26
10.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 26 10.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 26
10.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 26 10.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 26
10.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 26 10.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 27
10.1.4. Handling Recovery with Failure . . . . . . . . . . . 28 10.1.4. Handling Recovery with Failure . . . . . . . . . . . 28
10.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . 29 10.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . 29
10.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 29 10.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 29
10.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 30 10.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 30
10.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 31 10.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 31
10.2.4. Handling Recovery using M-bit Set . . . . . . . . . 32 10.2.4. Handling Recovery using M-bit Set . . . . . . . . . 32
10.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . 33 10.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . 33
10.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 33 10.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 33
10.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 34 10.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 34
10.3.3. Handling Recovery . . . . . . . . . . . . . . . . . 35 10.3.3. Handling Recovery . . . . . . . . . . . . . . . . . 35
skipping to change at page 3, line 26 skipping to change at page 3, line 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
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. CoAP supports delivery, simple congestion control, and flow control. CoAP supports
two message types (Section 1.2 of [RFC7252]): Confirmable (CON) and two message types (Section 1.2 of [RFC7252]): Confirmable (CON) and
Non-confirmable (NON) messages. Unlike NON messages, every CON Non-confirmable (NON) messages. Unlike NON messages, every CON
message will elect an acknowledgement or a reset. message will elicit an acknowledgement or a reset.
The CoAP specification recommends that a CoAP message should fit The CoAP specification recommends that a CoAP message should fit
within a single IP packet (i.e., avoid IP fragmentation). To handle within a single IP packet (i.e., avoid IP fragmentation). To handle
data records that cannot fit in a single IP packet, [RFC7959] data records that cannot fit in a single IP packet, [RFC7959]
introduced the concept of block-wise transfer and the companion CoAP introduced the concept of block-wise transfer and the companion CoAP
Block1 and Block2 Options. However, this concept is designed to work Block1 and Block2 Options. However, this concept is designed to work
exclusively with Confirmable messages (Section 1 of [RFC7959]). Note exclusively with Confirmable messages (Section 1 of [RFC7959]). Note
that the block-wise transfer was further updated by [RFC8323] for use that the block-wise transfer was further updated by [RFC8323] for use
over TCP, TLS, and WebSockets. over TCP, TLS, and WebSockets.
The CoAP Block1 and Block2 Options work well in environments where The CoAP Block1 and Block2 Options work well in environments where
there are no, or minimal, packet losses. These options operate there are no, or minimal, packet losses. These options operate
synchronously, i.e., each individual block has to be requested. A synchronously, i.e., each individual block has to be requested. A
CoAP endpoint can only ask for (or send) the next block when the CoAP endpoint can only ask for (or send) the next block when the
transfer of the previous block has completed. Packet transmission transfer of the previous block has completed. Packet transmission
rate, and hence block transmission rate, is controlled by Round Trip rate, and hence block transmission rate, is controlled by Round Trip
Times (RTTs). Times (RTTs).
There is a requirement for blocks of data larger than a single IP There is a requirement for blocks of data larger than a single IP
datagram to be transmitted at higher rates under network conditions datagram to be transmitted under network conditions where there may
where there may be asymmetrical transient packet loss (e.g., be asymmetrical transient packet loss (e.g., acknowledgment responses
responses may get dropped). An example is when a network is subject may get dropped). An example is when a network is subject to a
to a Distributed Denial of Service (DDoS) attack and there is a need Distributed Denial of Service (DDoS) attack and there is a need for
for DDoS mitigation agents relying upon CoAP to communicate with each DDoS mitigation agents relying upon CoAP to communicate with each
other (e.g., [RFC8782][I-D.ietf-dots-telemetry]). As a reminder, other (e.g., [RFC8782][I-D.ietf-dots-telemetry]). As a reminder,
[RFC7959] recommends the use of CON responses to handle potential [RFC7959] recommends the use of CON responses to handle potential
packet loss. However, such a recommendation does not work with a packet loss. However, such a recommendation does not work with a
flooded pipe DDoS situation (e.g., [RFC8782]). flooded pipe DDoS situation (e.g., [RFC8782]).
This document introduces the CoAP Q-Block1 and Q-Block2 Options which This document introduces the CoAP Q-Block1 and Q-Block2 Options which
allow block-wise transfer to work with series of Non-confirmable allow block-wise transfer to work with series of Non-confirmable
messages, instead of lock-stepping using Confirmable messages messages, instead of lock-stepping using Confirmable messages
(Section 3). In other words, this document provides a missing piece (Section 3). In other words, this document provides a missing piece
of [RFC7959], namely the support of block-wise transfer using Non- of [RFC7959], namely the support of block-wise transfer using Non-
confirmable where an entire body of data can be transmitted without confirmable where an entire body of data can be transmitted without
the requirement for an acknowledgement (but recovery is available the requirement that intermediate acknowledgments be received from
should it be needed). the peer (but recovery is available should it be needed).
Similar to [RFC7959], this specification does not remove any of the Similar to [RFC7959], this specification does not remove any of the
constraints posed by the base CoAP specification [RFC7252] it is constraints posed by the base CoAP specification [RFC7252] it is
strictly layered on top of. strictly layered on top of.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
skipping to change at page 5, line 6 skipping to change at page 5, line 6
in a block-wise fashion. in a block-wise fashion.
Request-Tag refers to an option that allows a CoAP server to match Request-Tag refers to an option that allows a CoAP server to match
message fragments belonging to the same request message fragments belonging to the same request
[I-D.ietf-core-echo-request-tag]. [I-D.ietf-core-echo-request-tag].
MAX_PAYLOADS is the maximum number of payloads that can be MAX_PAYLOADS is the maximum number of payloads that can be
transmitted at any one time. transmitted at any one time.
MAX_PAYLOADS_SET is the set of blocks identified by block numbers MAX_PAYLOADS_SET is the set of blocks identified by block numbers
that, when divided by MAX_PAYLOADS, they have the same numeric that, when divided by MAX_PAYLOADS, have the same numeric result.
result. For example, if MAX_PAYLOADS is set to '10', a For example, if MAX_PAYLOADS is set to '10', a MAX_PAYLOADS_SET could
MAX_PAYLOADS_SET could be blocks #0 to #9, #10 to #19, etc. be blocks #0 to #9, #10 to #19, etc. Depending on the overall data
Depending on the data size, the MAX_PAYLOADS_SET may not comprise all size, there could be fewer than MAX_PAYLOADS blocks in the final
the MAX_PAYLOADS blocks. MAX_PAYLOADS_SET.
3. Alternative CoAP Block-Wise Transfer Options 3. Alternative CoAP Block-Wise Transfer Options
This document introduces the CoAP Q-Block1 and Q-Block2 Options. This document introduces the CoAP Q-Block1 and Q-Block2 Options.
These options are designed to work in particular with NON requests These options are designed to work in particular with NON requests
and responses. and responses.
Using NON messages, the faster transmissions occur as all the blocks Using NON messages, faster transmissions can occur as all the blocks
can be transmitted serially (akin to fragmented IP packets) without can be transmitted serially (akin to fragmented IP packets) without
having to wait for a response or next request from the remote CoAP having to wait for a response or next request from the remote CoAP
peer. Recovery of missing blocks is faster in that multiple missing peer. Recovery of missing blocks is faster in that multiple missing
blocks can be requested in a single CoAP message. Even if there is blocks can be requested in a single CoAP message. Even if there is
asymmetrical packet loss, a body can still be sent and received by asymmetrical packet loss, a body can still be sent and received by
the peer whether the body comprises a single or multiple payloads, the peer whether the body comprises a single or multiple payloads,
assuming no recovery is required. assuming no recovery is required.
A CoAP endpoint can acknowledge all or a subset of the blocks. A CoAP endpoint can acknowledge all or a subset of the blocks.
Concretely, the receiving CoAP endpoint either informs the CoAP Concretely, the receiving CoAP endpoint either informs the CoAP
skipping to change at page 6, line 12 skipping to change at page 6, line 12
o They can operate in environments where packet loss is highly o They can operate in environments where packet loss is highly
asymmetrical. asymmetrical.
o They enable faster transmissions of sets of blocks of data with o They enable faster transmissions of sets of blocks of data with
fewer packet interchanges. fewer packet interchanges.
o They support faster recovery should any of the blocks get lost in o They support faster recovery should any of the blocks get lost in
transmission. transmission.
o They support sending an entire body using NON messages without o They support sending an entire body using NON messages without
requiring an intermediate response from the peer. requiring that an intermediate response be received from the peer.
There are the following disadvantages over using CoAP Block1 and There are the following disadvantages over using CoAP Block1 and
Block2 Options: Block2 Options:
o Loss of lock-stepping so payloads are not always received in the o Loss of lock-stepping so payloads are not always received in the
correct (block ascending) order. correct (block ascending) order.
o Additional congestion control measures need to be put in place for o Additional congestion control measures need to be put in place for
NON messages (Section 7.2). NON messages (Section 7.2).
skipping to change at page 7, line 21 skipping to change at page 7, line 21
This document adds a media type for the 4.08 (Request Entity This document adds a media type for the 4.08 (Request Entity
Incomplete) response defining an additional message format for Incomplete) response defining an additional message format for
reporting on payloads using the Q-Block1 Option that are not received reporting on payloads using the Q-Block1 Option that are not received
by the server. by the server.
See Section 5 for more details. See Section 5 for more details.
3.2. Applicability Scope 3.2. Applicability Scope
The block-wise transfer specified in [RFC7959] covers the general The block-wise transfer specified in [RFC7959] covers the general
case, but falls short in situations where packet loss is highly case using Confirmable messages, but falls short in situations where
asymmetrical. The mechanism specified in this document provides packet loss is highly asymmetrical or there is no need for an
roughly similar features to the Block1/Block2 Options. It provides acknowledgement. In other words, there is a need for Non-confirmable
additional properties that are tailored towards the intended use case support.
of Non-Confirmable transmission. Concretely, this mechanism
primarily targets applications such as DDoS Open Threat Signaling The mechanism specified in this document provides roughly similar
(DOTS) that cannot use CON responses to handle potential packet loss features to the Block1/Block2 Options. It provides additional
properties that are tailored towards the intended use case of Non-
confirmable transmission. Concretely, this mechanism primarily
targets applications such as DDoS Open Threat Signaling (DOTS) that
cannot use CON requests/responses because of potential packet loss
and that support application-specific mechanisms to assess whether and that support application-specific mechanisms to assess whether
the remote peer is not overloaded and thus is able to process the the remote peer is not overloaded and thus is able to process the
messages sent by a CoAP endpoint (e.g., DOTS heartbeats in messages sent by a CoAP endpoint (e.g., DOTS heartbeats in
Section 4.7 of [RFC8782]). Section 4.7 of [RFC8782]). Other use cases are when an application
sends data but has no need for an acknowledgement of receipt and, any
data transmission loss is not critical.
The mechanism includes guards to prevent a CoAP agent from The mechanism includes guards to prevent a CoAP agent from
overloading the network by adopting an aggressive sending rate. overloading the network by adopting an aggressive sending rate.
These guards MUST be followed in addition to the existing CoAP These guards MUST be followed in addition to the existing CoAP
congestion control as specified in Section 4.7 of [RFC7252]. See congestion control as specified in Section 4.7 of [RFC7252]. See
Section 7 for more details. Section 7 for more details.
This mechanism is not intended for general CoAP usage, and any use Any usage outside the primary use case of Non-confirmable with block
outside the intended use case should be carefully weighed against the transfers should be carefully weighed against the potential loss of
loss of interoperability with generic CoAP applications. It is hoped interoperability with generic CoAP applications (See the
that the experience gained with this mechanism can feed future disadvantages listed in Section 3). It is hoped that the experience
extensions of the block-wise mechanism that will both be generally gained with this mechanism can feed future extensions of the block-
applicable and serve this particular use case. wise mechanism that will both be generally applicable and serve this
particular use case.
It is not recommended that these options are used in a NoSec security It is not recommended that these options are used in a NoSec security
mode (Section 9 of [RFC7252]) as the source endpoint needs to be mode (Section 9 of [RFC7252]) as the source endpoint needs to be
trusted. Using OSCORE [RFC8613] does provide a security context and, trusted. Using OSCORE [RFC8613] does provide a security context and,
hence, a trust of the source endpoint that prepared the inner OSCORE hence, a trust of the source endpoint that prepared the inner OSCORE
content. However, even with OSCORE, using a NoSec security mode with content. However, even with OSCORE, using a NoSec security mode with
these options may still be inadequate, for reasons discussed in these options may still be inadequate, for reasons discussed in
Section 11. Section 11.
4. The Q-Block1 and Q-Block2 Options 4. The Q-Block1 and Q-Block2 Options
skipping to change at page 8, line 39 skipping to change at page 8, line 47
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.
When the Content-Format Option is present together with the Q-Block1 When the Content-Format Option is present together with the Q-Block1
or Q-Block2 Option, the option applies to the body not to the payload or Q-Block2 Option, the 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).
The Q-Block1 Option is useful with the payload-bearing, e.g., POST, The Q-Block1 Option is useful with the payload-bearing, e.g., POST,
PUT, FETCH, PATCH, and iPATCH requests and their responses. PUT, FETCH, PATCH, and iPATCH requests and their responses.
The Q-Block2 Option is useful, e.g., with GET, POST, PUT, FETCH, The Q-Block2 Option is useful, e.g., with GET, POST, PUT, FETCH,
PATCH, and iPATCH requests and their payload-bearing responses (2.01, PATCH, and iPATCH requests and their payload-bearing responses
2.02, 2.04, and 2.05) (Section 5.5 of [RFC7252]). (response codes 2.01, 2.02, 2.04, and 2.05) (Section 5.5 of
[RFC7252]).
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 the Q-Block1 Option is present in a request or the Q-Block2 Option If the Q-Block1 Option is present in a request or the Q-Block2 Option
is returned in a response, this indicates a block-wise transfer and is returned in a response, this indicates a block-wise transfer and
describes how this specific block-wise payload forms part of the describes how this specific block-wise payload forms part of the
entire body being transferred. If it is present in the opposite entire body being transferred. If it is present in the opposite
direction, it provides additional control on how that payload will be direction, it provides additional control on how that payload will be
formed or was processed. formed or was processed.
skipping to change at page 9, line 34 skipping to change at page 9, line 41
With CoAP over UDP, the way a request message is rejected for With CoAP over UDP, the way a request message is rejected for
critical options depends on the message type. A Confirmable message critical options depends on the message type. A Confirmable message
with an unrecognized critical option is rejected with a 4.02 (Bad with an unrecognized critical option is rejected with a 4.02 (Bad
Option) response (Section 5.4.1 of [RFC7252]). A Non-confirmable Option) response (Section 5.4.1 of [RFC7252]). A Non-confirmable
message with an unrecognized critical option is either rejected with message with an unrecognized critical option is either rejected with
a Reset message or just silently ignored (Sections 5.4.1 and 4.3 of 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 [RFC7252]). To reliably get a rejection message, it is therefore
REQUIRED that clients use a Confirmable message for determining REQUIRED that clients use a Confirmable message for determining
support for Q-Block1 and Q-Block2 Options. This CON message can be support for Q-Block1 and Q-Block2 Options. This CON message can be
sent under base CoAP congestion control setup specified in sent under the base CoAP congestion control setup specified in
Section 4.7 of [RFC7252] (that is, NSTART does not need to be Section 4.7 of [RFC7252] (that is, NSTART does not need to be
increased (Section 7.1)). increased (Section 7.1)).
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 (See
Section 5.7.1 of [RFC7252]).
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 of both class E and class U for OSCORE processing Options, are of both class E and class U for OSCORE processing
(Table 2). The Q-Block1 (or Q-Block2) Option MAY be an Inner or (Table 2). The Q-Block1 (or Q-Block2) Option MAY be an Inner or
Outer option (Section 4.1 of [RFC8613]). The Inner and Outer values Outer option (Section 4.1 of [RFC8613]). The Inner and Outer values
skipping to change at page 12, line 34 skipping to change at page 12, line 45
2.05 (Content) 2.05 (Content)
This Response Code indicates successful receipt of the entire This Response Code indicates successful receipt of the entire
FETCH request body (Section 2 of [RFC8132]) and that the FETCH request body (Section 2 of [RFC8132]) and that the
appropriate representation of the resource is being returned. The appropriate representation of the resource is being returned. The
token to use MUST be one of the tokens that were received in a token to use MUST be one of the tokens that were received in a
request for this block-wise exchange. However, it is desirable to request for this block-wise exchange. However, it is desirable to
provide the one used in the last received request. provide the one used in the last received request.
If the FETCH request includes the Observe Option, then the server If the FETCH request includes the Observe Option, then the server
MUST use the same token as used for the initial response for MUST use the same token as used for the 2.05 (Content) response
returning any Observe triggered responses so that the client can for returning any Observe triggered responses so that the client
match them up. can match them up.
The client should then release all of the tokens used for this The client should then release all of the tokens used for this
body unless a resource is being observed. body apart from the one used for tracking an observed resource.
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) have been successfully received. The token to use MUST M bit set) have been successfully received. The token to use MUST
be one of the tokens that were received in a request for this be one of the tokens that were received in a request for this
block-wise exchange. However, it is desirable to provide the one latest MAX_PAYLOADS_SET block-wise exchange. However, it is
used in the last received request. desirable to provide the one used in the last received request.
A response using this Response Code SHOULD NOT be generated for The client should then release all of the tokens used for this
every received Q-Block1 Option request (Section 7.2). It SHOULD MAX_PAYLOADS_SET.
only be generated when all the payload requests are Non-
confirmable and a MAX_PAYLOADS_SET has been received by the
server. More details about the motivations for this optimization
are discussed in Section 7.2.
This Response Code SHOULD NOT be generated for CON. A response using this Response Code MUST NOT be generated for
every received Q-Block1 Option request. It SHOULD only be
generated when all the payload requests are Non-confirmable and a
MAX_PAYLOADS_SET has been received by the server. More details
about the motivations for this optimization are discussed in
Section 7.2.
This Response Code SHOULD NOT be generated for CON as this may
cause duplicated payloads to unnecessarily be sent.
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 a Request-Tag Option or a Size1 Option but does include a include a Request-Tag Option or a Size1 Option but does include a
Q-Block1 option. Q-Block1 option.
4.02 (Bad Option) 4.02 (Bad Option)
This Response Code MUST be returned for a Confirmable request if This Response Code MUST be returned for a Confirmable request if
the server does not support the Q-Block Options. Note that a the server does not support the Q-Block Options. Note that a
reset message must be sent in case of Non-confirmable request. reset message may be sent in case of Non-confirmable request.
4.08 (Request Entity Incomplete) 4.08 (Request Entity Incomplete)
As a reminder, this Response Code returned without Content-Type As a reminder, this Response Code returned without Content-Type
"application/missing-blocks+cbor-seq" (Section 12.3) is handled as "application/missing-blocks+cbor-seq" (Section 12.3) is handled as
in Section 2.9.2 [RFC7959]. in Section 2.9.2 [RFC7959].
This Response Code returned with Content-Type "application/ This Response Code returned with Content-Type "application/
missing-blocks+cbor-seq" indicates that some of the payloads are missing-blocks+cbor-seq" indicates that some of the payloads are
missing and need to be resent. The client then retransmits the missing and need to be resent. The client then retransmits the
skipping to change at page 16, line 5 skipping to change at page 16, line 23
in operation. Further considerations related to the transmission in operation. Further considerations related to the transmission
timing for missing requests are discussed in Section 7.2. timing for missing requests are discussed in Section 7.2.
The missing block numbers requested by the client MUST have an The missing block numbers requested by the client MUST have an
increasing block number in each additional Q-Block2 Option with no increasing block number in each additional Q-Block2 Option with no
duplicates. The server SHOULD respond with a 4.00 (Bad Request) to duplicates. The server SHOULD respond with a 4.00 (Bad Request) to
requests not adhering to this behavior. Note that the ordering requests not adhering to this behavior. Note that the ordering
constraint is meant to force the client to check for duplicates and constraint is meant to force the client to check for duplicates and
remove them. This also helps with troubleshooting. remove them. This also helps with troubleshooting.
For Confirmable responses, the client continues to acknowledge each
packet. Typically, the server acknowledges the initial request using
an ACK with the payload, and then sends the subsequent payloads as
CON responses. The server will detect failure to send a packet, but
the client can issue, after a MAX_TRANSMIT_SPAN delay, a separate
GET, POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as
needed.
If the client receives a duplicate block with the same ETag, it MUST If the client receives a duplicate block with the same ETag, it MUST
silently ignore the payload. silently ignore the payload.
A client SHOULD maintain a partial body (missing payloads) for A client SHOULD maintain a partial body (missing payloads) for
NON_PARTIAL_TIMEOUT (Section 7.2) or as defined by the Max-Age Option NON_PARTIAL_TIMEOUT (Section 7.2) or as defined by the Max-Age Option
(or its default of 60 seconds (Section 5.6.1 of [RFC7252])), (or its default of 60 seconds (Section 5.6.1 of [RFC7252])),
whichever is the less. On release of the partial body, the client whichever is the less. On release of the partial body, the client
should then release all of the tokens used for this body apart from should then release all of the tokens used for this body apart from
the token that is used to track a resource that is being observed. the token that is used to track a resource that is being observed.
skipping to change at page 17, line 5 skipping to change at page 17, line 16
notification) with a new ETag to the same client as an additional notification) 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.
For Confirmable traffic, the server typically acknowledges the
initial request using an ACK with a piggybacked payload, and then
sends the subsequent payloads of the MAX_PAYLOADS_SET as CON
responses. These CON responses are individually ACKed by the client.
The server will detect failure to send a packet and SHOULD terminate
the body transfer, but the client can issue, after a
MAX_TRANSMIT_SPAN delay, a separate GET, POST, PUT, FETCH, PATCH, or
iPATCH for any missing blocks as needed.
4.5. Using Observe Option 4.5. Using Observe Option
For a request that uses Q-Block1, the Observe value [RFC7641] MUST be For a request that uses Q-Block1, the Observe value [RFC7641] MUST be
the same for all the payloads of the same body. This includes any the same for all the payloads of the same body. This includes any
missing payloads that are retransmitted. missing payloads that are retransmitted.
For a response that uses Q-Block2, the Observe value MUST be the same For a response that uses Q-Block2, the Observe value MUST be the same
for all the payloads of the same body. This is different from Block2 for all the payloads of the same body. This is different from Block2
usage where the Observe value is only present in the first block usage where the Observe value is only present in the first block
(Section 3.4 of [RFC7959]). This includes payloads transmitted (Section 3.4 of [RFC7959]). This includes payloads transmitted
skipping to change at page 18, line 11 skipping to change at page 18, line 31
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. Such messages must not be treated by the client as needs to proceed. Such messages must not be treated by the client as
a fatal error. a fatal error.
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 new data payload of the 4.08 (Request Entity Incomplete) response
with Content-Type set to "application/missing-blocks+cbor-seq" is
encoded as a CBOR Sequence [RFC8742]. It comprises one or more encoded as a CBOR Sequence [RFC8742]. It comprises one or more
missing block numbers encoded as CBOR unsigned integers [RFC8949]. missing block numbers encoded as CBOR unsigned integers [RFC8949].
The missing block numbers MUST be unique in each 4.08 (Request Entity The missing block numbers MUST be unique in each 4.08 (Request Entity
Incomplete) response when created by the server; the client MUST Incomplete) response when created by the server; the client MUST
ignore any duplicates in the same 4.08 (Request Entity Incomplete) ignore any duplicates in the same 4.08 (Request Entity Incomplete)
response. 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" (Section 12.3). "application/missing-blocks+cbor-seq" (Section 12.3).
The Concise Data Definition Language [RFC8610] (and see Section 4.1 The Concise Data Definition Language [RFC8610] (and see Section 4.1
[RFC8742]) for the data describing these missing blocks is as [RFC8742]) for the data describing these missing blocks is as
follows: follows:
; A notional 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
This CDDL syntax MUST be followed.
It is desirable that the token to use for the response is the token It is desirable that the token to use for the response is the token
that was used in the last block number received so far with the same that was used in the last block number received so far with the same
Request-Tag value. Note that the use of any received token with the Request-Tag value. Note that the use of any received token with the
same Request-Tag would be acceptable, but providing the one used in same Request-Tag would be acceptable, but providing the one used in
the last received payload will aid any troubleshooting. The client the last received payload will aid any troubleshooting. The client
will use the token to determine what was the previously sent request will use the token to determine what was the previously sent request
to obtain the Request-Tag value that was used. to obtain the Request-Tag value that was 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
skipping to change at page 19, line 31 skipping to change at page 20, line 8
Each new request generally uses a new Token (and sometimes must, see Each new request generally uses a new Token (and sometimes must, see
Section 4 of [I-D.ietf-core-echo-request-tag]). Additional responses Section 4 of [I-D.ietf-core-echo-request-tag]). Additional responses
to a request all use the token of the request they respond to. to a request all use the token of the request they respond to.
Implementation Note: By using 8-byte tokens, it is possible to Implementation Note: By using 8-byte tokens, it is possible to
easily minimize the number of tokens that have to be tracked by easily minimize the number of tokens that have to be tracked by
clients, by keeping the bottom 32 bits the same for the same body clients, by keeping the bottom 32 bits the same for the same body
and the upper 32 bits containing the current body's request number and the upper 32 bits containing the current body's request number
(incrementing every request, including every re-transmit). This (incrementing every request, including every re-transmit). This
allows the client to be alleviated from keeping all the per- allows the client to be alleviated from keeping all the per-
request-state, e.g., in Section 3 of [RFC8974]. request-state, e.g., in Section 3 of [RFC8974]. However, if using
NoSec, Section 5.2 of [RFC8974] needs to be considered for
security implications.
7. Congestion Control for Unreliable Transports 7. Congestion Control for Unreliable Transports
The transmission of all the blocks of a single body over an The transmission of all the blocks of a single body over an
unreliable transport MUST either all be Confirmable or all be Non- unreliable transport MUST either all be Confirmable or all be Non-
confirmable. This is meant to simplify the congestion control confirmable. This is meant to simplify the congestion control
procedure. procedure.
As a reminder, there is no need for CoAP-specific congestion control As a reminder, there is no need for CoAP-specific congestion control
for reliable transports [RFC8323]. for reliable transports [RFC8323].
skipping to change at page 20, line 19 skipping to change at page 20, line 46
implementation specific as to whether there should be any further implementation specific as to whether there should be any further
requests for missing data. requests for missing data.
7.2. Non-confirmable (NON) 7.2. Non-confirmable (NON)
This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT, This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT,
NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and
NON_PARTIAL_TIMEOUT primarily for use with NON (Table 3). NON_PARTIAL_TIMEOUT primarily for use with NON (Table 3).
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 MUST 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], especially given the those discussed in Section 5 of [RFC6928], especially given the
target application discussed in Section 3.2. target application discussed in Section 3.2.
NON_TIMEOUT is the period of delay between sending MAX_PAYLOADS_SET NON_TIMEOUT is the period of delay between sending MAX_PAYLOADS_SET
skipping to change at page 21, line 8 skipping to change at page 21, line 35
NON_MAX_RETRANSMIT is the maximum number of times a request for the NON_MAX_RETRANSMIT is the maximum number of times a request for the
retransmission of missing payloads can occur without a response from retransmission of missing payloads can occur without a response from
the remote peer. After this occurs, the local endpoint SHOULD the remote peer. After this occurs, the local endpoint SHOULD
consider the body stale, remove any body, and release Tokens and consider the body stale, remove any body, and release Tokens and
Request-Tag on the client (or the ETag on the server). By default, Request-Tag on the client (or the ETag on the server). By default,
NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT (Section 4.8 NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT (Section 4.8
of [RFC7252]). of [RFC7252]).
NON_PROBING_WAIT is used to limit the potential wait needed when NON_PROBING_WAIT is used to limit the potential wait needed when
using PROBING_RATE. By default, NON_PROBING_WAIT has the same value using PROBING_RATE. By default, NON_PROBING_WAIT is computed in the
as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). same way as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) but with
ACK_TIMEOUT and MAX_RETRANSMIT substituted with NON_TIMEOUT and
NON_MAX_RETRANSMIT, respectively:
NON_PROBING_WAIT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - 1) *
ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT
NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. NON_PARTIAL_TIMEOUT is used for expiring partially received bodies.
By default, NON_PARTIAL_TIMEOUT has the same value as By default, NON_PARTIAL_TIMEOUT is computed in the same way as
EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). This default value
is calculated in the same way as NON_PROBING_WAIT.
+---------------------+---------------+ +---------------------+---------------+
| Parameter Name | Default Value | | Parameter Name | Default Value |
+=====================+===============| +=====================+===============+
| MAX_PAYLOADS | 10 | | MAX_PAYLOADS | 10 |
| NON_MAX_RETRANSMIT | 4 | | NON_MAX_RETRANSMIT | 4 |
| NON_TIMEOUT | 2 s | | NON_TIMEOUT | 2 s |
| NON_RECEIVE_TIMEOUT | 4 s | | NON_RECEIVE_TIMEOUT | 4 s |
| NON_PROBING_WAIT | 247 s | | NON_PROBING_WAIT | 247 s |
| NON_PARTIAL_TIMEOUT | 247 s | | NON_PARTIAL_TIMEOUT | 247 s |
+---------------------+---------------+ +---------------------+---------------+
Table 3: Congestion Control Parameters Table 3: Congestion Control Parameters
skipping to change at page 21, line 42 skipping to change at page 22, line 32
If the wait time between sending bodies that are not being responded If the wait time between sending bodies that are not being responded
to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time
is limited to NON_PROBING_WAIT. 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]. Note that MAX_PAYLOADS, discussed in Section 4.5.2 of [RFC8782]. Note that MAX_PAYLOADS,
NON_MAX_RETRANSMIT, NON_TIMEOUT, NON_PROBING_WAIT, and NON_MAX_RETRANSMIT, NON_TIMEOUT, NON_PROBING_WAIT, and
NON_PARTIAL_TIMEOUT can be negotiated between DOTS peers, e.g., as NON_PARTIAL_TIMEOUT can be negotiated between DOTS peers, e.g., as
per [I-D.bosh-dots-quick-blocks]. per [I-D.bosh-dots-quick-blocks]. When explicit values are
configured for NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT, these
values are used without applying any jitter.
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 a Q-Block2 Option is subject to Each NON GET or FETCH request using a 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 congestion, after transmission of every MAX_PAYLOADS_SET of a single
MAX_PAYLOADS_SET of a single body, a delay is introduced of body, a delay MUST be introduced of NON_TIMEOUT before sending the
NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to manage next MAX_PAYLOADS_SET unless a 'Continue' is received from the peer
potential congestion issues. for the current MAX_PAYLOADS_SET, in which case the next
MAX_PAYLOADS_SET MAY start transmission immediately.
If the CoAP peer reports that at least one payload has not arrived Note: Assuming 1500-byte packets and the MAX_PAYLOADS_SET having
for each body for at least a 24-hour period and it is known that 10 payloads, this corresponds to 1500 * 10 * 8 = 120 Kbits. With
there are no other network issues over that period (e.g., DDoS a maximum delay of 2 seconds between MAX_PAYLOADS_SET, this
attacks), then the value of MAX_PAYLOADS can be reduced by 1 at a indicates an average speed requirement of 60 Kbps for a single
time (to a minimum of 1) and the situation re-evaluated for another body should there be no responses. This transmission rate is
24-hour period until there is no report of missing payloads under further reduced by being subject to PROBING_RATE.
normal operating conditions. Following a period of 24 hours where no
packet recovery was required, the value of MAX_PAYLOADS can be
increased by 1 (but without exceeding the default value) for a
further 24-hour evaluation. The newly derived value for MAX_PAYLOADS
should be used for both ends of this particular CoAP peer link. Note
that the CoAP peer will not know about the MAX_PAYLOADS change until
it is reconfigured. As a consequence of the two peers having
different MAX_PAYLOADS values, a peer may continue indicating that
there are some missing payloads as all of its MAX_PAYLOADS_SET may
not have arrived. How the two peer values for MAX_PAYLOADS are
synchronized is out of the scope.
The sending of a set of missing blocks of a body is restricted to The sending of a set of missing blocks of a body is restricted to
those in a MAX_PAYLOADS_SET at a time. In other words, a NON_TIMEOUT those in a MAX_PAYLOADS_SET at a time. In other words, a NON_TIMEOUT
delay is still observed between each MAX_PAYLOAD_SET. delay is still observed between each MAX_PAYLOAD_SET.
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 MAX_PAYLOADS_SET without any further delay. continue to send the next MAX_PAYLOADS_SET without any further delay.
If the server responds with a 4.08 (Request Entity Incomplete) If the server responds with a 4.08 (Request Entity Incomplete)
Response Code, then the missing payloads SHOULD be retransmitted Response Code, then the missing payloads SHOULD be retransmitted
skipping to change at page 22, line 49 skipping to change at page 23, line 30
2.31 (Continue) Response Code on receipt of all of the 2.31 (Continue) Response Code on receipt of all of the
MAX_PAYLOADS_SET to prevent the client unnecessarily delaying. If MAX_PAYLOADS_SET to prevent the client unnecessarily delaying. If
not all of the MAX_PAYLOADS_SET were received, the server SHOULD not all of the MAX_PAYLOADS_SET were received, the server SHOULD
delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the
repeat request count for a payload) before sending the 4.08 (Request repeat request count for a payload) before sending the 4.08 (Request
Entity Incomplete) Response Code for the missing payload(s). If all Entity Incomplete) Response Code for the missing payload(s). If all
of the MAX_PAYLOADS_SET were received and a 2.31 (Continue) had been of the MAX_PAYLOADS_SET were received and a 2.31 (Continue) had been
sent, but no more payloads were received for NON_RECEIVE_TIMEOUT sent, but no more payloads were received for NON_RECEIVE_TIMEOUT
(exponentially scaled), the server SHOULD send a 4.08 (Request Entity (exponentially scaled), the server SHOULD send a 4.08 (Request Entity
Incomplete) response detailing the missing payloads after the block Incomplete) response detailing the missing payloads after the block
number that was indicated in the sent 2.31 (Continue). If the repeat number that was indicated in the sent 2.31 (Continue). If the
request count for the 4.08 (Request Entity Incomplete) exceeds repeated response count of the 4.08 (Request Entity Incomplete)
NON_MAX_RETRANSMIT, the server SHOULD discard the partial body and exceeds NON_MAX_RETRANSMIT, the server SHOULD discard the partial
stop requesting the missing payloads. body and stop requesting the missing payloads.
It is likely that the client will start transmitting the next It is likely that the client will start transmitting the next
MAX_PAYLOADS_SET before the server times out on waiting for the last MAX_PAYLOADS_SET before the server times out on waiting for the last
of the previous MAX_PAYLOADS_SET. On receipt of a payload from the of the previous MAX_PAYLOADS_SET. On receipt of a payload from the
next MAX_PAYLOADS_SET, the server SHOULD send a 4.08 (Request Entity next MAX_PAYLOADS_SET, the server SHOULD send a 4.08 (Request Entity
Incomplete) Response Code indicating any missing payloads from any Incomplete) Response Code indicating any missing payloads from any
previous MAX_PAYLOADS_SET. Upon receipt of the 4.08 (Request Entity previous MAX_PAYLOADS_SET. Upon receipt of the 4.08 (Request Entity
Incomplete) Response Code, the client SHOULD send the missing Incomplete) Response Code, the client SHOULD send the missing
payloads before continuing to send the remainder of the payloads before continuing to send the remainder of the
MAX_PAYLOADS_SET and then go into another NON_TIMEOUT delay prior to MAX_PAYLOADS_SET and then go into another NON_TIMEOUT delay prior to
skipping to change at page 38, line 13 skipping to change at page 38, line 13
endpoint is legitimate even if NoSec security mode is used. However, endpoint is legitimate even if NoSec security mode is used. However,
an intermediary node can modify the unprotected outer Q-Block1 and/or an intermediary node can modify the unprotected outer Q-Block1 and/or
Q-Block2 Options to cause a Q-Block transfer to fail or keep Q-Block2 Options to cause a Q-Block transfer to fail or keep
requesting all the blocks by setting the M bit and, thus, causing requesting all the blocks by setting the M bit and, thus, causing
attack amplification. As discussed in Section 12.1 of [RFC8613], attack amplification. As discussed in Section 12.1 of [RFC8613],
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. Therefore, it is NOT RECOMMENDED to use the NoSec manipulated. Therefore, it is NOT RECOMMENDED to use the NoSec
security mode if either the Q-Block1 or Q-Block2 Options is used. security mode if either the Q-Block1 or Q-Block2 Options is used.
If OSCORE is not used, it is also NOT RECOMMENDED to use the NoSec
security mode if either the Q-Block1 or Q-Block2 Options is used.
If NoSec is being used, Section D.5 of [RFC8613] discusses the
security analysis and considerations for unprotected message fields
even if OSCORE is not being 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. IANA Considerations 12. IANA Considerations
RFC Editor Note: Please replace [RFCXXXX] with the RFC number to be RFC Editor Note: Please replace [RFCXXXX] with the RFC number to be
assigned to this document. assigned to this document.
12.1. CoAP Option Numbers Registry 12.1. CoAP Option Numbers Registry
skipping to change at page 41, line 20 skipping to change at page 41, line 20
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets", Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018, RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>. <https://www.rfc-editor.org/info/rfc8323>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<https://www.rfc-editor.org/info/rfc8742>. <https://www.rfc-editor.org/info/rfc8742>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
skipping to change at page 42, line 22 skipping to change at page 42, line 28
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928, "Increasing TCP's Initial Window", RFC 6928,
DOI 10.17487/RFC6928, April 2013, DOI 10.17487/RFC6928, April 2013,
<https://www.rfc-editor.org/info/rfc6928>. <https://www.rfc-editor.org/info/rfc6928>.
[RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.
Bose, "Constrained Application Protocol (CoAP) Option for Bose, "Constrained Application Protocol (CoAP) Option for
No Server Response", RFC 7967, DOI 10.17487/RFC7967, No Server Response", RFC 7967, DOI 10.17487/RFC7967,
August 2016, <https://www.rfc-editor.org/info/rfc7967>. August 2016, <https://www.rfc-editor.org/info/rfc7967>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P.,
Mortensen, A., and N. Teague, "Distributed Denial-of- Mortensen, A., and N. Teague, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Signal Channel Service Open Threat Signaling (DOTS) Signal Channel
Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020,
<https://www.rfc-editor.org/info/rfc8782>. <https://www.rfc-editor.org/info/rfc8782>.
[RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and [RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and
Stateless Clients in the Constrained Application Protocol Stateless Clients in the Constrained Application Protocol
(CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021, (CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021,
<https://www.rfc-editor.org/info/rfc8974>. <https://www.rfc-editor.org/info/rfc8974>.
skipping to change at page 47, line 37 skipping to change at page 47, line 37
Thanks to Achim Kraus, Jim Schaad, and Michael Richardson for their Thanks to Achim Kraus, Jim Schaad, and Michael Richardson for their
comments. comments.
Special thanks to Christian Amsuess, Carsten Bormann, and Marco Special thanks to Christian Amsuess, Carsten Bormann, and Marco
Tiloca for their suggestions and several reviews, which improved this Tiloca for their suggestions and several reviews, which improved this
specification significantly. Thanks to Francesca Palombini for the specification significantly. Thanks to Francesca Palombini for the
AD review. AD review.
Thanks to Pete Resnick for the Gen-ART review, Colin Perkins for the Thanks to Pete Resnick for the Gen-ART review, Colin Perkins for the
Tsvart review, and Emmanuel Baccelli for the Iotdir review. Thanks Tsvart review, and Emmanuel Baccelli for the Iotdir review. Thanks
to Martin Duke, Eric Vyncke, Benjamin Kaduk, Roman Danyliw, and John to Martin Duke, Eric Vyncke, Benjamin Kaduk, Roman Danyliw, John
Scudder for the IESG review. Scudder, and Lars Eggert for the IESG review.
Some text from [RFC7959] is reused for readers convenience. Some text from [RFC7959] is reused for readers convenience.
Authors' Addresses Authors' Addresses
Mohamed Boucadair Mohamed Boucadair
Orange Orange
Rennes 35000 Rennes 35000
France France
 End of changes. 45 change blocks. 
120 lines changed or deleted 143 lines changed or added

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