Draft: draft-ietf-core-new-block

Commentary: Hello Med , hello  , here 's a few concrete points I 'd like to suggest for new - block : Applicability : I 'd have expected to read something like this in the introduction : Separation of layers , sub - topic " congestion control " : It should be possible to phrase all congestion control parts of this in a dedicated section ( which may also make sense as an appendix ) . I 'd avoid all other mentions of things like PROBINGRATE : For example , Section 3.4 right in the middle of a paragraph on re - requesting missing blocks states that Yes it is , but so is every single CoAP request until the client hears back from the server . Repeating these things in places where are not a new requirement may make it easier for some implementers that try to build the whole stack in a single go , but even for them is prone to the authors missing a spot -- and for everyone else this will each time trigger the question of " is this new here or is n't this already handled by a component two layers down the stack ? " . I have n't tracked every single retransmission and rate limiting statement throughout the document , but I expect that this section could boil down to something like ( The latter replaces MAXPAYLOADS , and I 'm not sure whether it is better to express this in terms of package count or bytes on the wire , just giving an example here . All numbers in the above were pulled out of uninformed air . ) Separation of layers , sub - topic " Tokens " : Same thing , next layer . Whenever you 're tempted to talk of a token , consider some of these replacement phrases as a first step : " MUST be sent with a new token " -"is a new request " . "  MUST be included " -(nothing -- transports use tokens by construction ) " MUST be sent with the same token as the response " -"is sent as a response to " / " is sent as an additional response to that request " . ( Here it may make sense to refer to the tokens in an additional " ( which means it uses the same token , the same way an observation response uses the requests 's token for multiple responses ) " ) . Naming : It 's technically a minor thing , but people have already complained to me about how hard the Block[12 ] names are to comprehend , and introducing these options as Block[34 ] would not help here . I 'd like to suggest QuickBlock - Block[12 ] . ( I know that this part of designing a new option is annoying . In the interest of winding up with something that can be learned easily , it is unfortunately essential ) . In connection with that , it may make sense to briefly think about a draft name before it is submitted as a WG draft . new - block sounds like a 7959bis , which in my understanding this does not aim to be . 4.TBA3 Missing Payloads : I do n't quite see why this needs a distinct code . 4.08 Request Entity Incomplete sounds perfectly suitable to me . If you think that sending an existing 4.xx code in the middle of a block - wise transfer would cancel the transfer , there 's still two ways out of this : You 're just defining what a block - wise transfer is ; just allow it . ( In a RFC7959 block - wise transfer that runs over a proxy , the proxy may be currently incapable of doing any forwarding and return 5.03 Service Unavailable Max - Age:5 . The client would then just pause 5 seconds and send the latest block again . ) For all but the last block , it may also be an option to send it as a payload to a 2.31 code -- I do n't think that would be outright forbidden ( and at any rate , all involved clients speak the protocol anyway ) . 
 We do n't have an objection to this proposal . We asked the Chairs for guidance before we submitted -00 with " new - block " instead or " quick - block " . This one is thus closed .
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 asymmetrical packet loss is not a benefit
here.  Some sample examples with Confirmable messages are provided in
CON.
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 asymmetrical packet loss.  Some sample examples with
Confirmable messages are provided in CON.
This document updates the 4.08 (Request Entity Incomplete) by
defining an additional message format for reporting on payloads using
the Q-Block1 Option that are not received by the server.
This document adds a media type for the 4.08 (Request Entity
Incomplete) response defining an additional message format for
reporting on payloads using the Q-Block1 Option that are not received
by the server.
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 C and U columns are marked for the
Q-Block1 Option.  C, U, and R 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.
Q-Block1 Option is useful with the payload-bearing POST, PUT, PATCH,
and iPATCH requests and their responses (2.01 and 2.04).
Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH,
PATCH, and iPATCH requests and their responses (2.01 and 2.04).
The Q-Block1 Option is used when the client wants to send a large
amount of data to the server using the POST, PUT, PATCH, or iPATCH
methods where the data and headers do not fit into a single packet.
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
in nature, but it is RECOMMENDED that the client treats it as an
unsigned integer of 8 bytes in length.  An implementation may want to
consider limiting this to 4 bytes to reduce packet overhead size.
The server still treats it as an opaque entity.  The Request-Tag
value MUST be different for distinct bodies or sets of blocks of data
and SHOULD be incremented whenever a new body of data is being
transmitted between peers.  The initial Request-Tag value SHOULD be
randomly generated by the client.
For Confirmable transmission, the server MUST continue to acknowledge
each packet.
The Q-Block1 Option is used when the client wants to send a large
amount of data to the server using the POST, PUT, FETCH, PATCH, or
iPATCH methods where the data and headers do not fit into a single
packet.
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.
It is suggested that the client treats the Request-Tag as an
unsigned integer of 8 bytes in length.  An implementation may want
to consider limiting this to 4 bytes to reduce packet overhead
size.  The initial Request-Tag value SHOULD be randomly generated
and then subsequenty incremented by the client whenever a new body
of data is being transmitted between peers.
For Confirmable transmission, the server continues to acknowledge
each packet, but a response is not required (whether separate or
piggybacked) until retransmission or successful receipt of the body.
The ETag is opaque in nature, but it is RECOMMENDED that the server
treats it as an unsigned integer of 8 bytes in length.  An
implementation may want to consider limiting this to 4 bytes to
reduce packet overhead size.  The client still treats it as an opaque
entity.  The ETag value MUST be different for distinct bodies or sets
of blocks of data and SHOULD be incremented whenever a new body of
data is being transmitted between peers.  The initial ETag value
SHOULD be randomly generated by the server.
The ETag is opaque, the client still treats it as opaque but the
server SHOULD ensure that it is unique for every different body of
transmitted data.
It is suggested that the server treats the ETag as an unsigned
integer of 8 bytes in length.  An implementation may want to
consider limiting this to 4 bytes to reduce packet overhead size.
The initial ETag value SHOULD be randomly generated and then
subsequenty incremented by the server whenever a new body of data
is being transmitted between peers.