Draft: draft-ietf-core-new-block

Commentary: Updated text pushed . 
 Thanks .
Q-Block1 and Q-Block2 Options are designed to work with Non-
confirmable requests and responses, in particular.
Q-Block1 and Q-Block2 Options are designed to work in particular with
Non-confirmable requests and responses.
However, with methods needing both Q-Block1 for the request and
Q-Block2 for the response, and there is need for recovery following
payload loss, the numbers of packets needed to initiate and complete
the recovery can get very large as a function of the severity of the
experienced loss.
In CoAP over TCP, Capabilities and Settings Messages (CSMs) can be
used to indicate support of Q-Block Options by means of the Q-Block-
Wise-Transfer Capability Option (Table 2).  The behavior of CoAP
peers is similar to the one specified in Section 5.3.2 of RFC8323,
except that it indicates support of Q-Block Options.
Alternatively, with CoAP over TCP, Capabilities and Settings Messages
(CSMs) can be used to indicate support of Q-Block Options by means of
the Q-Block-Wise-Transfer Capability Option (Table 2).  The behavior
of CoAP peers is similar to the one specified in Section 5.3.2 of
RFC8323, except that it indicates support of Q-Block Options.
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.
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.
This Response Code indicates successful receipt of the entire
FETCH request body (Section 2 of RFC8132) and the appropriate
representation of the resource has been returned.  The token used
in the response MUST be the one in the FETCH request that has the
Q-Block1 with the M bit unset.  If the FETCH request includes the
Observe Option, then the server MUST use the same token for
returning any Observe triggered responses.  The client should then
release all of the tokens used for this body unless a resource is
being observed.
This Response Code indicates successful receipt of the entire
FETCH request body (Section 2 of RFC8132) and the appropriate
representation of the resource is being returned.  The token used
in the response MUST be the one in the FETCH request that has the
Q-Block1 with the M bit unset.  If the FETCH request includes the
Observe Option, then the server MUST use the same token for
returning any Observe triggered responses.  The client should then
release all of the tokens used for this body unless a resource is
being observed.
Either this Response Code or a reset message MUST be returned if
the server does not support the Q-Block1 Option.
Either this Response Code (Confirmable) or a reset message (Non-
confirmable) MUST be returned if the server does not support the
Q-Block1 Option.
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
matching client request which contains the Request-Tag that is
being used for this Q-Block1 body.
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 NUM, SZX, and M bit as appropriate.
The Request-Tag value to use is determined by taking the token in
the 4.08 (Request Entity Incomplete) response, locating the
matching client request, and then using its Request-Tag.
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.
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 in the response.
This is used to confirm that the current set of MAX_PAYLOADS
payloads (the latest one having block number NUM-1) has been
successfully received and that, upon receipt of this request, the
server can continue to send the next set of payloads (the first
one having block number NUM).  This is the 'Continue' Q-Block-2.
This is used to confirm that the current set of MAX_PAYLOADS
payloads (the latest one having block number NUM-1) has been
successfully received and that, upon receipt of this request, the
server can continue to send the next set of payloads (the first
one having block number NUM).  This is the 'Continue' Q-Block-2
and conceptually has the same usage (i.e., continue sending the
next set of data) as the use of 2.31 (Continue) for Q-Block1.
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.
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 of 60 seconds (Section 5.6.1 of RFC7252)),
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 locally cached body response.
It is RECOMMENDED that the server maintains a cached copy of the body
when using the Q-Block2 Option to facilitate retransmission of any
missing payloads.
If the server reports any missing payload, the client re-sends the
missing payload(s).  Each re-sent payload is treated as a new request
and the Observe Option MUST be included in the request.
If the response (or associated response) uses Q-Block2 Option, and
one of the response payloads is missing, the request for the missing
payload(s) is treated as a new request.  The request MUST comprise of
all of the request payloads and the Observe Option MUST NOT be
included in either the request or response.
If the client requests missing blocks, this is treated as a new
Request and the Observe Option MUST NOT be included in either the
request or response.  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.
For a request that uses Q-Block1, the Observe Option and value
RFC7641 MUST be the same for all the payloads of the same body.  This
includes any missing payloads that are retransmitted.
For a response that uses Q-Block2, the Observe Option and value MUST
be the same for all the payloads of the same body.  This includes
payloads transmitted following receipt of the 'Continue' Q-Block2
Option (qblock2) by the server.  If a missing payload is requested,
then both the request and response MUST NOT include the Observe
Option.
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 work, but providing the one used in the last
received block number will aid any troubleshooting.  The client will
use the token to determine what is the previously sent request to
obtain the Request-Tag value to be used.
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 work, but providing the one used in the last
received block number will aid any troubleshooting.  The client will
use the token to determine what was the previously sent request to
obtain the Request-Tag value to be used.
To minimize on the number of tokens that have to be tracked by
clients, it is recommended that the bottom 32 bits is kept the
same for the same body and the upper 32 bits contains the
individual payload number.
To minimize on the number of tokens that have to be tracked by
clients, it is recommended that the bottom 32 bits is kept the
same for the same body and the upper 32 bits contains the
individual payload number.  This allows the client to be
alleviated from keeping all the per-request-state, e.g., in
Section 3 of RFC8974.
The transmission of the payloads of a body either SHOULD all be
Confirmable or all be Non-confirmable.  This is meant to simplify the
congestion control procedure.
The transmission of the payloads of a body over an unreliable
transport SHOULD either all be Confirmable or all be Non-confirmable.
This is meant to simplify the congestion control procedure.
As a reminder, there is no need for CoAP-specific congestion control
for reliable transports RFC8323.
NON_RECEIVE_TIMEOUT is the maximum time to wait for a missing payload
before requesting retransmission.  NON_RECEIVE_TIMEOUT has a value of
twice NON_TIMEOUT.
NON_MAX_RETRANSMIT is the maximum number of times a request for the
retransmission of missing payloads can occur without a response from
the remote peer.  After this occurs, the peer SHOULD consider the
body stale and remove all references to it.  By default,
NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT (Section 4.8
of RFC7252).
NON_RECEIVE_TIMEOUT has a default value of twice NON_TIMEOUT.
NON_RECEIVE_TIMEOUT MUST always be greater than NON_TIMEOUT by at
least one second so that the sender of the payloads has the
opportunity to start sending the next set of payloads before the
receiver times out.
NON_MAX_RETRANSMIT is the maximum number of times a request for the
retransmission of missing payloads can occur without a response from
the remote peer.  After this occurs, the local endpoint SHOULD
consider the body stale and remove all references to it.  By default,
NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT (Section 4.8
of RFC7252).
For the server receiving NON Q-Block1 requests, it SHOULD send back a
payloads to prevent the client unnecessarily delaying.  Otherwise the
server SHOULD delay for NON_RECEIVE_TIMEOUT, before sending the 4.08
(Request Entity Incomplete) Response Code.  The NON_RECEIVE_TIMEOUT
delay may be reduced for the first time that this 4.08 (Request
Entity Incomplete) is sent if either the last of the MAX_PAYLOADS
payloads or the final payload with the M bit unset arrives, but
SHOULD NOT be reduced to zero as packets may arrive in the wrong
order.
For the server receiving NON Q-Block1 requests, it SHOULD send back a
payloads to prevent the client unnecessarily delaying.  Otherwise the
server SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled
based on the repeat request count for a payload), before sending the
payload(s).  If the repeat request count for a missing payload
exceeds NON_MAX_RETRANSMIT, the server SHOULD discard the partial
body and stop requesting the missing payloads.
For the client receiving NON Q-Block2 responses, it SHOULD send a
request 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, before
sending the request for the missing payloads.  The
NON_RECEIVE_TIMEOUT delay may be reduced for the first time that this
request is sent if either the last of the MAX_PAYLOADS payloads or
the final payload with the M bit unset arrives, but SHOULD NOT be
reduced to zero as packets may arrive in the wrong order.
The request that the client sends to acknowledge the receipt of all
the current set of MAX_PAYLOADS payloads is the 'Continue' Q-Block2
Option ('NUM modulo MAX_PAYLOADS' is zero, NUM is not zero, and M bit
is set (qblock2)).  The server SHOULD recognize this as a continue
request and just continue the transmission of the body (including
Observe Option, if appropriate for an unsolicited response) rather
than as a request for the remaining missing blocks.
It is possible that the server may start transmitting the next set of
MAX_PAYLOADS payloads before the client times out on waiting for the
last of the previous MAX_PAYLOADS payloads.  Upon receipt of the
first payload from the new set of MAX_PAYLOADS payloads, the client
SHOULD send a request indicating any missing payloads from any
previous set of MAX_PAYLOADS payloads.  Upon receipt of such request,
the server SHOULD send the missing payloads before continuing to send
the remainder of the MAX_PAYLOADS payloads and then go into another
NON_TIMEOUT delay prior to sending the next set of payloads.
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.
The server SHOULD recognize the 'Continue' Q-Block2 request as a
continue request and just continue the transmission of the body
(including Observe Option, if appropriate for an unsolicited
response) rather than as a request for the remaining missing blocks.
It is likely that the server will start transmitting the next set of
MAX_PAYLOADS payloads before the client times out on waiting for the
last of the previous MAX_PAYLOADS payloads.  Upon receipt of the
first payload from the new set of MAX_PAYLOADS payloads, the client
SHOULD send a request indicating any missing payloads from any
previous set of MAX_PAYLOADS payloads.  Upon receipt of such request,
the server SHOULD send the missing payloads before continuing to send
the remainder of the MAX_PAYLOADS payloads and then go into another
NON_TIMEOUT delay prior to sending the next set of payloads.
On seeing a payload from the next set of payloads, the server
realizes that some blocks are missing from the previous MAX_PAYLOADS
payloads and asks for the missing blocks in one go (B3non2).  It does
so by indicating which blocks have not been received in the data
portion of the response.  The token used in the response should be
the token that was used in the last block number received payload.
The client can then derive the Request-Tag by matching the token with
the sent request.
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. Similarly, the server can elect to not to
continue asking for missing blocks.  Both these decisions are
implementation specific.
On seeing a payload from the next set of payloads, the server
realizes that some blocks are missing from the previous MAX_PAYLOADS
payloads and asks for the missing blocks in one go (B3non2).  It does
so by indicating which blocks from the previous MAX_PAYLOADS payloads
have not been received in the data portion of the response.  The
token used in the response should be the token that was used in the
last block number received payload.  The client can then derive the
Request-Tag by matching the token with the sent request.
B3non3 depicts an example of a NON PUT request conveying Q-Block1
Option where recovery takes place, but eventually fails.
These examples include the Observe Option to demonstrate how that is
used.  The Observe Option is not required for Q-Block2 and the
observe detail can be ignored.
nonb41 shows the example of an Observe that is triggered but for
which some notification blocks are lost.  The client detects the
missing blocks and requests their retransmission.  It does so by
indicating the blocks that were successfully received.
Under high levels of traffic loss, the client can elect not to retry
getting missing blocks of data.  This decision is implementation
specific.
nonb41 shows the example of an Observe that is triggered but for
which some notification blocks are lost.  The client detects the
missing blocks and requests their retransmission.  It does so by
indicating the blocks that are missing as one or more Q-Block2
Options.
The client realizes that not all the payloads of the response have
been returned.  The client then asks for the missing blocks in one go
(b12non3).  However, because the original request is spread over
multiple payloads using Q-Block1, the entire FETCH body has to be
used to make the request for the missing payloads.
The client realizes that not all the payloads of the response have
been returned.  The client then asks for the missing blocks in one go
(b12non3).  Note that, following Section 2.7 of RFC7959, the FETCH
request does not include the Q-Block1 or any payload.
This document suggests 19 (TBA1) and 51 (TBA2) as a values to be
assigned for the new option numbers.
This document suggests 19 (TBA1) and 51 (TBA2) as values to be
assigned for the new option numbers.
This document suggests 272 (TBA3) as a value to be assigned for the
new content format number.
This document suggests 8 (TBA4) as a value to be assigned for the new
option number.