Draft: draft-ietf-core-new-block

Commentary: Updates pushed 
 Thanks . I see some minor edits not taken into account ( e.g. , all the titles with " MAX_PAYLOAD " ) . I will merge and fix these in the master directly . I will be doing a last check and submit . 
 Apologies - missed your plural change to MAX_PAYLOAD . 
 See all the fixes at 
 Fixes in look good to me . 
 In a request , for block number 0 , the M bit unset indicates the entire body is requested . If the M bit is set for block number 0 , this indicates that this is a repeat request . Otherwise for a request , the Quick - Block2 Option MUST always have the M bit unset . 
 NEW text : In a request for any block number , the M bit unset indicates the request is just for that block . If the M bit is set , this indicates that this is a request for this block and for all of the remaining blocks within the body . If the server receives multiple requests ( implied or otherwise ) for the same block , it MUST only send back one instance of that block .
Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and
iPATCH requests and their payload-bearing responses (2.01, 2.03,
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,
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.
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.
This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT,
NON_RECEIVE_TIMEOUT, NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT
primarily for use with NON.
This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT,
NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and
NON_PARTIAL_TIMEOUT primarily for use with NON.
NON_MAX_RETRANSMIT is the maximum number of times a request for the
retransmission of missings 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_RETRANSMI has the same value as MAX_RETRANSMIT.
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 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, 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 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 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 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.
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 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.
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.
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.
nonb4 illustrates the example of Q-Block2 Option.  The client sends a
NON GET carrying Observe and 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.
nonb411 shows the example of an Observe that is triggered but only
the first two notification blocks reaches the client.  In order to
retrieve the missing blocks, the client sends a request with a single
Q-Block2 Option with the M bit set.
b12non illustrates the example of a FETCH using both Q-Block1 and
Q-Block2 along with an Observe.  No loss is experienced.
If there is a loss of a message with a Q-Block1 Option, this is
handled as shown in B3non1 and B3non2 with FETCH substitued for PUT
and 2.04 becomes a 2.05 response.
If there is a loss of a message with a Q-Block2 Option, this is
handled as shown in nonb411 with FETCH substitued for GET.
nonb411 shows the example of an Observe that is triggered but only
the first two notification blocks reach the client.  In order to
retrieve the missing blocks, the client sends a request with a single
Q-Block2 Option with the M bit set.
b12non illustrates the example of a FETCH using both Q-Block1 and
Q-Block2 Options along with an Observe Option.  No loss is
experienced.
Consider now a scenario where there are some blocks are lost in
transmission as illustrated in b12non1.
The server realizes that some blocks are missing and asks for the
missing blocks in one go (b12non2).  It does so by indicating which
blocks have not been received in the data portion of the response.
The token used in the response is 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.
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.