Draft: draft-ietf-core-new-block

Commentary: Changes pushed 
 Fixed a couple of formatting errors - code re - pushed .
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 (Table 3).
This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT,
NON_TIMEOUT_RANDOM, NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT,
NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT primarily for use with NON
(Table 3).
Note: Randomness may naturally be provided based on the traffic
profile, how probing-rate is computed (as this is an average), and
when the peer responds.  Randomness is explicitly added for some
of the congestion control parameters to handle situations where
every thing is in sync when retrying.
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_TIMEOUT is used to compute the 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_TIMEOUT_RANDOM is the initial actual delay between sending the
first two MAX_PAYLOADS_SETs of the same body.  The same delay is then
used between the subsequent MAX_PAYLOADS_SETs.  It is a random
duration (not an integral number of seconds) between NON_TIMEOUT and
(NON_TIMEOUT * ACK_RANDOM_FACTOR).  ACK_RANDOM_FACTOR is set to 1.5
as discussed in 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 MAX_PAYLOADS_SET 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_RANDOM 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.
NON_PARTIAL_TIMEOUT is used for expiring partially received bodies.
By default, NON_PARTIAL_TIMEOUT is computed in the same way as
EXCHANGE_LIFETIME (Section 4.8.2 of RFC7252).  This default value is
calculated in the same way as NON_PROBING_WAIT.
As the sending of many payloads of a single body may itself cause
congestion, after transmission of every MAX_PAYLOADS_SET of a single
body, a delay MUST be introduced of NON_TIMEOUT before sending the
next MAX_PAYLOADS_SET unless a 'Continue' is received from the peer
for the current MAX_PAYLOADS_SET, in which case the next
MAX_PAYLOADS_SET MAY start transmission immediately.
Note: Assuming 1500-byte packets and the MAX_PAYLOADS_SET having
10 payloads, this corresponds to 1500 * 10 * 8 = 120 Kbits.  With
a maximum delay of 2 seconds between MAX_PAYLOADS_SET, this
indicates an average speed requirement of 60 Kbps for a single
body should there be no responses.  This transmission rate is
further reduced by being subject to PROBING_RATE.
The sending of a set of missing blocks of a body is restricted to
those in a MAX_PAYLOADS_SET at a time.  In other words, a NON_TIMEOUT
delay is still observed between each MAX_PAYLOAD_SET.
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 further 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.
As the sending of many payloads of a single body may itself cause
congestion, after transmission of every MAX_PAYLOADS_SET of a single
body, a delay MUST be introduced of NON_TIMEOUT_RANDOM before sending
the next MAX_PAYLOADS_SET unless a 'Continue' is received from the
peer for the current MAX_PAYLOADS_SET, in which case the next
MAX_PAYLOADS_SET MAY start transmission immediately.
Note: Assuming 1500-byte packets and the MAX_PAYLOADS_SET having
10 payloads, this corresponds to 1500 * 10 * 8 = 120 Kbits.  With
a delay of 2 seconds between MAX_PAYLOADS_SET, this indicates an
average speed requirement of 60 Kbps for a single body should
there be no responses.  This transmission rate is further reduced
by being subject to PROBING_RATE.
The sending of a set of missing blocks of a body is restricted to
those in a MAX_PAYLOADS_SET at a time.  In other words, a
NON_TIMEOUT_RANDOM delay is still observed between each
MAX_PAYLOAD_SET.
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 further 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_RANDOM delay prior to sending
the next set of 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.
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_RANDOM delay
prior to sending the next MAX_PAYLOADS_SET.
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.
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_RANDOM 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_RANDOM after every
transmission of MAX_PAYLOADS_SET will be observed.  The endpoint
receiving the body is still likely to receive the entire body.