Draft: draft-ietf-core-new-block

Commentary: Define and use MAXPAYLOADSSET
MAX_PAYLOADS_SET is the set of blocks when the block numbers divided
by MAX_PAYLOADS have the same numeric result.  E.g., if MAX_PAYLOADS
is 10, a MAX_PAYLOADS_SET could be blocks #0 to #9, or #10 to #19,
etc.  Depending on the data size, the final MAX_PAYLOADS_SET may not
comprise of all of the MAX_PAYLOADS blocks.
A response using this Response Code SHOULD NOT be generated for
every received Q-Block1 Option request (cc-non).  It SHOULD only
be generated when all the payload requests are Non-confirmable and
a set of MAX_PAYLOADS payloads have been received by the server.
More details about the motivations for this optimization are
discussed in cc-non.
A response using this Response Code SHOULD NOT be generated for
every received Q-Block1 Option request (cc-non).  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 cc-
non.
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.
This is a request for that block and for all of the remaining
blocks in the current MAX_PAYLOADS set.
This is used to confirm that the current MAX_PAYLOADS_SET (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 MAX_PAYLOADS_SET (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.
This is a request for that block and for all of the remaining
blocks in the current MAX_PAYLOADS_SET.
For NON payloads, the client SHOULD wait NON_RECEIVE_TIMEOUT (cc-non)
after the last received payload before requesting retransmission of
any missing blocks.  Retransmission is requested by issuing a GET,
POST, PUT, FETCH, PATCH, or iPATCH request that contains one or more
Q-Block2 Options that define the missing block(s).  Generally the M
bit on the Q-Block2 Option(s) SHOULD be unset, although the M bit MAY
be set to request this and later blocks from this MAX_PAYLOADS set,
see sec-nonb411 for an example of this in operation.  Further
considerations related to the transmission timing for missing
requests are discussed in cc-non.
For NON payloads, the client SHOULD wait NON_RECEIVE_TIMEOUT (cc-non)
after the last received payload before requesting retransmission of
any missing blocks.  Retransmission is requested by issuing a GET,
POST, PUT, FETCH, PATCH, or iPATCH request that contains one or more
Q-Block2 Options that define the missing block(s).  Generally the M
bit on the Q-Block2 Option(s) SHOULD be unset, although the M bit MAY
be set to request this and later blocks from this MAX_PAYLOADS_SET,
see sec-nonb411 for an example of this in operation.  Further
considerations related to the transmission timing for missing
requests are discussed in cc-non.
NON_TIMEOUT is the period of delay between sending sets of
MAX_PAYLOADS payloads for the same body.  By default, NON_TIMEOUT has
the same value as ACK_TIMEOUT (Section 4.8 of RFC7252).
NON_TIMEOUT is the period of delay between sending MAX_PAYLOADS_SET
for the same body.  By default, NON_TIMEOUT has the same value as
ACK_TIMEOUT (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_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 MAX_PAYLOADS_SET before the
receiver times out.
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
NON_TIMEOUT before sending the next set of payloads to manage
potential congestion issues.
As the sending of many payloads of a single body may itself cause
congestion, it is RECOMMENDED that after transmission of every
MAX_PAYLOADS_SET of a single body, a delay is introduced of
NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to manage
potential congestion issues.
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 subject to
MAX_PAYLOADS set of payloads.
For Q-Block1 Option, if the server responds with a 2.31 (Continue)
Response Code for the latest payload sent, then the client can
continue to send the next set of payloads without any delay.  If the
server responds with a 4.08 (Request Entity Incomplete) Response
Code, 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 Q-Block1 requests, it SHOULD send back a
payloads to prevent the client unnecessarily delaying.  If not all of
the MAX_PAYLOADS payloads were received, the server SHOULD delay for
NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request
count for a payload) before sending the 4.08 (Request Entity
Incomplete) Response Code for the missing payload(s).  If all of the
MAX_PAYLOADS blocks were received and a 2.31 (continue) had been
sent, but no more payloads were received for NON_RECEIVE_TIMEOUT
(exponentially scaled), the server SHOULD send a 4.08 (Request Entity
Incomplete) response detailing the missing payloads after the block
number that was indicated in the sent 2.31 (Continue).  If the repeat
request count for missing payloads exceeds NON_MAX_RETRANSMIT, the
server SHOULD discard the partial body and stop requesting the
missing payloads.
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 those in a
MAX_PAYLOADS_SET at a time.
For Q-Block1 Option, if the server responds with a 2.31 (Continue)
Response Code for the latest payload sent, then the client can
continue to send the next MAX_PAYLOADS_SET without any delay.  If the
server responds with a 4.08 (Request Entity Incomplete) Response
Code, 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 Q-Block1 requests, it SHOULD send back a
MAX_PAYLOADS_SET to prevent the client unnecessarily delaying.  If
not all of the MAX_PAYLOADS_SET were received, the server SHOULD
delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the
repeat request count for a payload) before sending the 4.08 (Request
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
sent, but no more payloads were received for NON_RECEIVE_TIMEOUT
(exponentially scaled), the server SHOULD send a 4.08 (Request Entity
Incomplete) response detailing the missing payloads after the block
number that was indicated in the sent 2.31 (Continue).  If the repeat
request count for missing payloads exceeds NON_MAX_RETRANSMIT, the
server SHOULD discard the partial body and stop requesting the
missing payloads.
It is likely that the client will start transmitting the next set of
MAX_PAYLOADS payloads before the server times out on waiting for the
last of the previous MAX_PAYLOADS payloads.  On receipt of a payload
from the new set of MAX_PAYLOADS payloads, the server SHOULD send a
payloads from any previous MAX_PAYLOADS payloads.  Upon receipt of
the 4.08 (Request Entity Incomplete) Response Code, the client 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.
It is likely that the client will start transmitting the next
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
next MAX_PAYLOADS_SET, the server SHOULD send a 4.08 (Request Entity
Incomplete) Response Code indicating any missing payloads from any
previous MAX_PAYLOADS_SET.  Upon receipt of the 4.08 (Request Entity
Incomplete) Response Code, the client SHOULD send the missing
payloads before continuing to send the remainder of the
MAX_PAYLOADS_SET and then go into another NON_TIMEOUT delay prior to
sending the next MAX_PAYLOADS_SET.
For the client receiving NON Q-Block2 responses, it SHOULD send a
'Continue' Q-Block2 request (qblock2) for the next MAX_PAYLOADS_SET
on receipt of all of the MAX_PAYLOADS_SET, 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.
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 a
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.
Note: If there is asymmetric traffic loss causing responses to
never get received, a delay of NON_TIMEOUT after every
transmission of MAX_PAYLOADS blocks will be observed.  The
endpoint receiving the body is still likely to receive the entire
body.
It is likely that the server will start transmitting the next
MAX_PAYLOADS_SET before the client times out on waiting for the last
of the previous MAX_PAYLOADS_SET.  Upon receipt of a payload from the
new MAX_PAYLOADS_SET, the client SHOULD send a request indicating any
missing payloads from any previous MAX_PAYLOADS_SET.  Upon receipt of
such request, the server SHOULD send the missing payloads before
continuing to send the remainder of the MAX_PAYLOADS_SET and then go
into another NON_TIMEOUT delay prior to sending the next
MAX_PAYLOADS_SET.
Note: If there is asymmetric traffic loss causing responses to
never get received, a delay of NON_TIMEOUT after every
transmission of MAX_PAYLOADS_SET will be observed.  The endpoint
receiving the body is still likely to receive the entire body.
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 (code).
The token used in the response should be the token that was used in
the last received payload.  The client can then derive the Request-
Tag by matching the token with the sent request.
On seeing a payload from the next MAX_PAYLOAD_SET, the server
realizes that some blocks are missing from the previous
MAX_PAYLOADS_SET and asks for the missing blocks in one go (B3non2).
It does so by indicating which blocks from the previous
MAX_PAYLOADS_SET have not been received in the data portion of the
response (code).  The token used in the response should be the token
that was used in the last received payload.  The client can then
derive the Request-Tag by matching the token with the sent request.