Draft: draft-ietf-core-new-block

Commentary: Some of these are more than nit - level and reorder or rephrase things in an attempt to improve clarity . I 'm not tied to any of them and we can adjust as needed for your preference .
These options are similar to the CoAP Block1 and Block2 Options
defined in RFC 7959, not a replacement for them, but do enable faster
transmission rates for large amounts of data with less packet
interchanges.  Also, Q-Block1 and Q-Block2 Options support faster
recovery should any of the blocks get lost in transmission.
These options are similar to, but distinct from, the CoAP Block1 and
Block2 Options defined in RFC 7959.  Q-Block1 and Q-Block2 Options
are not intended to replace Block1 and Block2, but rather have the
goal of enabling faster transmission rates for large amounts of data
with fewer packet interchanges.  Also, the Q-Block1 and Q-Block2
Options support faster recovery should any of the blocks get lost in
transmission.
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 and was further updated by RFC8323 for use over TCP,
TLS, and WebSockets.
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 as to not rely on IP
fragmentation, and was further updated by RFC8323 for use over TCP,
TLS, and WebSockets.
There is a requirement for these blocks of data to be transmitted at
higher rates under network conditions where there may be asymmetrical
transient packet loss (i.e., responses may get dropped).  An example
is when a network is subject to a Distributed Denial of Service
(DDoS) attack and there is a need for DDoS mitigation agents relying
upon CoAP to communicate with each other (e.g., I-D.ietf-dots-
telemetry).  As a reminder, RFC7959 recommends the use of Confirmable
(CON) responses to handle potential packet loss.  However, such a
recommendation does not work with a flooded pipe DDoS situation
(e.g., RFC8782).
There is a requirement for blocks of data larger than a single IP
datagram to be transmitted at higher rates under network conditions
where there may be asymmetrical transient packet loss (e.g.,
responses may get dropped).  An example is when a network is subject
to a Distributed Denial of Service (DDoS) attack and there is a need
for DDoS mitigation agents relying upon CoAP to communicate with each
other (e.g., I-D.ietf-dots-telemetry).  As a reminder, RFC7959
recommends the use of Confirmable (CON) responses to handle potential
packet loss.  However, such a recommendation does not work with a
flooded pipe DDoS situation (e.g., RFC8782).
Using NON messages, the faster transmissions occur as all the blocks
can be transmitted serially (as are IP fragmented packets) without
having to wait for a response or next request from the remote CoAP
peer.  Recovery of missing blocks is faster in that multiple missing
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
the peer whether the body comprises of a single or multiple payloads
assuming no recovery is required.
Using NON messages, the faster transmissions occur as all the blocks
can be transmitted serially (akin to fragmented IP packets) without
having to wait for a response or next request from the remote CoAP
peer.  Recovery of missing blocks is faster in that multiple missing
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
the peer whether the body comprises of a single or multiple payloads,
assuming no recovery is required.
Note that similar performance benefits can be applied to Confirmable
messages if the value of NSTART is increased from 1 (Section 4.7 of
RFC7252).  However, the use of Confirmable messages will not work if
there is asymmetrical packet loss.  Some examples with Confirmable
messages are provided in CON.
Note that similar performance benefits can be applied to Confirmable
messages if the value of NSTART is increased from 1 (Section 4.7 of
RFC7252).  However, the use of Confirmable messages will not work
effectively if there is asymmetrical packet loss.  Some examples with
Confirmable messages are provided in CON.
They enable faster transmissions of sets of blocks of data with
less packet interchanges.
They enable faster transmissions of sets of blocks of data with
fewer packet interchanges.
To reduce the transmission times for CON transmission of large
bodies, NSTART needs to be increased from 1, but this affects
congestion control where other parameters need to be tuned
(Section 4.7 of RFC7252).  Such tuning is out of scope of this
document.
To reduce the transmission times for CON transmission of large
bodies, NSTART needs to be increased from 1, but this affects
congestion control and incurs a requirement to re-tune other
parameters (Section 4.7 of RFC7252).  Such tuning is out of scope
of this document.
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
trusted.  Using OSCORE RFC8613 does provide a security context and,
hence, a trust of the source endpoint.  However, using a NoSec
security mode may still be inadequate for reasons discussed in
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
trusted.  Using OSCORE RFC8613 does provide a security context and,
hence, a trust of the source endpoint that prepared the inner OSCORE
content.  However, even with OSCORE, using a NoSec security mode with
these options may still be inadequate, for reasons discussed in
security.
Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH,
PATCH, and iPATCH requests and their responses.
Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and
iPATCH requests and their payload-bearing responses (2.01, 2.02,
If Q-Block1 Option is present in a request or Q-Block2 Option in a
response (i.e., in that message to the payload of which it pertains),
it indicates a block-wise transfer and describes how this specific
block-wise payload forms part of the entire body being transferred.
If it is present in the opposite direction, it provides additional
control on how that payload will be formed or was processed.
The Q-Block1 Option is useful with the payload-bearing POST, PUT,
FETCH, PATCH, and iPATCH requests and their responses.
The Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and
iPATCH requests and their payload-bearing responses (2.01, 2.02,
If the Q-Block1 Option is present in a request or the Q-Block2 Option
in a response (i.e., in that message to the payload of which it
pertains), it indicates a block-wise transfer and describes how this
specific block-wise payload forms part of the entire body being
transferred.  If it is present in the opposite direction, it provides
additional control on how that payload will be formed or was
processed.
The Q-Block1 and Q-Block2 Options, like the Block1 and Block2
Options, both of class E and class U for OSCORE processing (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 are therefore
independent of each other.  The Inner option is encrypted and
integrity protected between clients and servers, and provides message
body identification in case of end-to-end fragmentation of requests.
The Outer option is visible to proxies and labels message bodies in
case of hop-by-hop fragmentation of requests.
The Q-Block1 and Q-Block2 Options, like the Block1 and Block2
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
Outer option (Section 4.1 of RFC8613).  The Inner and Outer values
are therefore independent of each other.  The Inner option is
encrypted and integrity protected between clients and servers, and
provides message body identification in case of end-to-end
fragmentation of requests.  The Outer option is visible to proxies
and labels message bodies in case of hop-by-hop fragmentation of
requests.
For Confirmable transmission, the server continues to acknowledge
each packet, but a response is not required (whether separate or
piggybacked) until successful receipt of the body by the server.  For
Non-confirmable transmission, no response is required until the
successful receipt of the body by the server or some of the payloads
have not arrived after a timeout and a retransmit missing payloads
response is needed.  For reliable transports (e.g., RFC8323), a
response is not required until successful receipt of the body by the
server.
For Confirmable transmission, the server continues to acknowledge
each packet, but a response is not required (whether separate or
piggybacked) until successful receipt of the body by the server.  For
Non-confirmable transmission, no response is required until either
the successful receipt of the body by the server or a timer expires
with some of the payloads having not yet arrived.  In the latter
case, a "retransmit missing payloads" response is needed.  For
reliable transports (e.g., RFC8323), a response is not required until
successful receipt of the body by the server.
The Size1 Option MUST be used with the Q-Block1 Option when used in a
request and MUST be present in all payloads of the request preserving
the same value.  The Size2 Option MUST be used with the Q-Block2
Option when used in a response and MUST be present in all payloads of
the response preserving the same value.
The Size1 Option MUST be used with the Q-Block1 Option when used in a
request and MUST be present in all payloads of the request,
preserving the same value.  The Size2 Option MUST be used with the
Q-Block2 Option when used in a response and MUST be present in all
payloads of the response, preserving the same value.
The token to use for the response SHOULD be the token that was used
in the last block number received so far with the same Request-Tag
value.  Note that the use of any received token with the same
Request-Tag would be acceptable, but providing the one used in the
last received payload will aid any troubleshooting.  The client will
use the token to determine what was the previously sent request to
obtain the Request-Tag value to be used.
The token to use for the response SHOULD be the token that was used
in the last block number received so far with the same Request-Tag
value.  Note that the use of any received token with the same
Request-Tag would be acceptable, but providing the one used in the
last received payload will aid any troubleshooting.  The client will
use the token to determine what was the previously sent request to
obtain the Request-Tag value that was used.
Congestion control for CON requests and responses is specified in
Section 4.7 of RFC7252.  In order to benefit from faster transmission
rates, NSTART will need to be increased from 1.  However, the other
CON congestion control parameters will need to be tuned to cover this
change.  This tuning is not specified in this document given that the
applicability scope of the current specification assumes that all
requests and responses using Q-Block1 and Q-Block2 will be Non-
confirmable (scope) apart from the initial Q-Block functionality
negotiation.
Congestion control for CON requests and responses is specified in
Section 4.7 of RFC7252.  In order to benefit from faster transmission
rates, NSTART will need to be increased from 1.  However, the other
CON congestion control parameters will need to be tuned to cover this
change.  This tuning is not specified in this document, given that
the applicability scope of the current specification assumes that all
requests and responses using Q-Block1 and Q-Block2 will be Non-
confirmable (scope) apart from the initial Q-Block functionality
negotiation.
NON_PROBING_WAIT is used to limit the potential wait needed
calculated when using PROBING_RATE.  By default, NON_PROBING_WAIT has
the same value as EXCHANGE_LIFETIME (Section 4.8.2 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 single body of blocks will be subjected
to PROBING_RATE (Section 4.7 of RFC7252), not the individual packets.
If the wait time between sending bodies that are not being responded
to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the gap time
is limited to NON_PROBING_WAIT.
Note: For the particular DOTS application, PROBING_RATE and other
transmission parameters are negotiated between peers.  Even when
not negotiated, the DOTS application uses customized defaults as
discussed in Section 4.5.2 of RFC8782.  Note that MAX_PAYLOADS,
NON_MAX_RETRANSMIT, NON_TIMEOUT, NON_PROBING_WAIT, and
NON_PARTIAL_TIMEOUT can be negotiated between DOTS peers as per I-
D.bosh-dots-quick-blocks.
Each NON GET or FETCH request using Q-Block2 Option is subject to
PROBING_RATE.
NON_PROBING_WAIT is used to limit the potential wait needed when
using PROBING_RATE.  By default, NON_PROBING_WAIT has the same value
as EXCHANGE_LIFETIME (Section 4.8.2 of RFC7252).
The 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.  A single group of (MAX_PAYLOADS)
blocks will be subjected to PROBING_RATE (Section 4.7 of RFC7252),
not the individual packets.  If the wait time between sending bodies
that are not being responded to based on PROBING_RATE exceeds
NON_PROBING_WAIT, then the gap time is limited to NON_PROBING_WAIT.
Note: For the particular DOTS application, PROBING_RATE and other
transmission parameters are negotiated between peers.  Even when
not negotiated, the DOTS application uses customized defaults as
discussed in Section 4.5.2 of RFC8782.  Note that MAX_PAYLOADS,
NON_MAX_RETRANSMIT, NON_TIMEOUT, NON_PROBING_WAIT, and
NON_PARTIAL_TIMEOUT can be negotiated between DOTS peers, e.g., as
per I-D.bosh-dots-quick-blocks.
Each NON GET or FETCH request using a Q-Block2 Option is subject to
PROBING_RATE.
If the CoAP peer reports at least one payload has not arrived for
each body for at least a 24 hour period and it is known that there
are no other network issues over that period (e.g., DDoS attacks),
then the value of MAX_PAYLOADS can be reduced by 1 at a time (to a
minimum of 1) and the situation re-evaluated for another 24 hour
period until there is no report of missing payloads under 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.
If the CoAP peer reports that at least one payload has not arrived
for each body for at least a 24 hour period and it is known that
there are no other network issues over that period (e.g., DDoS
attacks), then the value of MAX_PAYLOADS can be reduced by 1 at a
time (to a minimum of 1) and the situation re-evaluated for another
24 hour period until there is no report of missing payloads under
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.
For the client receiving NON Q-Block2 responses, it SHOULD send a
'Continue' Q-Block2 request (qblock2) for the next set of payloads on
receipt of all of the MAX_PAYLOADS payloads to prevent the server
unnecessarily delaying.  Otherwise, the client SHOULD delay for
NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request
count for a payload), before sending the request for the missing
payload(s).  If the repeat request count for a missing payload
exceeds NON_MAX_RETRANSMIT, the client SHOULD discard the partial
body and stop requesting the missing payloads.
For the client receiving NON Q-Block2 responses, it SHOULD send a
'Continue' Q-Block2 request (qblock2) for the next set of payloads on
receipt of all of the MAX_PAYLOADS payloads, to prevent the server
unnecessarily delaying.  Otherwise the client SHOULD delay for
NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request
count for a payload), before sending the request for the missing
payload(s).  If the repeat request count for a missing payload
exceeds NON_MAX_RETRANSMIT, the client SHOULD discard the partial
body and stop requesting the missing payloads.
A proxy that supports Q-Block2 Option MUST be prepared to receive a
GET or similar request indicating one or more missing blocks.  The
proxy will serve from its cache the missing blocks that are available
in its cache in the same way a server would send all the appropriate
Q-Block2 responses.  If the cache key matching body is not available
in the cache, the proxy MUST request the entire body from the CoAP
server using the information in the cache key.
A proxy that supports Q-Block2 Option MUST be prepared to receive a
GET or similar request indicating one or more missing blocks.  The
proxy will serve from its cache the missing blocks that are available
in its cache in the same way a server would send all the appropriate
Q-Block2 responses.  If a body matching the cache key is not
available in the cache, the proxy MUST request the entire body from
the CoAP server using the information in the cache key.