Draft: draft-ietf-core-new-block

Commentary: Jon inputs on the second part of Christian 's review . 
 The draft describes this all as " just working through a proxy " -- original block - wise does not , and I 'd like to hear how this is hoping to get away without the options being proxy - unsafe . Is there any point at all in using block - by - block proxying for these use cases ? Unless a proxy is sitting right inside the link under attack , and unless the bodies get huge , it may be way easier for this to be purely hop - by - hop . Proxies would reassemble the full bodies and , for the next hop , just decide what works best there ( be it regular block - wise ,  or BERT ) . ( If there 's a point in allowing block - by - block forwarding , we can talk it through and work through the initial ideas that will come up like " We use large enough Request - Tag values so they are unique " , " how large does that need to be " , " why do we end up having a Request - Tag in every request now " and " why do we not want that " , but my gut feeling is we wo n't need to go there . )
These options are designed to work with Non-confirmable requests and
responses.
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.  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 use of Confirmable (CON) responses to handle potential
packet loss, which does not work with a flooded pipe DDoS situation.
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 use of Confirmable
(CON) responses to handle potential packet loss, which does not work
with a flooded pipe DDoS situation.
Additional congestion control measures need to be put in place.
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 an acknowledgement 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 packet.  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 the same 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.
For Confirmable transmission of large bodies, to reduce the
transmission times, NSTART needs to be increased from 1, but this
affects Congestion Control where other parameters need to be tuned
(Section 4.7 of RFC7252).  This tuning is out of scope of this
document.
Additional congestion control measures need to be put in place for
No-Confirmable transmission (cc-non).
Using Non-Confirmable 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 packet.  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.
The block-wise transfer specified in RFC7959 covers the general case,
but falls short in situations where packet loss is highly
asymmetrical.  The mechanism specified in this document provides
roughly similar features to the Block1/Block2 Options.  It provides
additional properties that are tailored towards the intended use
case.  Concretely, this mechanism primarily targets applications such
as DDoS Open Threat Signaling (DOTS) that can't use Confirmable (CON)
responses to handle potential packet loss and that support
application-specific mechanisms to assess whether the remote peer is
able to handle the messages sent by a CoAP endpoint (e.g., DOTS
heartbeats in Section 4.7 of RFC8782).
The block-wise transfer specified in RFC7959 covers the general case,
but falls short in situations where packet loss is highly
asymmetrical.  The mechanism specified in this document provides
roughly similar 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 can't use Confirmable (CON) responses to handle potential
packet loss and that support application-specific mechanisms to
assess whether the remote peer is able to handle the messages sent by
a CoAP endpoint (e.g., DOTS heartbeats in Section 4.7 of RFC8782).
The properties of Q-Block1 and Q-Block2 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 Critcal and Unsafe columns are marked
for the Q-Block1 Option.  Critical, Unsafe, and Repeatable columns
are marked for the Q-Block2 Option.
The properties of Q-Block1 and Q-Block2 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 Critcal and UnSafe columns are marked
for the Q-Block1 Option.  Critical, UnSafe, and Repeatable columns
are marked for the Q-Block2 Option.  As these options are UnSafe,
NoCacheKey has no meaning and so is marked with a dash.
The Q-Block2 Option is repeatable when requesting re-transmission of
missing Blocks, but not otherwise.  Except that case, any request
carrying multiple Q-Block1 (or Q-Block2) Options MUST be handled
following the procedure specified in Section 5.4.5 of RFC7252.
The Q-Block1 and Q-Block2 Options, like the Block1 and Block2
Options, are both a class E and a class U in terms of OSCORE
processing (Table 2): The Q-Block1 (or Q-Block2) Option MAY be an
Inner or Outer option (see Section 4.1 of RFC8613).  The Inner and
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-Block2 Option is repeatable when requesting retransmission of
missing Blocks, but not otherwise.  Except that case, any request
carrying multiple Q-Block1 (or Q-Block2) Options MUST be handled
following the procedure specified in Section 5.4.5 of RFC7252.
The Q-Block1 and Q-Block2 Options, like the Block1 and Block2
Options, are both a class E and a class U in terms of OSCORE
processing (Table 2).
The Q-Block1 (or Q-Block2) Option MAY be an Inner or Outer option
(see Section 4.1 of RFC8613).  The Inner and 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.
When Q-Block1 Option is used, the client MUST include a single
Request-Tag Option I-D.ietf-core-echo-request-tag.  The Request-Tag
value MUST be the same for all of the blocks in the body of data that
is being transferred.  It is also used to identify a particular block
of a body that needs to be re-transmitted.  The Request-Tag is
opaque, the server still treats it as opaque but the client SHOULD
ensure that it is unique for every different body of transmitted
data.
When Q-Block1 Option is used, the client MUST include a Size1 Option
(See size).  The Size1 value MUST be the same for all of the requests
for the body of data that is being transferred.
When Q-Block1 Option is used, the client MUST include a Request-Tag
Option I-D.ietf-core-echo-request-tag.  The Request-Tag value MUST be
the same for all of the requests for the body of data that is being
transferred.  It is also used to identify a particular payload of a
body that needs to be retransmitted.  The Request-Tag is opaque, the
server still treats it as opaque but the client SHOULD ensure that it
is unique for every different body of transmitted data.
For Confirmable transmission, the server MUST continue to acknowledge
each packet.
A 2.01 (Created) or 2.04 (Changed) Response Code indicates successful
receipt of the entire body.
The 2.31 (Continue) Response is not used in the current version of
the specification.
A 4.00 (Bad Request) Response Code MUST be returned if the request
does not include a Request-Tag Option but does include a Q-Block1
option.
A 4.02 (Bad Option) Response Code MUST be returned if the server does
not support the Q-Block1 Option.
A 4.13 (Request Entity Too Large) Response Code can be returned under
similar conditions to those discussed in Section 2.9.3 of RFC7959.
A 4.08 (Request Entity Incomplete) Response Code returned without
Content-Type "application/missing-blocks+cbor-seq" (new-format) is
handled as in Section 2.9.2 RFC7959.
A 4.08 (Request Entity Incomplete) Response Code returned with
Content-Type "application/missing-blocks+cbor-seq" indicates that
some of the payloads are missing and need to be resent.  The client
then re-transmits the missing payloads using the Request-Tag and
Q-Block1 to specify the block number, SZX, and M bit as appropriate.
The Request-Tag value to use is determined from the payload of the
not recognize the Request-Tag, the client can ignore this response.
If the server has not received all the payloads of a body, but one or
more payloads have been received, it SHOULD wait for up to
MAX_TRANSMIT_SPAN (Section 4.8.2 of RFC7252) before sending the 4.08
(Request Entity Incomplete) Response Code.  However, this time MAY be
reduced to two times ACK_TIMEOUT before sending a 4.08 (Request
Entity Incomplete) Response Code to cover the situation where
MAX_PAYLOADS has been triggered by the client causing a break in
transmission.
If the client transmits a new body of data with a new Request-Tag to
the same resource on a server, the server MUST remove any partially
received body held for a previous Request-Tag for that resource.
If the server receives a duplicate block with the same Request-Tag,
it SHOULD silently ignore the packet.
A server SHOULD only maintain a partial body (missing payloads) for
up to EXCHANGE_LIFETIME (Section 4.8.2 of RFC7252).
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 or, if some of the
payloads are sent as Non-confirmable and have not arrived, a
retransmit missing payloads response is needed.
The client MUST send the payloads with the block numbers increasing,
starting from zero, until the body is complete (subject to any
congestion control (cc)).  Any missing payloads requested by the
server must in addition be separately transmitted with increasing
block numbers.
Response Codes.
This Response Code indicates successful receipt of the entire body
and the resource was created.
This Response Code indicates successful receipt of the entire body
and the resource was updated.
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
M bit set) in the response have been successfully received.
A response using this Response Code SHOULD NOT be generated for
every received Q-Block1 Option request.  It SHOULD only be
generated when all the payload requests are Non-confirmable and
NON_PAYLOADS payloads have been received by the server (cc-non).
It SHOULD NOT be generated for Confirmable traffic.
This Response Code MUST be returned if the request does not
include both a Request-Tag Option and a Size1 Option but does
include a Q-Block1 option.
Either this Response Code or a reset message MUST be returned if
the server does not support the Q-Block1 Option.
This Response Code returned without Content-Type "application/
missing-blocks+cbor-seq" (new-format) is handled as in
Section 2.9.2 RFC7959.
This Response Code returned with Content-Type "application/
missing-blocks+cbor-seq" indicates that some of the payloads are
missing and need to be resent.  The client then retransmits the
missing payloads using the same Request-Tag, Size1 and Q-Block1 to
specify the block number, SZX, and M bit as appropriate.
The Request-Tag value to use is determined from the token in the
4.08 (Request Entity Incomplete) response and then finding the
matching client request which contains the Request-Tag that is
being used for this Q-Block1 body.
This Response Code can be returned under similar conditions to
those discussed in Section 2.9.3 of RFC7959.
This Response Code can be returned if there is insufficient space
to create a response PDU with a block size of 16 bytes (SZX = 0)
to send back all the response options as appropriate.  In this
case, the Size1 Option is not included.
If the server has not received all the payloads of a body, but one or
more Non-confirmable payloads have been received, it SHOULD wait for
up to NON_RECEIVE_TIMEOUT (cc-non) before sending a 4.08 (Request
Entity Incomplete) response.  Further discussion on the timings of
transmissions of 4.08 (Request Entity Incomplete) and 2.31 (Continue)
responses is in cc-non.
If a server receives payloads with different Request-Tags for the
same resource, it should continue to process all the bodies as it has
no way of determining which is the latest version, or which body, if
any, the client is terminating the transmission for.
If the client elects to stop the transmission of a complete body, it
SHOULD "forget" all tracked tokens associated with the body's
Request-Tag so that a reset message is generated for the invalid
token in the 4.08 (Request Entity Incomplete) response.  The server
on receipt of the reset message SHOULD delete the partial body.
If the server receives a duplicate block with the same Request-Tag,
it SHOULD ignore the payload of the packet, but MUST still respond as
if the block was received for the first time.
A server SHOULD only maintain a partial body (missing payloads) for
up to NON_PARTIAL_TIMEOUT (cc-non).
The payloads sent back from the server as a response MUST all have a
Size2 Option (See size).  The Size2 value MUST be the same for all of
the responses for the body of data that is being transferred.
If the client detects that some of the payloads are missing, the
missing payloads are requested by issuing a new GET, POST, PUT,
FETCH, PATCH, or iPATCH request that contains one or more Q-Block2
Options that define the missing blocks with the M bit unset.
The ETag Option MUST NOT be used in the request as the server could
respond with a 2.03 (Valid Response) with no payload.  If the server
responds with a different ETag Option value (as the resource
representation has changed), then the client SHOULD drop all the
payloads for the current body that are no longer valid.
The client may elect to request the missing blocks or just ignore the
partial body.  It SHOULD wait for up to MAX_TRANSMIT_SPAN
(Section 4.8.2 of RFC7252) before issuing a GET, POST, PUT, FETCH,
PATCH, or iPATCH request for the missing blocks.  However, this time
MAY be reduced to two times ACK_TIMEOUT before sending the request to
cover the situation where MAX_PAYLOADS has been triggered by the
server causing a break in transmission.
With NON transmission, the client only needs to indicate that some of
the payloads are missing by issuing a GET, POST, PUT, FETCH, PATCH,
or iPATCH request for the missing blocks.
For Confirmable transmission, the client SHOULD continue to
acknowledge each packet as well as issuing a separate GET, POST, PUT,
FETCH, PATCH, or iPATCH for the missing blocks.
If the server transmits a new body of data (e.g., a triggered
Observe) with a new ETag to the same client as an additional
response, the client MUST remove any partially received body held for
a previous ETag.
A client SHOULD only maintain a partial body (missing payloads) for
up to EXCHANGE_LIFETIME (Section 4.8.2 of RFC7252) or as defined by
the Max-Age Option, whichever is the less.
If there is insufficient space to create a response PDU with a block
size of 16 bytes (SZX = 0) to reflect back all the request options as
appropriate, a 4.13 (Request Entity Too Large) is returned without
the Size2 Option.
The client may elect to request any detected missing blocks or just
ignore the partial body.  This decision is implementation specific.
The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (cc-non) after
the last received payload for Non-confirmable payloads before issuing
a GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one
or more Q-Block2 Options that define the missing blocks with the M
bit unset.  Further discussion on the timings of transmissions for
missing requests is discussed in (cc-non).
For Confirmable responses, the client continues to acknowledge each
packet.  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.
A client SHOULD only maintain a partial body (missing payloads) for
up to NON_PARTIAL_TIMEOUT (cc-non) or as defined by the Max-Age
Option (or its default), whichever is the less.
The ETag Option should not be used in the request for missing blocks
as the server could respond with a 2.03 (Valid Response) with no
payload.  It can be used in the request if the client wants to check
the freshness of the currently cached body response.
If the server detects part way through a body transfer that the
resource data has changed and the server is not maintaining a cached
copy of the old data, then the body response SHOULD be restarted with
a different ETag Option value.  Any subsequent missing block requests
MUST be responded to using the latest ETag Option value.
If the server responds during a body update with a different ETag
Option value (as the resource representation has changed), then the
client should treat the partial body with the old ETag as no longer
being fresh.
If the server transmits a new body of data (e.g., a triggered
Observe) with a new ETag to the same client as an additional
response, the client should remove any partially received body held
for a previous ETag for that resource as it is unlikely the missing
blocks can be retrieved.
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
appropriate, a 4.13 (Request Entity Too Large) is returned without
the Size1 Option.
If the client requests missing blocks, this is treated as a new
request.  The Observe value may change but MUST still be reported.
If the ETag value changes then the previously received partial body
should be destroyed and the whole body re-requested.
If the client requests missing blocks, this is treated as a new
Request and the Observe Option MUST NOT be included.  If the ETag
value in the response changes, then the previously received partial
body should be considered as not fresh and the whole body re-
requested.
The data payload of the 4.08 (Request Entity Incomplete) Response
Code is encoded as a CBOR Sequence RFC8742.  First is CBOR encoded
Request-Tag followed by 1 or more missing CBOR encoded missing block
numbers.  The missing block numbers MUST be unique in each 4.08
(Request Entity Incomplete) when created by the server; the client
SHOULD drop any duplicates in the same 4.08 (Request Entity
Incomplete) message.
The Content-Format Option (Section 5.10.3 of RFC7252) MUST be used in
the 4.08 (Request Entity Incomplete) Response Code.  It MUST be set
to "application/missing-blocks+cbor-seq" (see new-format).
The data payload of the 4.08 (Request Entity Incomplete) response is
encoded as a CBOR Sequence RFC8742.  There are one or more missing
CBOR encoded missing block numbers.  The missing block numbers MUST
be unique in each 4.08 (Request Entity Incomplete) response when
created by the server; the client SHOULD drop any duplicates in the
same 4.08 (Request Entity Incomplete) response.
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
"application/missing-blocks+cbor-seq" (see new-format).
The token to use for the response SHOULD be the token that was used
in the highest block number received payload.  The Q-Block1 Option
from the same packet SHOULD be included.
Updating the payload without overflowing the overall packet size
as each block number can be of varying length needs consideration.
It is possible to use Indefinite-Length Arrays (Section 3.2.2 of
RFC8949), limit the array count to 23 (Undefined value) so that
the array data byte can be updated with the overall length once
the payload length is confirmed or limited to MAX_PAYLOADS count.
Limiting the count to MAX_PAYLOADS means that Congestion Control
is less likely to be invoked on the server.
Updating the payload without overflowing the overall packet size
as each block number can be of varying length needs consideration.
It is possible to use Indefinite-Length Arrays (Section 3.2.2 of
RFC8949), or alternatively limit the array count to 23 so that the
initial byte with the array major type and data length in the
additional information can be updated with the overall count once
the payload count is confirmed.  Further restricting the count to
NON_PAYLOADS means that Congestion Control is less likely to be
invoked on the server.
The 4.08 (Request Entity Incomplete) with Content-Type "application/
missing-blocks+cbor-seq" SHOULD NOT be used when using Confirmable
requests or a reliable connection RFC8323 as the client will be able
to determine that there is a transmission failure of a particular
payload and hence that the server is missing that payload.
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 (Section 4.7 of RFC7252).
Each NON 4.08 (Request Entity Incomplete) Response Codes is subjected
to PROBING_RATE.
Each NON GET or similar request using Q-Block2 Option is subjected to
PROBING_RATE.
As the sending of many payloads of a single body may itself cause
congestion, it is RECOMMENDED that after transmission of every set of
MAX_PAYLOADS payloads of a single body, a delay is introduced of
ACK_TIMEOUT (Section 4.8.2 of RFC7252) before the next set of payload
transmissions to manage potential congestion issues.  MAX_PAYLOADS
should be configurable with a default value of 10.
For NON transmissions, it is permissible, but not required, to send
the ultimate payload of a MAX_PAYLOADS set as a Confirmable packet.
If a Confirmable packet is used, then the transmitting peer MUST wait
for the ACK to be returned before sending the next set of payloads,
which can be in time terms less than the ACK_TIMEOUT delay.
Also, for NON transmissions, it is permissible, but not required, to
send a Confirmable packet for the final payload of a body transfer
(that is, M bit unset).  If a Confirmable packet is used, then the
transmitting peer MUST wait for the appropriate response to be
returned for successful transmission, or respond to requests for the
missing blocks (if any).
The sending of the set of missing blocks is subject to MAX_PAYLOADS.
Note: A delay of ACK_TIMEOUT after every transmission of
MAX_PAYLOADS blocks may be observed even if the peer agent is able
to handle more blocks without experiencing an overload.  This
delay can be reduced by using CON for the MAX_PAYLOADS packet to
trigger sending the next set of data when the ACK is received.
Nevertheless, this behavior is likely to create other timeout
issues in a lossy environment (e.g., unidirectional loss as in
DDoS pipe flooding).  The use of NON is thus superior but requires
an additional signal (e.g., RFC7967) in the MAX_PAYLOADS packet to
seek for a 2.31 (Continue) from the peer if it is ready to receive
the next set of blocks.
For Confirmable transmission, NSTART SHOULD be increased from the
default (1) to get faster transmission rates.
Caching block based information is not straight forward in a proxy.
For Q-Block1 and Q-Block2 Options, it is expected that the proxy will
reassemble the body (using any appropriate recovery options for
packet loss) before passing on the body to the appropriate CoAP
endpoint.  The onward transmission of the body does not require the
use of the Q-Block1 or Q-Block2 Options as these options may not be
supported in that link.  This means that the proxy must fully support
the Q-Block1 and Q-Block2 Options.
How the body is cached in the initial CoAP client (Q-Block1) or
ultimate CoAP server (Q-Block2) is implementation specific.
As the entire body is being cached in the proxy, the Q-Block1 and
Q-Block2 Options are not part of the cache key.
The transmission of the payloads of a body either SHOULD all be
Confirmable, or SHOULD all be Non-confirmable.  This is to simplify
the Congestion Control requirements.
Congestion Control for Confirmable requests and responses is as
Section 4.7 of RFC7252.  For faster transmission rates, NSTART will
need to be increased from 1.  However the other Confirmable
Congestion Control parameters will need to be tuned to cover this
change.  This tuning is out of scope of this document as it is
expected that all requests and responses using Q-Block1 and Q-Block2
will be Non-confirmable.
It is implementation specific as to whether there should be any
further requests for missing data as there will have been significant
transmission failure as individual payloads will have failed after
MAX_TRANSMIT_SPAN.
This document introduces new parameters NON_PAYLOADS, NON_TIMEOUT,
NON_RECEIVE_TIMEOUT, NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT
primarily for use with Non-confirmable requests and responses.
NON_PAYLOADS should be configurable with a default value of 10.  Both
endpoints SHOULD have the same value (otherwise there will be
transmission delays in one direction) and the value MAY be negotiated
between the endpoints to a common value by using a higher level
protocol (out of scope of this document).  This is the maximum number
of payloads that can be transmitted at any one time.
NON_TIMEOUT has the same value as ACK_TIMEOUT (Section 4.8 of
RFC7252).  This is the maximum period of delay between sending sets
of NON_PAYLOADS payloads for the same body.
NON_RECEIVE_TIMEOUT has a value of twice NON_TIMEOUT.  It is the
maximum time to wait for a missing payload before requesting
retransmission.
NON_PROBING_WAIT has the same value as computed for EXCHANGE_LIFETIME
(Section 4.8.2 of RFC7252).  It is used to limit the potential wait
needed calculated when using PROBING_WAIT.
NON_PARTIAL_TIMEOUT has the same value as computed for
EXCHANGE_LIFETIME (Section 4.8.2 of RFC7252).  It is used expiring
partially received bodies.
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.
Each Non-Confirmable 4.08 (Request Entity Incomplete) response is
subjected to PROBING_RATE.
Each Non-Confirmable GET or FETCH request using Q-Block2 Option is
subjected to PROBING_RATE.
As the sending of many payloads of a single body may itself cause
congestion, it is RECOMMENDED that after transmission of every set of
NON_PAYLOADS payloads of a single body, a delay is introduced of
NON_TIMEOUT before sending the next set of payloads to manage
potential congestion issues.  If the peer endpoint consistently
reports there are missing payloads, then the value of NON_TIMEOUT
should be increased.
The sending of a set of missing payloads of a body is subject to
NON_PAYLOADS worth of payloads.
For Q-Block1, if the server responds with a 2.31 (Continue) response
for the latest payload sent, then the client can continue to send the
next set of payloads without delay.  If the server responds with a
4.08 (Request Entity Incomplete), then the missing payloads SHOULD be
retransmitted before going into another NON_TIMEOUT delay prior to
sending the next set of payloads.
For the server receiving Non-Confirmable Q-Block1 requests, it SHOULD
send back a 2.31 (Continue) or 4.08 (Request Entity Incomplete)
response on receipt of the last of the NON_PAYLOADS payloads to
prevent the client unnecessarily delaying.  If the last of the
NON_PAYLOADS payloads does not arrive (or the final payload where the
M bit is not set does not arrive), then the server SHOULD delay for
NON_RECEIVE_TIMEOUT before sending the 4.08 (Request Entity
Incomplete) response.
It is possible that the client may start transmitting the next set of
NON_PAYLOADS payloads before the server times out on waiting for the
last of the previous NON_PAYLOADS payloads.  On receipt of the first
payload from the new set of NON_PAYLOADS payloads, the server SHOULD
send a 4.08 (Request Entity Incomplete) response indicating any
missing payloads from any previous NON_PAYLOADS payloads.  The client
on receipt of the 4.08 (Request Entity Incomplete) response SHOULD
send the missing payloads before continuing to send the remainder of
the NON_PAYLOADS payloads and then go into another NON_TIMEOUT delay
prior to sending the next set of payloads.
For the client receiving Non-Confirmable Q-Block2 responses, it
SHOULD send a request for the next set of payloads, or a request for
the missing payloads on receipt of the last of the NON_PAYLOADS
payloads to prevent the server unnecessarily delaying the
transmission of the body.  If the last of the NON_PAYLOADS payloads
does not arrive (or the final payload where the M bit is not set does
not arrive), then the client SHOULD delay for NON_RECEIVE_TIMEOUT
before sending the request for the missing payloads.
The request that the client sends to acknowledge the reciept of all
the current set of NON_PAYLOADS payloads SHOULD contain a Q-Block2
Option with NUM set to first block of the next set of NON_PAYLOADS
payloads and M bit set to 1.  The server SHOULD recognize this as a
continue request and just continue the transmission of the body
(inclusing Observe option if appropriate for an unsolicited response)
rather than as a request for missing blocks.
On receipt of the entire body, the client does not need to
acknowledge this.
Note: If there is asymmetric traffic loss causing responses to
never get received, a delay of NON_TIMEOUT after every
transmission of NON_PAYLOADS blocks will be observed.  The
endpoint receiving the body is still likely to receive the entire
body.
Caching block based information is not straight forward in a proxy.
For Q-Block1 and Q-Block2 Options, for simplicity it is expected that
the proxy will reassemble the body (using any appropriate recovery
options for packet loss) before passing on the body to the
appropriate CoAP endpoint.  This does not preclude an implementation
doing a more complex per payload caching, but how to do this is out
of the scope of this document.  The onward transmission of the body
does not require the use of the Q-Block1 or Q-Block2 Options as these
options may not be supported in that link.  This means that the proxy
must fully support the Q-Block1 and Q-Block2 Options.
How the body is cached in the CoAP client (for Q-Block1
transmissions) or the CoAP server (for Q-Block2 transmissions) is
implementation specific.
As the entire body is being cached in the proxy, the Q-Block1 and
Q-Block2 Options are removed as part of the block assembly and thus
do not reach the cache.
For requests with Q-Block1 Option, the Request-Tag Option is
associated with the build up of the body from successive payloads,
but is not part of the cache key.  For the onward transmission of the
body using CoAP, a new Request-Tag SHOULD be generated and used.
For requests with Q-Block1 Option, the Request-Tag Option is
associated with the build up of the body from successive payloads,
but is not part of the cache key.  For the onward transmission of the
body using CoAP, a new Request-Tag SHOULD be generated and used.
Ideally this new Request-Tag should replace the client's request
Request-Tag.
It is possible that two or more CoAP clients are concurrently
updating the same resource through a common proxy to the same CoAP
server using Q-Block1 (or Block1) Option.  If this is the case, the
first client to complete building the body causes that body to start
transmitting to the CoAP server with an appropriate Request-Tag
value.  When the next client completes building the body, any
existing partial body transmission to the CoAP server is terminated
and the new body representation transmission starts with a new
Request-Tag value.
A proxy that supports Q-Block2 Option MUST be prepared to receive a
GET or similar message 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-Block2s.  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.
It is possible that two or more CoAP clients are concurrently
updating the same resource through a common proxy to the same CoAP
server using Q-Block1 (or Block1) Option.  If this is the case, the
first client to complete building the body causes that body to start
transmitting to the CoAP server with an appropriate Request-Tag
value.  When the next client completes building the body, any
existing partial body transmission to the CoAP server is terminated
and the new body representation transmission starts with a new
Request-Tag value.  Note that it cannot be assumed that the proxy
will always receive a complete body from a client.
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-Block2s.  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.
The server realizes that some blocks are missing and asks for the
missing ones in one go (B3non2).  It does so by indicating which
blocks have been received in the data portion of the response.
Under high levels of traffic loss, the client can elect not to retry
sending missing blocks of data.  This decision is implementation
specific.
nonb4 illustrates the example of Q-Block2 Option.  The client sends a
NON GET carrying an Observe and a Q-Block2 Options.  The Q-Block2
Option indicates a size hint (1024 bytes).  This request is replied
by the server using four (4) blocks that are transmitted to the
client without any loss.  Each of these blocks carries a Q-Block2
Option.  The same process is repeated when an Observe is triggered,
but no loss is experienced by any of the notification blocks.
The server realizes that some blocks are missing and asks for the
missing ones in one go (B3non2).  It does so by indicating which
blocks have been received in the data portion of the response.  The
Token just needs to be one of those that have been received for this
Request-Tag, so the client can derive the Request-Tag.
Under high levels of traffic loss, the client can elect not to retry
sending missing blocks of data by "forgetting" all the tracked tokens
for this Request-Tag. This decision is implementation specific.
nonb4 illustrates the example of Q-Block2 Option.  The client sends a
NON GET carrying an Observe and a Q-Block2 Options.  The Q-Block2
Option indicates a block size hint (1024 bytes).  This request is
replied to by the server using four (4) blocks that are transmitted
to the client without any loss.  Each of these blocks carries a
Q-Block2 Option.  The same process is repeated when an Observe is
triggered, but no loss is experienced by any of the notification
blocks.