Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission
draft-ietf-core-new-block-14

[Ballot comment]
Thank you for addressing my discuss and comment points!

In reviewing the latest updates, I briefly tried to cross-reference
the formula in section 7.2:

      NON_PROBING_WAIT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - 1) *
      ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT

My initial attempt found that the corresponding formulae in RFC 7252 used
PROCESSING_DELAY instead of NON_TIMEOUT for the last term, but I did not
go back to double-check.  It's possible I'm just misreading something.

[Ballot comment]
My further comments are resolved in the current GitHub copy of the document, so once it's published as version 13 I think we're good to go as far as I'm concerned. Thanks for the discussion and changes.

--

My initial comments have been resolved or partially resolved in version 12, see https://mailarchive.ietf.org/arch/msg/core/6geK8P9I0jZBPp9a5qSrQwQNhUo/. Note I've added two new ones at the end of the list.

(draft-ietf-core-new-block-11)

1. Section 3.2

  This mechanism is not intended for general CoAP usage, and any use
  outside the intended use case should be carefully weighed against the
  loss of interoperability with generic CoAP applications.

I’m curious: is the only reason the mechanism isn’t intended for general usage, the fact some implementations won’t support it? Or does it have other deficiencies that also make it unsuitable?


2. Section 4.1

  Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and
  iPATCH requests and their payload-bearing responses (2.01, 2.02,
  2.03, 2.04, and 2.05) (Section 5.5 of [RFC7252]).

I found the list of codes incomprehensible on first encountering it, since the concept of response codes hadn’t been introduced yet. I do understand that the document assumes familiarity with CoAP; nonetheless for basic clarity I think this should say “(response codes 2.01, 2.02…”. Additionally, the reference to RFC 7252 §5.5 doesn’t seem to be especially germane?

By the way, is 2.03 indeed a payload-bearing response? The only other place the spec touches on it is in §4.4, which says “the server could respond with a 2.03 (Valid) response with no payload”.


3. Section 4.1

  To indicate support for Q-Block2 responses, the CoAP client MUST
  include the Q-Block2 Option in a GET or similar request (FETCH, for
  example), the Q-Block2 Option in a PUT or similar request, or the
  Q-Block1 Option in a PUT or similar request so that the server knows
  that the client supports this Q-Block functionality should it need to
  send back a body that spans multiple payloads.  Otherwise, the server
  would use the Block2 Option (if supported) to send back a message
  body that is too large to fit into a single IP packet [RFC7959].

Is this paragraph really supposed to mention both Q-Block2 and Q-Block1? In particular, I’m confused by the mention of both of these in relation to PUT.


4. Section 4.1

  The Q-Block1 and Q-Block2 Options are unsafe to forward.  That is, a
  CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option
  MUST reject the request or response that uses either option.

Presumably (hopefully) this is simply describing the behavior of existing spec-compliant proxies when processing the new messages. As such, is the MUST appropriate? I would think not.


5. Section 4.3

      body.  Note that the last received payload may not be the one with
      the highest block number.

“Might not” would be less ambiguous than “may not”.


6. Section 4.4 (also two places in §4.3)

(This comment rehashes, in more detail, the difficulty explained in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

  The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2)

I read this as meaning the client should wait for as little as zero, or as long as NON_RECEIVE_TIMEOUT — that’s my understanding of “up to”. Is that the intended meaning? If it is, I think it’s worth writing out as I’ve done, for clarity. If it’s not, it definitely needs to be fixed.

There’s a similar issue with “up to NON_PARTIAL_TIMEOUT” later in the section.

Referring ahead to Section 7.2 muddies the waters further. Even though the text quoted above says NON_RECEIVE_TIMEOUT is an upper limit on how long to wait, §7.2 says it’s a lower limit instead... maybe? From §7.2:

  NON_RECEIVE_TIMEOUT is the initial maximum time to wait for a missing

“Maximum”, ok great, that means “upper bound” and so lines up with §4.4 although the “initial” is surprising since §4.4 doesn’t say anything about the upper limit increasing. It continues:

  payload before requesting retransmission for the first time.  Every
  time the missing payload is re-requested, the time to wait value
  doubles.  The time to wait is calculated as:

      Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count - 1))

But this part says it’s (a) an exact time-to-wait, not a “maximum”, and (b) it says it increases exponentially, so NON_RECEIVE_TIMEOUT isn’t a maximum at all, but a minimum.

This later text in §7.2 implies that perhaps the problem in the above passages is the word “maximum”, and it should simply be deleted:

  For the server receiving NON Q-Block1 requests, it SHOULD send back a
  2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS
  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). 

Similarly “up to” in the quote that began this comment should be “at least”.

Whether you adopt those suggestions or not,  it seems as though all this needs to be rewritten with careful attention to conveying what the desired behavior is.

But the plot thickens. Later in §7.2 we have

  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 the first
  payload from the new set of MAX_PAYLOADS payloads, the server SHOULD
  send a 4.08 (Request Entity Incomplete) Response Code indicating any
  missing payloads from any previous MAX_PAYLOADS payloads.

The point being that the retransmission request can be triggered by an event other than timer expiration. So in that sense, “maximum” is right — it provides an upper bound on how long to wait before requesting a retransmission — but in another sense it’s wrong because the exponential increase is applied to it. I think the word “maximum” is trying to do too much work, and more words are probably required in order to make this clear. I also think the problem is exacerbated by the fact both §4.4 and §7.2 are talking normatively about how to use NON_RECEIVE_TIMEOUT. It seems as though the main description is found in §7.2, and some confusion would be avoided by making §4.4 less specific, and simply referring forward to §7.2.

And, as noted in my DISCUSS, example 10.2.3 muddies the waters still further since it illustrates yet another behavior.


7. Section 4.4

  The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2)
  after the last received payload for NON payloads before issuing a
  GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or
  more Q-Block2 Options that define the missing blocks with the M bit
  unset.  The client MAY set the M bit to request this and later blocks
  from this MAX_PAYLOADS set.  Further considerations related to the
  transmission timing for missing requests are discussed in
  Section 7.2.

I find this whole paragraph pretty confusing with the dueling SHOULD and MAY, where it appears the SHOULD might be doing two jobs at once. I *think* your intent is something like the following?

“The client SHOULD wait as specified in Section 7.2 for NON payloads 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-Block option(s) SHOULD be unset, although the M bit MAY be set to request this and later blocks from this MAX_PAYLOADS set, see Section 10.2.4 for an example of this in operation.”


8. Section 5

  If the size of the 4.08 (Request Entity Incomplete) response packet
  is larger than that defined by Section 4.6 [RFC7252], then the number
  of missing blocks MUST be limited so that the response can fit into a
  single packet.  If this is the case, then the server can send

Suggestion: “then the number of missing blocks reported MUST...” (The thing being limited is not the actual number of missing blocks. You’re limiting the number you report on.)


9. Section 7.1

  It is implementation specific as to whether there should be any
  further requests for missing data as there will have been significant
  transmission failure as individual payloads will have failed after
  MAX_TRANSMIT_SPAN.

This paragraph seems as though it’s a non-sequitur. It just doesn’t make sense to me. :-(


10. Section 7.2

(This comment relates to the difficulty explained in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

  NON_TIMEOUT is the maximum 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]).

Presumably the use of “maximum” means it’s fine to delay zero seconds (or any value lower than NON_TIMEOUT).


11. General

By the way, none of the timers specify jitter (and indeed, if read literally, jitter would be forbidden). Is this intentional?


12. Section 7.2

  If the CoAP peer reports at least one payload has not arrived for
  each body for at least a 24 hour period and it is known that there
  are no other network issues over that period, then the value of
  MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1) and
  the situation re-evaluated for another 24 hour period until there is
  no report of missing payloads under normal operating conditions.  The
  newly derived value for MAX_PAYLOADS should be used for both ends of
  this particular CoAP peer link.  Note that the CoAP peer will not
  know about the MAX_PAYLOADS change until it is reconfigured.  As a
  consequence of the two peers having different MAX_PAYLOADS values, a
  peer may continue indicate that 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.

I take it this is just thrown in here as an operational suggestion? It’s not specifying protocol, right? It seems a little misplaced, if so.


13. Section 10.1.3

(This comment relates to the aside in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

Why doesn’t the server request 1,9,10 in one go? Since its rxmt request is triggered by rx of 11, one would think it could infer 10 had been lost.

14. Section 10.1.4 (also 10.3.3)

(This comment relates to the aside in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

Why doesn’t reception of a message with More=0 trigger the server to request retransmission of the missing block? Why does it have to wait for timeout?

15. Section 10.2.3

(This comment relates to my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

Why doesn’t reception of QB2:10/0/1024 trigger the client to request retransmission? Why does it have to wait for timeout? Similarly reception of QB2:9/1/1024 later in the example.

16. Section 10.2.4

Since MAX_PAYLOADS is 10, why does the example say “MAX_PAYLOADS has been reached” after payloads 2-9 have been retransmitted? That’s only 8 payloads.

--
I do have a couple new comments raised during my review of the changes in version 12:

(draft-ietf-core-new-block-12)

17. Section 1:

  This document introduces the CoAP Q-Block1 and Q-Block2 Options which
  allow block-wise transfer to work with series of Non-confirmable
  messages, instead of lock-stepping using Confirmable messages
  (Section 3).  In other words, this document provides a missing piece
  of [RFC7959], namely the support of block-wise transfer using Non-
  confirmable where an entire body of data can be transmitted without
  the requirement for an acknowledgement (but recovery is available
  should it be needed).

As far as I can tell the spec does not really remove the requirement for acknowledgement, it just amortizes the acknowledgements by only sending them every MAX_PAYLOADS_SET. Response Code 2.31 is essentially an acknowledgement, and it gets sent that frequently, right? There’s also (if I recall correctly) some flavor of acknowledgement that is sent when the entire body has been transferred. So, I think the new paragraph isn’t accurate.

This observation also applies to this claimed benefit in §3:

  o  They support sending an entire body using NON messages without
    requiring an intermediate response from the peer.

Response Code 2.31 is exactly an intermediate response. I guess maybe your focus is that if the intermediate response isn’t received, transmission continues, albeit more slowly than it would otherwise, and unreliably too, so in that sense the responses aren’t “required”. I think this requires awfully close parsing of the word “required”, though.

18. Section 2:

  MAX_PAYLOADS_SET is the set of blocks identified by block numbers
  that, when divided by MAX_PAYLOADS, they have the same numeric

Remove “they”

  result.  For example, if MAX_PAYLOADS is set to '10', a
  MAX_PAYLOADS_SET could be blocks #0 to #9, #10 to #19, etc.
  Depending on the data size, the MAX_PAYLOADS_SET may not comprise all
  the MAX_PAYLOADS blocks.

I don’t understand the last sentence ("Depending on the data size, the MAX_PAYLOADS_SET may not comprise all the MAX_PAYLOADS blocks.”) Are you trying to say that if the body size isn’t evenly divisible by MAX_PAYLOADS then the final MAX_PAYLOADS_SET will have fewer than MAX_PAYLOADS blocks in it?

(I do think this change, to introduce the term MAX_PAYLOADS_SET, is generally helpful; thanks.)

[Ballot comment]
My initial comments have been resolved or partially resolved in version 12, see https://mailarchive.ietf.org/arch/msg/core/6geK8P9I0jZBPp9a5qSrQwQNhUo/. Note I've added two new ones at the end of the list.

(draft-ietf-core-new-block-11)

1. Section 3.2

  This mechanism is not intended for general CoAP usage, and any use
  outside the intended use case should be carefully weighed against the
  loss of interoperability with generic CoAP applications.

I’m curious: is the only reason the mechanism isn’t intended for general usage, the fact some implementations won’t support it? Or does it have other deficiencies that also make it unsuitable?


2. Section 4.1

  Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and
  iPATCH requests and their payload-bearing responses (2.01, 2.02,
  2.03, 2.04, and 2.05) (Section 5.5 of [RFC7252]).

I found the list of codes incomprehensible on first encountering it, since the concept of response codes hadn’t been introduced yet. I do understand that the document assumes familiarity with CoAP; nonetheless for basic clarity I think this should say “(response codes 2.01, 2.02…”. Additionally, the reference to RFC 7252 §5.5 doesn’t seem to be especially germane?

By the way, is 2.03 indeed a payload-bearing response? The only other place the spec touches on it is in §4.4, which says “the server could respond with a 2.03 (Valid) response with no payload”.


3. Section 4.1

  To indicate support for Q-Block2 responses, the CoAP client MUST
  include the Q-Block2 Option in a GET or similar request (FETCH, for
  example), the Q-Block2 Option in a PUT or similar request, or the
  Q-Block1 Option in a PUT or similar request so that the server knows
  that the client supports this Q-Block functionality should it need to
  send back a body that spans multiple payloads.  Otherwise, the server
  would use the Block2 Option (if supported) to send back a message
  body that is too large to fit into a single IP packet [RFC7959].

Is this paragraph really supposed to mention both Q-Block2 and Q-Block1? In particular, I’m confused by the mention of both of these in relation to PUT.


4. Section 4.1

  The Q-Block1 and Q-Block2 Options are unsafe to forward.  That is, a
  CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option
  MUST reject the request or response that uses either option.

Presumably (hopefully) this is simply describing the behavior of existing spec-compliant proxies when processing the new messages. As such, is the MUST appropriate? I would think not.


5. Section 4.3

      body.  Note that the last received payload may not be the one with
      the highest block number.

“Might not” would be less ambiguous than “may not”.


6. Section 4.4 (also two places in §4.3)

(This comment rehashes, in more detail, the difficulty explained in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

  The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2)

I read this as meaning the client should wait for as little as zero, or as long as NON_RECEIVE_TIMEOUT — that’s my understanding of “up to”. Is that the intended meaning? If it is, I think it’s worth writing out as I’ve done, for clarity. If it’s not, it definitely needs to be fixed.

There’s a similar issue with “up to NON_PARTIAL_TIMEOUT” later in the section.

Referring ahead to Section 7.2 muddies the waters further. Even though the text quoted above says NON_RECEIVE_TIMEOUT is an upper limit on how long to wait, §7.2 says it’s a lower limit instead... maybe? From §7.2:

  NON_RECEIVE_TIMEOUT is the initial maximum time to wait for a missing

“Maximum”, ok great, that means “upper bound” and so lines up with §4.4 although the “initial” is surprising since §4.4 doesn’t say anything about the upper limit increasing. It continues:

  payload before requesting retransmission for the first time.  Every
  time the missing payload is re-requested, the time to wait value
  doubles.  The time to wait is calculated as:

      Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count - 1))

But this part says it’s (a) an exact time-to-wait, not a “maximum”, and (b) it says it increases exponentially, so NON_RECEIVE_TIMEOUT isn’t a maximum at all, but a minimum.

This later text in §7.2 implies that perhaps the problem in the above passages is the word “maximum”, and it should simply be deleted:

  For the server receiving NON Q-Block1 requests, it SHOULD send back a
  2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS
  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). 

Similarly “up to” in the quote that began this comment should be “at least”.

Whether you adopt those suggestions or not,  it seems as though all this needs to be rewritten with careful attention to conveying what the desired behavior is.

But the plot thickens. Later in §7.2 we have

  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 the first
  payload from the new set of MAX_PAYLOADS payloads, the server SHOULD
  send a 4.08 (Request Entity Incomplete) Response Code indicating any
  missing payloads from any previous MAX_PAYLOADS payloads.

The point being that the retransmission request can be triggered by an event other than timer expiration. So in that sense, “maximum” is right — it provides an upper bound on how long to wait before requesting a retransmission — but in another sense it’s wrong because the exponential increase is applied to it. I think the word “maximum” is trying to do too much work, and more words are probably required in order to make this clear. I also think the problem is exacerbated by the fact both §4.4 and §7.2 are talking normatively about how to use NON_RECEIVE_TIMEOUT. It seems as though the main description is found in §7.2, and some confusion would be avoided by making §4.4 less specific, and simply referring forward to §7.2.

And, as noted in my DISCUSS, example 10.2.3 muddies the waters still further since it illustrates yet another behavior.


7. Section 4.4

  The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2)
  after the last received payload for NON payloads before issuing a
  GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or
  more Q-Block2 Options that define the missing blocks with the M bit
  unset.  The client MAY set the M bit to request this and later blocks
  from this MAX_PAYLOADS set.  Further considerations related to the
  transmission timing for missing requests are discussed in
  Section 7.2.

I find this whole paragraph pretty confusing with the dueling SHOULD and MAY, where it appears the SHOULD might be doing two jobs at once. I *think* your intent is something like the following?

“The client SHOULD wait as specified in Section 7.2 for NON payloads 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-Block option(s) SHOULD be unset, although the M bit MAY be set to request this and later blocks from this MAX_PAYLOADS set, see Section 10.2.4 for an example of this in operation.”


8. Section 5

  If the size of the 4.08 (Request Entity Incomplete) response packet
  is larger than that defined by Section 4.6 [RFC7252], then the number
  of missing blocks MUST be limited so that the response can fit into a
  single packet.  If this is the case, then the server can send

Suggestion: “then the number of missing blocks reported MUST...” (The thing being limited is not the actual number of missing blocks. You’re limiting the number you report on.)


9. Section 7.1

  It is implementation specific as to whether there should be any
  further requests for missing data as there will have been significant
  transmission failure as individual payloads will have failed after
  MAX_TRANSMIT_SPAN.

This paragraph seems as though it’s a non-sequitur. It just doesn’t make sense to me. :-(


10. Section 7.2

(This comment relates to the difficulty explained in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

  NON_TIMEOUT is the maximum 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]).

Presumably the use of “maximum” means it’s fine to delay zero seconds (or any value lower than NON_TIMEOUT).


11. General

By the way, none of the timers specify jitter (and indeed, if read literally, jitter would be forbidden). Is this intentional?


12. Section 7.2

  If the CoAP peer reports at least one payload has not arrived for
  each body for at least a 24 hour period and it is known that there
  are no other network issues over that period, then the value of
  MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1) and
  the situation re-evaluated for another 24 hour period until there is
  no report of missing payloads under normal operating conditions.  The
  newly derived value for MAX_PAYLOADS should be used for both ends of
  this particular CoAP peer link.  Note that the CoAP peer will not
  know about the MAX_PAYLOADS change until it is reconfigured.  As a
  consequence of the two peers having different MAX_PAYLOADS values, a
  peer may continue indicate that 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.

I take it this is just thrown in here as an operational suggestion? It’s not specifying protocol, right? It seems a little misplaced, if so.


13. Section 10.1.3

(This comment relates to the aside in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

Why doesn’t the server request 1,9,10 in one go? Since its rxmt request is triggered by rx of 11, one would think it could infer 10 had been lost.

14. Section 10.1.4 (also 10.3.3)

(This comment relates to the aside in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

Why doesn’t reception of a message with More=0 trigger the server to request retransmission of the missing block? Why does it have to wait for timeout?

15. Section 10.2.3

(This comment relates to my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

Why doesn’t reception of QB2:10/0/1024 trigger the client to request retransmission? Why does it have to wait for timeout? Similarly reception of QB2:9/1/1024 later in the example.

16. Section 10.2.4

Since MAX_PAYLOADS is 10, why does the example say “MAX_PAYLOADS has been reached” after payloads 2-9 have been retransmitted? That’s only 8 payloads.

--
I do have a couple new comments raised during my review of the changes in version 12:

(draft-ietf-core-new-block-12)

17. Section 1:

  This document introduces the CoAP Q-Block1 and Q-Block2 Options which
  allow block-wise transfer to work with series of Non-confirmable
  messages, instead of lock-stepping using Confirmable messages
  (Section 3).  In other words, this document provides a missing piece
  of [RFC7959], namely the support of block-wise transfer using Non-
  confirmable where an entire body of data can be transmitted without
  the requirement for an acknowledgement (but recovery is available
  should it be needed).

As far as I can tell the spec does not really remove the requirement for acknowledgement, it just amortizes the acknowledgements by only sending them every MAX_PAYLOADS_SET. Response Code 2.31 is essentially an acknowledgement, and it gets sent that frequently, right? There’s also (if I recall correctly) some flavor of acknowledgement that is sent when the entire body has been transferred. So, I think the new paragraph isn’t accurate.

This observation also applies to this claimed benefit in §3:

  o  They support sending an entire body using NON messages without
    requiring an intermediate response from the peer.

Response Code 2.31 is exactly an intermediate response. I guess maybe your focus is that if the intermediate response isn’t received, transmission continues, albeit more slowly than it would otherwise, and unreliably too, so in that sense the responses aren’t “required”. I think this requires awfully close parsing of the word “required”, though.

18. Section 2:

  MAX_PAYLOADS_SET is the set of blocks identified by block numbers
  that, when divided by MAX_PAYLOADS, they have the same numeric

Remove “they”

  result.  For example, if MAX_PAYLOADS is set to '10', a
  MAX_PAYLOADS_SET could be blocks #0 to #9, #10 to #19, etc.
  Depending on the data size, the MAX_PAYLOADS_SET may not comprise all
  the MAX_PAYLOADS blocks.

I don’t understand the last sentence ("Depending on the data size, the MAX_PAYLOADS_SET may not comprise all the MAX_PAYLOADS blocks.”) Are you trying to say that if the body size isn’t evenly divisible by MAX_PAYLOADS then the final MAX_PAYLOADS_SET will have fewer than MAX_PAYLOADS blocks in it?

(I do think this change, to introduce the term MAX_PAYLOADS_SET, is generally helpful; thanks.)

[Ballot discuss]
I am raising my comment #11 to a DISCUSS.

I notice that RFC 7252 jitters its timers, for example:

  counter.  For a new Confirmable message, the initial timeout is set
  to a random duration (often not an integral number of seconds)
  between ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FACTOR) (see
  Section 4.8)
…
  ACK_RANDOM_FACTOR MUST NOT be decreased below 1.0, and it SHOULD have
  a value that is sufficiently different from 1.0 to provide some
  protection from synchronization effects.

MAX_TRANSMIT_SPAN and MAX_TRANSMIT_WAIT are similarly jittered. A number of your introduced parameters

  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).

appear at least superficially similar to the timers the authors of RFC 7252 deemed important to jitter to prevent synchronization effects. Did you specifically consider jittering them, and decide that jitter was unnecessary? If so, can you explain what is different about your specification, compared to the base spec, that eliminates the concern?

--
Version 12 resolves the concerns in the DISCUSS point below; I am retaining it for posterity only:

For the most part I found this document relatively easy to follow, considering my complete lack of background in CoAP. However, despite a concerted effort I have not been able to nail down with confidence what the intended semantics of several of your timeouts are, notably NON_RECEIVE_TIMEOUT. Some of the text (for example, §4.4) implies that the timeout is an upper bound on how long an implementation should wait before declaring a block to have been lost (“The client SHOULD wait for up to NON_RECEIVE_TIMEOUT”). At the very least, this is imprecise because the timeout increases exponentially with repeated timeouts — but this is a relatively minor matter, discussed further in my comments.

Later, in §7.2, you say that expiry of the timeout is not the only trigger for a 4.08 response:

  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 the first
  payload from the new set of MAX_PAYLOADS payloads, the server SHOULD
  send a 4.08 (Request Entity Incomplete) Response Code indicating any
  missing payloads from any previous MAX_PAYLOADS payloads.

It makes sense to me that you use this additional trigger. At this point in my reading of the spec, my understanding of the retransmission algorithm was that a 4.08 should be sent when either a payload is received from a new set of MAX_PAYLOADS, or NON_RECEIVE_TIMEOUT expires. But then I got to the example in 10.2.3, which shows the client waiting for the expiration of NON_RECEIVE_TIMEOUT even though it has received the first of a new set of MAX_PAYLOADS, and I concluded that either I’ve missed something basic, or the document is internally inconsistent.

As an aside, I’m also unclear as to why the only trigger you specify for sending a 4.08 is the arrival of the first of a new MAX_PAYLOADS flight. Other possible triggers I noticed include a gap in the sequence, and reception of a payload with More=0.

Some of these issues are repeated in my comments, below — I’ve noted those in the comment. Possibly in addressing this DISCUSS we’ll clear up some of those comments too.

[Ballot comment]
Comments:

(draft-ietf-core-new-block-11)

1. Section 3.2

  This mechanism is not intended for general CoAP usage, and any use
  outside the intended use case should be carefully weighed against the
  loss of interoperability with generic CoAP applications.

I’m curious: is the only reason the mechanism isn’t intended for general usage, the fact some implementations won’t support it? Or does it have other deficiencies that also make it unsuitable?


2. Section 4.1

  Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and
  iPATCH requests and their payload-bearing responses (2.01, 2.02,
  2.03, 2.04, and 2.05) (Section 5.5 of [RFC7252]).

I found the list of codes incomprehensible on first encountering it, since the concept of response codes hadn’t been introduced yet. I do understand that the document assumes familiarity with CoAP; nonetheless for basic clarity I think this should say “(response codes 2.01, 2.02…”. Additionally, the reference to RFC 7252 §5.5 doesn’t seem to be especially germane?

By the way, is 2.03 indeed a payload-bearing response? The only other place the spec touches on it is in §4.4, which says “the server could respond with a 2.03 (Valid) response with no payload”.


3. Section 4.1

  To indicate support for Q-Block2 responses, the CoAP client MUST
  include the Q-Block2 Option in a GET or similar request (FETCH, for
  example), the Q-Block2 Option in a PUT or similar request, or the
  Q-Block1 Option in a PUT or similar request so that the server knows
  that the client supports this Q-Block functionality should it need to
  send back a body that spans multiple payloads.  Otherwise, the server
  would use the Block2 Option (if supported) to send back a message
  body that is too large to fit into a single IP packet [RFC7959].

Is this paragraph really supposed to mention both Q-Block2 and Q-Block1? In particular, I’m confused by the mention of both of these in relation to PUT.


4. Section 4.1

  The Q-Block1 and Q-Block2 Options are unsafe to forward.  That is, a
  CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option
  MUST reject the request or response that uses either option.

Presumably (hopefully) this is simply describing the behavior of existing spec-compliant proxies when processing the new messages. As such, is the MUST appropriate? I would think not.


5. Section 4.3

      body.  Note that the last received payload may not be the one with
      the highest block number.

“Might not” would be less ambiguous than “may not”.


6. Section 4.4 (also two places in §4.3)

(This comment rehashes, in more detail, the difficulty explained in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

  The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2)

I read this as meaning the client should wait for as little as zero, or as long as NON_RECEIVE_TIMEOUT — that’s my understanding of “up to”. Is that the intended meaning? If it is, I think it’s worth writing out as I’ve done, for clarity. If it’s not, it definitely needs to be fixed.

There’s a similar issue with “up to NON_PARTIAL_TIMEOUT” later in the section.

Referring ahead to Section 7.2 muddies the waters further. Even though the text quoted above says NON_RECEIVE_TIMEOUT is an upper limit on how long to wait, §7.2 says it’s a lower limit instead... maybe? From §7.2:

  NON_RECEIVE_TIMEOUT is the initial maximum time to wait for a missing

“Maximum”, ok great, that means “upper bound” and so lines up with §4.4 although the “initial” is surprising since §4.4 doesn’t say anything about the upper limit increasing. It continues:

  payload before requesting retransmission for the first time.  Every
  time the missing payload is re-requested, the time to wait value
  doubles.  The time to wait is calculated as:

      Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count - 1))

But this part says it’s (a) an exact time-to-wait, not a “maximum”, and (b) it says it increases exponentially, so NON_RECEIVE_TIMEOUT isn’t a maximum at all, but a minimum.

This later text in §7.2 implies that perhaps the problem in the above passages is the word “maximum”, and it should simply be deleted:

  For the server receiving NON Q-Block1 requests, it SHOULD send back a
  2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS
  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). 

Similarly “up to” in the quote that began this comment should be “at least”.

Whether you adopt those suggestions or not,  it seems as though all this needs to be rewritten with careful attention to conveying what the desired behavior is.

But the plot thickens. Later in §7.2 we have

  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 the first
  payload from the new set of MAX_PAYLOADS payloads, the server SHOULD
  send a 4.08 (Request Entity Incomplete) Response Code indicating any
  missing payloads from any previous MAX_PAYLOADS payloads.

The point being that the retransmission request can be triggered by an event other than timer expiration. So in that sense, “maximum” is right — it provides an upper bound on how long to wait before requesting a retransmission — but in another sense it’s wrong because the exponential increase is applied to it. I think the word “maximum” is trying to do too much work, and more words are probably required in order to make this clear. I also think the problem is exacerbated by the fact both §4.4 and §7.2 are talking normatively about how to use NON_RECEIVE_TIMEOUT. It seems as though the main description is found in §7.2, and some confusion would be avoided by making §4.4 less specific, and simply referring forward to §7.2.

And, as noted in my DISCUSS, example 10.2.3 muddies the waters still further since it illustrates yet another behavior.


7. Section 4.4

  The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2)
  after the last received payload for NON payloads before issuing a
  GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or
  more Q-Block2 Options that define the missing blocks with the M bit
  unset.  The client MAY set the M bit to request this and later blocks
  from this MAX_PAYLOADS set.  Further considerations related to the
  transmission timing for missing requests are discussed in
  Section 7.2.

I find this whole paragraph pretty confusing with the dueling SHOULD and MAY, where it appears the SHOULD might be doing two jobs at once. I *think* your intent is something like the following?

“The client SHOULD wait as specified in Section 7.2 for NON payloads 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-Block option(s) SHOULD be unset, although the M bit MAY be set to request this and later blocks from this MAX_PAYLOADS set, see Section 10.2.4 for an example of this in operation.”


8. Section 5

  If the size of the 4.08 (Request Entity Incomplete) response packet
  is larger than that defined by Section 4.6 [RFC7252], then the number
  of missing blocks MUST be limited so that the response can fit into a
  single packet.  If this is the case, then the server can send

Suggestion: “then the number of missing blocks reported MUST...” (The thing being limited is not the actual number of missing blocks. You’re limiting the number you report on.)


9. Section 7.1

  It is implementation specific as to whether there should be any
  further requests for missing data as there will have been significant
  transmission failure as individual payloads will have failed after
  MAX_TRANSMIT_SPAN.

This paragraph seems as though it’s a non-sequitur. It just doesn’t make sense to me. :-(


10. Section 7.2

(This comment relates to the difficulty explained in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

  NON_TIMEOUT is the maximum 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]).

Presumably the use of “maximum” means it’s fine to delay zero seconds (or any value lower than NON_TIMEOUT).


11. General

By the way, none of the timers specify jitter (and indeed, if read literally, jitter would be forbidden). Is this intentional?


12. Section 7.2

  If the CoAP peer reports at least one payload has not arrived for
  each body for at least a 24 hour period and it is known that there
  are no other network issues over that period, then the value of
  MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1) and
  the situation re-evaluated for another 24 hour period until there is
  no report of missing payloads under normal operating conditions.  The
  newly derived value for MAX_PAYLOADS should be used for both ends of
  this particular CoAP peer link.  Note that the CoAP peer will not
  know about the MAX_PAYLOADS change until it is reconfigured.  As a
  consequence of the two peers having different MAX_PAYLOADS values, a
  peer may continue indicate that 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.

I take it this is just thrown in here as an operational suggestion? It’s not specifying protocol, right? It seems a little misplaced, if so.


13. Section 10.1.3

(This comment relates to the aside in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

Why doesn’t the server request 1,9,10 in one go? Since its rxmt request is triggered by rx of 11, one would think it could infer 10 had been lost.

14. Section 10.1.4 (also 10.3.3)

(This comment relates to the aside in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

Why doesn’t reception of a message with More=0 trigger the server to request retransmission of the missing block? Why does it have to wait for timeout?

15. Section 10.2.3

(This comment relates to my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

Why doesn’t reception of QB2:10/0/1024 trigger the client to request retransmission? Why does it have to wait for timeout? Similarly reception of QB2:9/1/1024 later in the example.

16. Section 10.2.4

Since MAX_PAYLOADS is 10, why does the example say “MAX_PAYLOADS has been reached” after payloads 2-9 have been retransmitted? That’s only 8 payloads.

--

The comments above have been resolved or partially resolved in version 12, see https://mailarchive.ietf.org/arch/msg/core/6geK8P9I0jZBPp9a5qSrQwQNhUo/. I do have a couple new comments raised during my review of the changes in version 12:

17. Section 1:

  This document introduces the CoAP Q-Block1 and Q-Block2 Options which
  allow block-wise transfer to work with series of Non-confirmable
  messages, instead of lock-stepping using Confirmable messages
  (Section 3).  In other words, this document provides a missing piece
  of [RFC7959], namely the support of block-wise transfer using Non-
  confirmable where an entire body of data can be transmitted without
  the requirement for an acknowledgement (but recovery is available
  should it be needed).

As far as I can tell the spec does not really remove the requirement for acknowledgement, it just amortizes the acknowledgements by only sending them every MAX_PAYLOADS_SET. Response Code 2.31 is essentially an acknowledgement, and it gets sent that frequently, right? There’s also (if I recall correctly) some flavor of acknowledgement that is sent when the entire body has been transferred. So, I think the new paragraph isn’t accurate.

This observation also applies to this claimed benefit in §3:

  o  They support sending an entire body using NON messages without
    requiring an intermediate response from the peer.

Response Code 2.31 is exactly an intermediate response. I guess maybe your focus is that if the intermediate response isn’t received, transmission continues, albeit more slowly than it would otherwise, and unreliably too, so in that sense the responses aren’t “required”. I think this requires awfully close parsing of the word “required”, though.

18. Section 2:

  MAX_PAYLOADS_SET is the set of blocks identified by block numbers
  that, when divided by MAX_PAYLOADS, they have the same numeric

Remove “they”

  result.  For example, if MAX_PAYLOADS is set to '10', a
  MAX_PAYLOADS_SET could be blocks #0 to #9, #10 to #19, etc.
  Depending on the data size, the MAX_PAYLOADS_SET may not comprise all
  the MAX_PAYLOADS blocks.

I don’t understand the last sentence ("Depending on the data size, the MAX_PAYLOADS_SET may not comprise all the MAX_PAYLOADS blocks.”) Are you trying to say that if the body size isn’t evenly divisible by MAX_PAYLOADS then the final MAX_PAYLOADS_SET will have fewer than MAX_PAYLOADS blocks in it?

(I do think this change, to introduce the term MAX_PAYLOADS_SET, is generally helpful; thanks.)

### Summary

Document Shepherd: Marco Tiloca
Area Director: Francesca Palombini

The document defines two new options for the Constrained Application Protocol (CoAP), namely Q-Block1 and Q-Block2. The two options enable effective block-wise transfers of large data payload, also under network conditions where asymmetrical transient packet loss may be experienced.

The main use case addressed by this document is a network under Distributed Denial of Service (DDoS) attack, where DDoS mitigation agents are still required to exchange large amount of data using CoAP. This use case is especially targeted in the DOTS Working Group, where the use of the two new options is suggested in its DOTS Telemetry, see https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/

Compared to the similar options Block1 and Block2 defined in RFC 7959 --- which are based on synchronous, lock-step exchanges of blocks, and thus can be ineffective or even prohibitive to use under a DDoS situation --- the new options enable faster transmission rates with less packet interchanges, as well as faster recovery of lost blocks.

The document also defines congestion control procedures to be used when the Q-Block1 and Q-Block2 Options are used over an unreliable transport.

The document is intended for Standards Track.

Version -11 addressed a Last Call review from GenART.

Version -12 addressed a Last Call review from TSVART, a Telechat review from IOTDIR, as well as a number of reviews from the IESG.

Supplementary material about testing/evaluation methodology and reports from DOTS interops has also been provided at https://github.com/core-wg/new-block/blob/master/testing%20methodology.md

### Review and Consensus

The document has been discussed on multiple IETF meetings and CoRE interim meetings, and has gone through multiple expert reviews.

During and after Working Group Last Call, effort was also put in better reflecting how design choices align with the intended scope of the document, i.e. to serve especially use cases with asymmetrical transient packet loss and particularly the DOTS Telemetry, see https://datatracker.ietf.org/doc/html/rfc8782  and  https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/

Consensus has been reached on the scope, content and level of detail of the document.

### Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

### Other Points

The document registers:

* Two new option numbers in the "CoAP Option Numbers" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry.
* One new Media-Type in the "Media Types" registry.
* One new related CoAP Content-Format in the "CoAP Content-Formats" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry.

A Pull-Request of an author's implementation to "libcoap" is available at https://github.com/obgm/libcoap/pull/611

Feedback from the implementation activity has contributed to the design and refinement of specific aspects, notably:

- Limiting new mechanics for congestion control only to CoAP Non-Confirmable messages.
- Not mixing CoAP Confirmable and Non-Confirmable messages for a same request/response body.
- The 'Continue' indication of successfully received blocks.
- The discovery of server support for the Q-Block1 and Q-Block2 Options.
- Further lessons learned highlighted as "Implementation note" in the document.

### Checklist

- [X] Does the shepherd stand behind the document and think the document is ready for publication?
- [X] Is the correct RFC type indicated in the title page header?
- [X] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
- [X] Is the intent of the document accurately and adequately explained in the introduction?
- [X] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
- [X] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?

- [X] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
- [X] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
- [X] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
- [X] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
'Does not apply'
- [X] If this is a "bis" document, have all of the errata been considered?
'Does not apply'

**IANA** Considerations:

- [X] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
- [X] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
- [X] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
- [X] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
- [X] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
- [X] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
'Does not apply'
- [X]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?
'Does not apply'

[Ballot discuss]
[Updating this DISCUSS based on the discussion during the May 6 telechat.]

Section 1, paragraph 4, discuss:
>    There is a requirement for these blocks of data to be transmitted at
>    higher rates under network conditions where there may be asymmetrical
>    transient packet loss (i.e., responses may get dropped).  An example
>    is when a network is subject to a Distributed Denial of Service
>    (DDoS) attack and there is a need for DDoS mitigation agents relying
>    upon CoAP to communicate with each other (e.g.,
>    [RFC8782][I-D.ietf-dots-telemetry]).  As a reminder, [RFC7959]

I understand that COAP was initially chosen to transport DOTS signaling messages
due to their small size, support for structured messages and request/response
semantics, as well as the ability to function over lossy paths such as found in
IoT deployment, which COAP is architected for.

DOTS now seems to desire to transport larger messages, and this document extends
CORE to enable this functionality. However, this CORE extension seems to solely
focus on Internet deployment scenarios, essentially attempting to re-architect
COAP into a general Internet transport protocol for transmission over paths with
high loss rates. It's questionable whether "maintenance of RFC7959" part of the
current CORE charter covers this document.

The motivation for this new extension is apparently that RFC7959 doesn't result
in sufficient performance for the DOTS use case, i.e., timely delivery of larger
amounts of data during periods of high random loss (i.e., under DDoS). This
is a fundamentally hard problem, because in order to deliver data in a timely
manner in such scenarios, the sender needs to be very aggressive, to send enough
packets into the network so that enough arrive at the receiver to make steady
progress; and at the same time the feedback channel is also severely degraded
due to loss.

The IETF TSV area currently has hence no known good solution for such use cases.
This specification possibly describes such a solution, but I was not able to find
any evaluation results that would show that this proposed mechanism actually
delivers the desired performance improvements over RFC7959 in the scenarios
of interest. I was also not able to find any evaluation results of whether the
proposed mechanism is safe to use in situations that might be easily confused
with DDoS, such as high-load scenarios that are not of malicious origin, or if it even
is safe when executing over normal Internet paths.

If such evaluation results exists, would you mind pointing me at them?

Without evaluation results that demonstrate that the proposed mechanism
is effective and safe, I do not believe it should be published on the Standards
Track. It could go forward as an Experimental RFC, supporting an experiment
to perform such an evaluation.

[Ballot comment]
I support Lars's discuss.

I am conflicted with how to ballot on this document, and I am also considering whether to abstain instead.

I appreciate the utility and problem that this is trying to address, but I'm concerned that this is pushing CoAP outside the IOT domain, and it seems to be very focused on solving a specific DOTs problem, and seems to make CoAP creep towards TCP.

I also note that the following paragraph seems to suggest that what is being done here is somewhat experimental in nature and could even be replaced in future. Hence I wonder whether publishing as an experimental RFC might be an alternative, although that does not really answer the question as to whether it is right to extend CoAP's block handling in this way.

  This mechanism is not intended for general CoAP usage, and any use
  outside the intended use case should be carefully weighed against the
  loss of interoperability with generic CoAP applications.  It is hoped
  that the experience gained with this mechanism can feed future
  extensions of the block-wise mechanism that will both be generally
  applicable and serve this particular use case.

Regards,
Rob

[Ballot comment]
I support Lars's discuss.

I am conflicted with how to ballot on this document - I was also considering whether to abstain.

I appreciate the utility and problem that this is trying to address, but I'm concerned that this is pushing CoAP outside the IOT domain, and it seems to be very focused on solving a specific DOTs problem, and seems to make CoAP creep towards TCP.

I also note that the following paragraph seems to suggest that what is being done here is somewhat experimental in nature and could even be replaced in future. Hence I wonder whether publishing as an experimental RFC might be an alternative, although that does not really answer the question as to whether it is right to extend CoAP's block handling in this way.

  This mechanism is not intended for general CoAP usage, and any use
  outside the intended use case should be carefully weighed against the
  loss of interoperability with generic CoAP applications.  It is hoped
  that the experience gained with this mechanism can feed future
  extensions of the block-wise mechanism that will both be generally
  applicable and serve this particular use case.

Regards,
Rob

[Ballot comment]
I support Ben's DISCUSS.

Nearly every SHOULD [NOT] in this document left me wondering "Why isn't this a MUST [NOT]?" or "Since this is a SHOULD, I have a choice, but it's not clear to me how I should make that choice."  I see Ben also tripped on at least one of these.

Nice work on the IANA Considerations section.

[Ballot discuss]
I have a concern about the MAX_PAYLOADS congestion-control parameter.
In Section 7.2 it is stated that both endpoints only SHOULD have the
same value.  I don't see how this can be anything less than MUST, given
that we attribute semantics to whether NUM modulo MAX_PAYLOADS is zero or
non-zero in the processing of the Q-Block2 option.  If the endpoints
disagree on the value of MAX_PAYLOADS they will disagree on the
semantics of Q-Block2 -- how can that be interoperable?
(Being able to negotiate the value does not seem inherently problematic,
but since it is relevant for protocol semantics it seems like the value
must be identical on both endpoints.)
This seems especially important to have clarity on given that the
current specification allows for MAX_PAYLOADS to be decreased at runtime
in response to congestion feedback over a 24-hour period, with no
synchronization between peers provided ("Note that the CoAP peer will
not know about the MAX_PAYLOADS change until it is reconfigured".)

[Ballot comment]
I made some editorial suggestions in a github pull request at
https://github.com/core-wg/new-block/pull/21 .  It seems that there are
now some merge conflicts; I cannot promise to have availability to try
to resolve them particularly quickly, but I can do so "eventually" if
needed.

Section 1

  There is a requirement for these blocks of data to be transmitted at
  higher rates under network conditions where there may be asymmetrical
  transient packet loss (i.e., responses may get dropped).  An example
  is when a network is subject to a Distributed Denial of Service
  (DDoS) attack and there is a need for DDoS mitigation agents relying
  upon CoAP to communicate with each other (e.g.,
  [RFC8782][I-D.ietf-dots-telemetry]).  As a reminder, [RFC7959]

I suppose the RFC Editor will do the right thing about referencing 8782
vs 8782bis ... and I am overdue in following up on the IETF LC results
for the latter :(

Section 2

We currently introduce the concept of MAX_PAYLOADs by implicit use in a
few places before it is actually given a proper definition.  I wonder if
mentioning here that it is used to group a batch of blocks would help
the reader.

Section 3

  o  They support sending an entire body using Non-confirmable (NON)
      messages without requiring a response from the peer.

I put this change in my github PR, but repeating here for visibility
since I am making an assumption: I propose adding "intermediate" for
"without requiring an intermediate response from the peer".  My
understanding is that a final message indicaing successful receiption is
still used (or a selective ack in case of loss), so the contrast to RFC
7959 is in the (lack of) need for intermediate responses for each block.

  o  Mixing of NON and CON during requests/responses using Q-Block is
      not supported.

There is perhaps subtle differences across "not supported", "forbidden",
and "not defined in this specification".  Do we perhaps actually mean
"forbidden"?

Section 3.2

  (DOTS) that cannot use CON responses to handle potential packet loss
  and that support application-specific mechanisms to assess whether
  the remote peer is able to handle the messages sent by a CoAP
  endpoint (e.g., DOTS heartbeats in Section 4.7 of [RFC8782]).

Can we get greater clarity on what "able to handle" is intended to mean?
I can't tell if it's anywhere between "the transport is able to deliver
message bodies" and "the software stack implements and enables a
particular feature".

Section 4.1

  When the Content-Format Option is present together with the Q-Block1
  or Q-Block2 Option, the option applies to the body not to the payload
  (i.e., it must be the same for all payloads of the same body).

Do we have a normative requirement somewhere that the recipient track
and compare the content-format values across blocks?  If not, should we?

  Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and
  iPATCH requests and their payload-bearing responses (2.01, 2.02,
  2.03, 2.04, and 2.05) (Section 5.5 of [RFC7252]).

Do we need an "e.g." in front of the list, to account for the potential
future registration of new payload-bearing response codes?

  If Q-Block1 Option is present in a request or Q-Block2 Option in a
  response (i.e., in that message to the payload of which it pertains),

Can we reword this parenthetical in a less convoluted way?  I'm not even
sure I'm parsing it properly.

  [RFC7252]).  To reliably get a rejection message, it is therefore
  REQUIRED that clients use a Confirmable message for determining
  support for Q-Block1 and Q-Block2 Options.

(I know that some other discussion happened on this mechanism, but I
forget if there are already plans to add a clarification that this is
only needed once per peer within a given set of exchanges.)

  The Q-Block2 Option is repeatable when requesting retransmission of
  missing blocks, but not otherwise.  Except that case, any request
  carrying multiple Q-Block1 (or Q-Block2) Options MUST be handled
  following the procedure specified in Section 5.4.5 of [RFC7252].

Since these are critical options, the referenced procedures involve
rejecting the message, right?  Is that important enough to note
directly?

  Note that if Q-Block1 or Q-Block2 Options are included in a packet as
  Inner options, Block1 or Block2 Options MUST NOT be included as Inner
  options.  Similarly there MUST NOT be a mix of Q-Block and Block for
  the Outer options.  [...]

(Hopefully a silly question, but do we make the analogous prohibition
against combining Q-Block and regular Block for non-OSCORE cases
anywhere?  I thought we did, but now I can't find it...)

Section 4.3

  being transferred.  The Request-Tag is opaque, the server still
  treats it as opaque but the client MUST ensure that it is unique for
  every different body of transmitted data.

(nit) the structure of this sentence seems off, to me.  I may just want
a comma after "server still treats it as opaque", but looking more
closely I might rewrite to more like "The Request-Tag is opaque to the
server, but the client MUST ensure that it is unique for every different
request body being transmitted".

      Implementation Note: 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 subsequently incremented by the
      client whenever a new body of data is being transmitted between
      peers.

In the vein of draft-gont-numeric-ids-sec-considerations, is the
increment necessarily 1 or can there be gaps?  Similarly, the risk of
information disclosure (via side channel) is reduced if the initial
random value is generated anew for each connection.  This is maybe
implied by the current text but could be stated more clearly.

  The client MUST send the payloads with the block numbers increasing,
  starting from zero, until the body is complete (subject to any
  congestion control (Section 7)).  Any missing payloads requested by
  the server must in addition be separately transmitted with increasing
  block numbers.

When I first read this, I thought that the block numbers of
retransmissions needed to continue to increase in the same sequence as
the original transmission, i.e., retransmitted blocks are assigned new
block numbers.  The examples do not bear this out (and it seems like it
would be complicated to specify clearly), so I suggest rephrasing to "in
order of increasing block number".

      If the FETCH request includes the Observe Option, then the server
      MUST use the same token as used for the initial response for
      returning any Observe triggered responses so that the client can
      match them up.

      The client should then release all of the tokens used for this
      body unless a resource is being observed.

If a resource is being observed, should the client release all the other
tokens (than the one used for the initial response)?

Also, is the "initial response" the first response for the blockwise
transfer (which might be a 2.31 or 4.08 for NON requests), or the first
one with response code 2.05?

  2.31 (Continue)

      This Response Code can be used to indicate that all of the blocks
      up to and including the Q-Block1 Option block NUM (all having the
      M bit set) have been successfully received.  The token used MUST
      be one of the tokens that were received in a request for this
      block-wise exchange.  However, it is desirable to provide the one
      used in the last received request.

Can the client release any tokens upon receipt of such a response?

  4.02 (Bad Option)

      This Response Code MUST be returned for a Confirmable request if
      the server does not support the Q-Block Options.  Note that a
      reset message must be sent in case of Non-confirmable request.

Reset only needs to be sent if the server is not ignoring the request
entirely, though, right?


%%%
The following few comments are interrelated:

      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 new 'M' bit is "as appropriate" for the new flight of messages, or
as was sent initially?  (The examples in §10.x suggest "as was sent
initially".)

      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.

The "value to use" here seems to be indicating the value to use in the
retransmitted request...

      The token used MUST be one of the tokens that were received in a
      request for this block-wise exchange.  However, it is desirable to
      provide the one used in the last received request.  See Section 5
      for further information.

... but here the "token used" seems to be indicating the token to be
used in constructing the response that has response code 4.08.

If my understanding is correct, we really should have more clarity on
which value is "used" for which message.

Additionally, in the last quoted paragraph we refer to Section 5 for
further information, which includes a SHOULD-level requirement to
"provide the [token] used in the last received request".  It is very
surprising to have the normative requirements for behavior split across
sections in this manner.  (Or was the intent that Section 5 also use the
"desirable" wording?)
%%%

Section 4.4

  The ETag is opaque, the client still treats it as opaque but the
  server MUST ensure that it is unique for every different body of
  transmitted data.

[analogous comment as for Request-Tag]

      Implementation Note: 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 subsequently incremented by the server
      whenever a new body of data is being transmitted between peers.

[analogous comment as for Request-Tag]

  The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2)
  after the last received payload for NON payloads before issuing a
  GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or
  more Q-Block2 Options that define the missing blocks with the M bit
  unset.  The client MAY set the M bit to request this and later blocks
  from this MAX_PAYLOADS set.  Further considerations related to the
  transmission timing for missing requests are discussed in
  Section 7.2.

Does the MAY grant permission to send with M bit set prior to
NON_RECEIVE_TIMEOUT, or just permission to send with M bit set in
addition to with M bit unset (but still after the timeout)?

  For Confirmable responses, the client continues to acknowledge each
  packet.  Typically, the server acknowledges the initial request using
  an ACK with the payload, and then sends the subsequent payloads as
  CON responses.  The server will detect failure to send a packet, but
  the client can issue, after a MAX_TRANSMIT_SPAN delay, a separate
  GET, POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as
  needed.

Starting out with "for confirmable responses" implies that we're going
to separately cover non-confirmable responses later, or at some point
transition to statements of general applicability (to both confirmable
and non-confirmable responses).  Where does that happen?

  A client SHOULD maintain a partial body (missing payloads) for up to
  NON_PARTIAL_TIMEOUT (Section 7.2) or as defined by the Max-Age Option
  (or its default of 60 seconds (Section 5.6.1 of [RFC7252])),
  whichever is the less.  On release of the partial body, the client
  should then release all of the tokens used for this body unless a
  resource is being observed.

[as above, can the client release any subset of tokens in the case of
observe?]

  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.

It's surprising to write that the client SHOULD but it is RECOMMENDED
that the server cache, when those two requirements keywords have an
equivalent strength per BCP 14.  Can't we used consistent terminology
for the same requirement level?

  If the server detects part way through a body transfer that the
  resource data has changed and the server is not maintaining a cached
  copy of the old data, then the transmission is terminated.  Any
  subsequent missing block requests MUST be responded to using the
  latest ETag and Size2 Option values with the updated data.

This sounds like the server starts responding "in the middle" of the new
representation, so the client would need to go back and re-request the
initial parts, possibly across multiple groups of MAX_PAYLOADS blocks.
It seems like this requirement for client behavior should be more
clearly documented somewhere.  We do go on to talk about the client
removing the stale partial body, but not about completing the new body.

Section 4.5

  For a response that uses Q-Block2, the Observe value MUST be the same
  for all the payloads of the same body.  This is different from Block2
  usage where the Observe value is only present in the first block
  (Section 3.4 of [RFC7959]).  This includes payloads transmitted
  following receipt of the 'Continue' Q-Block2 Option (Section 4.4) by
  the server.  If a missing payload is requested by a client, then both
  the request and response MUST NOT include the Observe Option.

(side note?) It seems very surprising to omit Observe from only
retransmitted payloads but keep it in all initial payload transmissions.

Section 4.6

  The Size1 or Size2 option values MUST exactly represent the size of
  the data on the body so that any missing data can easily be
  determined.

Is this MUST duplicating the behavior already specified by RFC 7959?

Section 5

  The data payload of the 4.08 (Request Entity Incomplete) response is
  encoded as a CBOR Sequence [RFC8742].  It comprises of one or more

I think we want some qualifying text that reaffirms that the behavior
being described is applicable only to the
application/missing-blocks+cbor-seq content-type case, possibly by
having the previous discussion state that "this section defines the
behavior and semantics for 4.08 responses using the new content-type."

  The Concise Data Definition Language [RFC8610] (and see Section 4.1
  [RFC8742]) for the data describing these missing blocks is as
  follows:

(Should we mention that this is only informational and that the prose
description is normative, in line with RFC 8610 being only an
informative reference?)

        ; A notional array, the elements of which are to be used
        ; in a CBOR Sequence:

(nit) Is there a reason to use a different wording than the referenced
example from RFC 8742?

Section 6

  Implementation Note:  By using 8-byte tokens, it is possible to
      easily minimize the number of tokens that have to be tracked by
      clients, by keeping the bottom 32 bits the same for the same body
      and the upper 32 bits containing the current body's request number
      (incrementing every request, including every re-transmit).  This
      allows the client to be alleviated from keeping all the per-
      request-state, e.g., in Section 3 of [RFC8974].

If we're going to introduce structure into a nominally opaque
identifier, we need to discuss the consequences of that in the security
considerations.  draft-gont-numeric-ids-sec-considerations has some
guidance in this regard.

Section 7.1

  Congestion control for CON requests and responses is specified in
  Section 4.7 of [RFC7252].  For faster transmission rates, NSTART will
  need to be increased from 1.  However, the other CON congestion
  control parameters will need to be tuned to cover this change.  [...]

I thought there had been some discussion in a different AD's ballot
thread on this text, but I can't find it now.  I'm happy to defer to the
previous discussion if I'm not just imagining it.
Anyways, I might suggest phrasing this as "if faster transmission rates
are needed, NSTART will need to be increased from 1".

  It is implementation specific as to whether there should be any
  further requests for missing data as there will have been significant
  transmission failure as individual payloads will have failed after
  MAX_TRANSMIT_SPAN.

(editorial) I don't think I can successfully parse this sentence.  There
may be a few missing words, and splitting into multiple sentences would
likely help as well.

Section 7.2

  NON_RECEIVE_TIMEOUT is the initial maximum time to wait for a missing
  payload before requesting retransmission for the first time.  Every
  time the missing payload is re-requested, the time to wait value
  doubles.  The time to wait is calculated as:

Thank you for being very clear about the exponential backoff procedure
:)

  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 this is a
  repeat for the 2.31 (Continue) response, the server SHOULD send a
  4.08 (Request Entity Incomplete) response detailing the missing
  payloads after the block number that would have been indicated in the
  2.31 (Continue).  [...]

I don't understand what "if this is a repeat for the 2.31 (Continue)
response" is intended to mean.

  The client does not need to acknowledge the receipt of the entire
  body.

Does that mean that the last group of response blocks will always be
retransmitted NON_MAX_RETRANSMIT times?

Section 10

            QB1: Q-Block1 Option values NUM/More/SZX
            QB2: Q-Block2 Option values NUM/More/SZX

What's depicted in the figure seems to be the actual block size, and not
the three-bit SZX value.

Section 10.1.3

Should we indicate somehow in Figure 6 that the 4.08 responses use the
new content-format?

Also, is there any value in indicating that there might be a race
between the client continuing to send the next set of payloads and the
initial 4.08 response?

Section 10.2.3

I don't understand why the NON_RECEIVE_TIMEOUT (client) triggers --
shouldn't the delivery of the 11th block indicate that the server thinks
it sent a full MAX_PAYLOADS group and thus a selective ACK, after
perhaps just a modest reordering delay?

Section 10.3.2

  [[MAX_PAYLOADS has been reached]]
      |    [[MAX_PAYLOADS blocks acknowledged by client using
      |      'Continue' Q-Block2]]
      +--------->| NON FETCH /path M:0x3b T:0xab QB2:10/1/1024
      |<---------+ NON 2.05 M:0x8b T:0xaa O:1334 ET=21 QB2:10/0/1024

Shouldn't the server switch to using T:0xab now?

      +--------->| NON FETCH /path M:0x3c T:0xac QB2:10/1/1024
      |<---------+ NON 2.05 M:0x96 T:0xaa O:1335 ET=22 QB2:10/0/1024

and 0xac here?

Section 10.3.3

          |<---------+ NON 2.05 M:0xa6 T:0xc6 ET=23 QB2:3/0/1024
          |  ...    |
      [[NON_RECEIVE_TIMEOUT (client) delay expires]]

Why does the client time out here (at least with the full
NON_RECEIVE_TIMEOUT); the final-message indication seems like it would
allow for an ~immediate response (delayed only for some reordering
threshold)?

[Ballot discuss]
For the most part I found this document relatively easy to follow, considering my complete lack of background in CoAP. However, despite a concerted effort I have not been able to nail down with confidence what the intended semantics of several of your timeouts are, notably NON_RECEIVE_TIMEOUT. Some of the text (for example, §4.4) implies that the timeout is an upper bound on how long an implementation should wait before declaring a block to have been lost (“The client SHOULD wait for up to NON_RECEIVE_TIMEOUT”). At the very least, this is imprecise because the timeout increases exponentially with repeated timeouts — but this is a relatively minor matter, discussed further in my comments.

Later, in §7.2, you say that expiry of the timeout is not the only trigger for a 4.08 response:

  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 the first
  payload from the new set of MAX_PAYLOADS payloads, the server SHOULD
  send a 4.08 (Request Entity Incomplete) Response Code indicating any
  missing payloads from any previous MAX_PAYLOADS payloads.

It makes sense to me that you use this additional trigger. At this point in my reading of the spec, my understanding of the retransmission algorithm was that a 4.08 should be sent when either a payload is received from a new set of MAX_PAYLOADS, or NON_RECEIVE_TIMEOUT expires. But then I got to the example in 10.2.3, which shows the client waiting for the expiration of NON_RECEIVE_TIMEOUT even though it has received the first of a new set of MAX_PAYLOADS, and I concluded that either I’ve missed something basic, or the document is internally inconsistent.

As an aside, I’m also unclear as to why the only trigger you specify for sending a 4.08 is the arrival of the first of a new MAX_PAYLOADS flight. Other possible triggers I noticed include a gap in the sequence, and reception of a payload with More=0.

Some of these issues are repeated in my comments, below — I’ve noted those in the comment. Possibly in addressing this DISCUSS we’ll clear up some of those comments too.

[Ballot comment]
Comments:

(draft-ietf-core-new-block-11)

1. Section 3.2

  This mechanism is not intended for general CoAP usage, and any use
  outside the intended use case should be carefully weighed against the
  loss of interoperability with generic CoAP applications.

I’m curious: is the only reason the mechanism isn’t intended for general usage, the fact some implementations won’t support it? Or does it have other deficiencies that also make it unsuitable?


2. Section 4.1

  Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and
  iPATCH requests and their payload-bearing responses (2.01, 2.02,
  2.03, 2.04, and 2.05) (Section 5.5 of [RFC7252]).

I found the list of codes incomprehensible on first encountering it, since the concept of response codes hadn’t been introduced yet. I do understand that the document assumes familiarity with CoAP; nonetheless for basic clarity I think this should say “(response codes 2.01, 2.02…”. Additionally, the reference to RFC 7252 §5.5 doesn’t seem to be especially germane?

By the way, is 2.03 indeed a payload-bearing response? The only other place the spec touches on it is in §4.4, which says “the server could respond with a 2.03 (Valid) response with no payload”.


3. Section 4.1

  To indicate support for Q-Block2 responses, the CoAP client MUST
  include the Q-Block2 Option in a GET or similar request (FETCH, for
  example), the Q-Block2 Option in a PUT or similar request, or the
  Q-Block1 Option in a PUT or similar request so that the server knows
  that the client supports this Q-Block functionality should it need to
  send back a body that spans multiple payloads.  Otherwise, the server
  would use the Block2 Option (if supported) to send back a message
  body that is too large to fit into a single IP packet [RFC7959].

Is this paragraph really supposed to mention both Q-Block2 and Q-Block1? In particular, I’m confused by the mention of both of these in relation to PUT.


4. Section 4.1

  The Q-Block1 and Q-Block2 Options are unsafe to forward.  That is, a
  CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option
  MUST reject the request or response that uses either option.

Presumably (hopefully) this is simply describing the behavior of existing spec-compliant proxies when processing the new messages. As such, is the MUST appropriate? I would think not.


5. Section 4.3

      body.  Note that the last received payload may not be the one with
      the highest block number.

“Might not” would be less ambiguous than “may not”.


6. Section 4.4 (also two places in §4.3)

(This comment rehashes, in more detail, the difficulty explained in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

  The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2)

I read this as meaning the client should wait for as little as zero, or as long as NON_RECEIVE_TIMEOUT — that’s my understanding of “up to”. Is that the intended meaning? If it is, I think it’s worth writing out as I’ve done, for clarity. If it’s not, it definitely needs to be fixed.

There’s a similar issue with “up to NON_PARTIAL_TIMEOUT” later in the section.

Referring ahead to Section 7.2 muddies the waters further. Even though the text quoted above says NON_RECEIVE_TIMEOUT is an upper limit on how long to wait, §7.2 says it’s a lower limit instead... maybe? From §7.2:

  NON_RECEIVE_TIMEOUT is the initial maximum time to wait for a missing

“Maximum”, ok great, that means “upper bound” and so lines up with §4.4 although the “initial” is surprising since §4.4 doesn’t say anything about the upper limit increasing. It continues:

  payload before requesting retransmission for the first time.  Every
  time the missing payload is re-requested, the time to wait value
  doubles.  The time to wait is calculated as:

      Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count - 1))

But this part says it’s (a) an exact time-to-wait, not a “maximum”, and (b) it says it increases exponentially, so NON_RECEIVE_TIMEOUT isn’t a maximum at all, but a minimum.

This later text in §7.2 implies that perhaps the problem in the above passages is the word “maximum”, and it should simply be deleted:

  For the server receiving NON Q-Block1 requests, it SHOULD send back a
  2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS
  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). 

Similarly “up to” in the quote that began this comment should be “at least”.

Whether you adopt those suggestions or not,  it seems as though all this needs to be rewritten with careful attention to conveying what the desired behavior is.

But the plot thickens. Later in §7.2 we have

  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 the first
  payload from the new set of MAX_PAYLOADS payloads, the server SHOULD
  send a 4.08 (Request Entity Incomplete) Response Code indicating any
  missing payloads from any previous MAX_PAYLOADS payloads.

The point being that the retransmission request can be triggered by an event other than timer expiration. So in that sense, “maximum” is right — it provides an upper bound on how long to wait before requesting a retransmission — but in another sense it’s wrong because the exponential increase is applied to it. I think the word “maximum” is trying to do too much work, and more words are probably required in order to make this clear. I also think the problem is exacerbated by the fact both §4.4 and §7.2 are talking normatively about how to use NON_RECEIVE_TIMEOUT. It seems as though the main description is found in §7.2, and some confusion would be avoided by making §4.4 less specific, and simply referring forward to §7.2.

And, as noted in my DISCUSS, example 10.2.3 muddies the waters still further since it illustrates yet another behavior.


7. Section 4.4

  The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2)
  after the last received payload for NON payloads before issuing a
  GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or
  more Q-Block2 Options that define the missing blocks with the M bit
  unset.  The client MAY set the M bit to request this and later blocks
  from this MAX_PAYLOADS set.  Further considerations related to the
  transmission timing for missing requests are discussed in
  Section 7.2.

I find this whole paragraph pretty confusing with the dueling SHOULD and MAY, where it appears the SHOULD might be doing two jobs at once. I *think* your intent is something like the following?

“The client SHOULD wait as specified in Section 7.2 for NON payloads 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-Block option(s) SHOULD be unset, although the M bit MAY be set to request this and later blocks from this MAX_PAYLOADS set, see Section 10.2.4 for an example of this in operation.”


8. Section 5

  If the size of the 4.08 (Request Entity Incomplete) response packet
  is larger than that defined by Section 4.6 [RFC7252], then the number
  of missing blocks MUST be limited so that the response can fit into a
  single packet.  If this is the case, then the server can send

Suggestion: “then the number of missing blocks reported MUST...” (The thing being limited is not the actual number of missing blocks. You’re limiting the number you report on.)


9. Section 7.1

  It is implementation specific as to whether there should be any
  further requests for missing data as there will have been significant
  transmission failure as individual payloads will have failed after
  MAX_TRANSMIT_SPAN.

This paragraph seems as though it’s a non-sequitur. It just doesn’t make sense to me. :-(


10. Section 7.2

(This comment relates to the difficulty explained in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

  NON_TIMEOUT is the maximum 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]).

Presumably the use of “maximum” means it’s fine to delay zero seconds (or any value lower than NON_TIMEOUT).


11. General

By the way, none of the timers specify jitter (and indeed, if read literally, jitter would be forbidden). Is this intentional?


12. Section 7.2

  If the CoAP peer reports at least one payload has not arrived for
  each body for at least a 24 hour period and it is known that there
  are no other network issues over that period, then the value of
  MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1) and
  the situation re-evaluated for another 24 hour period until there is
  no report of missing payloads under normal operating conditions.  The
  newly derived value for MAX_PAYLOADS should be used for both ends of
  this particular CoAP peer link.  Note that the CoAP peer will not
  know about the MAX_PAYLOADS change until it is reconfigured.  As a
  consequence of the two peers having different MAX_PAYLOADS values, a
  peer may continue indicate that 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.

I take it this is just thrown in here as an operational suggestion? It’s not specifying protocol, right? It seems a little misplaced, if so.


13. Section 10.1.3

(This comment relates to the aside in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

Why doesn’t the server request 1,9,10 in one go? Since its rxmt request is triggered by rx of 11, one would think it could infer 10 had been lost.

14. Section 10.1.4 (also 10.3.3)

(This comment relates to the aside in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

Why doesn’t reception of a message with More=0 trigger the server to request retransmission of the missing block? Why does it have to wait for timeout?

15. Section 10.2.3

(This comment relates to my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.)

Why doesn’t reception of QB2:10/0/1024 trigger the client to request retransmission? Why does it have to wait for timeout? Similarly reception of QB2:9/1/1024 later in the example.

16. Section 10.2.4

Since MAX_PAYLOADS is 10, why does the example say “MAX_PAYLOADS has been reached” after payloads 2-9 have been retransmitted? That’s only 8 payloads.

[Ballot comment]
** Section 3.2 and Section 11
(a) Section 3.2. It is not recommended that these options are used in a NoSec security mode

(b) Section 11. It is NOT RECOMMENDED that the NoSec security mode is
  used if the Q-Block1 and Q-Block2 Options are to be used.

I believe that the intend of (a) and (b) is to caution against using NoSec mode with either Q-Block1 or 2.  One read of (b) would be that this guidance is only about when both options are used together (e.g., the language of Section 4.7).  I recommend restating (b) to be more along the lines of:

Therefore, it is NOT RECOMMENDED to use the NoSec security mode if either the Q-Block1 or Q-Block2 Options is used.

** Section 4.1.  Colloquialism. s/local configuration knob/local configuration option/

** Section 4.4.

(a)  If the server detects part way through a body transfer that the
  resource data has changed and the server is not maintaining a cached
  copy of the old data, then the transmission is terminated.  Any
  subsequent missing block requests MUST be responded to using the
  latest ETag and Size2 Option values with the updated data.

...

(b) If the server transmits a new body of data (e.g., a triggered Observe
  notification) with a new ETag to the same client as an additional
  response, the client should remove any partially received body held
  for a previous ETag for that resource as it is unlikely the missing
  blocks can be retrieved.

(1) Is (a) suggesting that the missing block requests would be serviced from a copy of the “resource data that has changed”?  This would mean that the client would get an inconsistent version of the resource which is neither the old or new version.

(2) (b) seems like it is noting that the partially received body should in fact be discarded to avoid the situation in (1).  However, how does the client get the initial, now discarded blocks?  I’m not sure where that transmission shouldn’t fail with an error as I don’t follow how recover is possible.

[Ballot comment]
Thanks for addressing my DISCUSS.

Thank you for the examples. They were useful in providing an overview of the protocol.

Thanks also to Colin Perkins for an especially thoughtful TSVART review. Please address his comments, although his concerns about (7.1) are IMO mostly subsumed by my DISCUSS.

- It would be useful to introduce the "token", "request tag", and "Etag" concepts before using them. Reading front-to-back, I spent most of Section 4 confused.

- (4.4) It would be useful to state that clients MUST (SHOULD?) NOT request retransmission of blocks from ETags that are not "fresh" -- IIUC, they probably don't exist anymore, and anyway the server has no way of knowing which non-fresh ETag to serve beacuse it says "The ETag Option should not be used in the request for missing blocks"

BTW, s/should/SHOULD

- (7.2) If NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT both "have the same value as computed for EXCHANGE_LIFETIME", why are they different variables? Or is that they SHOULD have the same value but might not? A normative word would be helpful here.

[Ballot discuss]
The current CORE charter does not seem to cover the topic of this
document. I also see no related milestone.

Section 1, paragraph 4, discuss:
>    There is a requirement for these blocks of data to be transmitted at
>    higher rates under network conditions where there may be asymmetrical
>    transient packet loss (i.e., responses may get dropped).  An example
>    is when a network is subject to a Distributed Denial of Service
>    (DDoS) attack and there is a need for DDoS mitigation agents relying
>    upon CoAP to communicate with each other (e.g.,
>    [RFC8782][I-D.ietf-dots-telemetry]).  As a reminder, [RFC7959]

I understand that COAP was initially chosen to transport DOTS signaling messages
due to their small size, support for structured messages and request/response
semantics, as well as the ability to function over lossy paths such as found in
IoT deployment, which COAP is architected for.

DOTS now seems to desire to transport larger messages, and this document extends
CORE to enable this functionality. However, this CORE extension seems to solely
focus on Internet deployment scenarios, essentially attempting to re-architect
COAP into a general Internet transport protocol for transmission over paths with
high loss rates. I do not believe that the CORE WG is chartered to do this.

[Ballot comment]
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools, so there will likely be some false positives. There is no need
to let me know what you did with these suggestions.

Section 1, paragraph 3, nit:
> ell in environments where there are no or minimal packet losses. These optio
>                                    ^^
Did you mean "now" (=at this moment) instead of 'no' (negation)?

Section 3, paragraph 16, nit:
> ed by the peer whether the body comprises of a single or multiple payloads a
>                                ^^^^^^^^^^^^
Did you mean "comprises" or "consists of"?

Section 4.1, paragraph 18, nit:
> T be included as Inner options. Similarly there MUST NOT be a mix of Q-Block
>                                ^^^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 4.3, paragraph 3, nit:
> -Tag value MUST be the same for all of the requests for the body of data tha
>                                ^^^^^^^^^^
Consider using "all the".

Section 4.3, paragraph 3, nit:
> ue, the server still treats it as opaque but the client MUST ensure that it i
>                                  ^^^^^^
Use a comma before 'but' if it connects two independent clauses (unless they
are closely connected and short).

Section 4.3, paragraph 6, nit:
>  not arrived after a timeout and a retransmit missing payloads response is n
>                                  ^^^^^^^^^^^^
After 'a', do not use a verb. Make sure that the spelling of 'retransmit' is
correct. If 'retransmit' is the first word in a compound adjective, use a
hyphen between the two words. Note: This error message can occur if you use a
verb as a noun, and the word is not a noun in standard English.

Section 4.3, paragraph 6, nit:
>  a timeout and a retransmit missing payloads response is needed. For reliabl
>                                    ^^^^^^^^
An apostrophe may be missing.

Section 4.3, paragraph 11, nit:
> g. The client should then release all of the tokens used for this body. Note
>                                  ^^^^^^^^^^
Consider using "all the".

Section 4.3, paragraph 13, nit:
> t. The client should then release all of the tokens used for this body. 2
>                                  ^^^^^^^^^^
Consider using "all the".

Section 4.3, paragraph 15, nit:
> quest. The client should then release all of the tokens used for this body.
>                                      ^^^^^^^^^^
Consider using "all the".

Section 4.3, paragraph 18, nit:
>  The client should then release all of the tokens used for this body unless
>                                ^^^^^^^^^^
Consider using "all the".

Section 4.3, paragraph 20, nit:
> e Code can be used to indicate that all of the blocks up to and including th
>                                    ^^^^^^^^^^
Consider using "all the".

Section 4.3, paragraph 30, nit:
> ing-blocks+cbor-seq" indicates that some of the payloads are missing and need
>                                    ^^^^^^^^^^^
If the text is a generality, 'of the' is not necessary.

Section 4.4, paragraph 4, nit:
> a request for that block and for all of the remaining blocks in the current
>                                  ^^^^^^^^^^^^^^^^
Consider using "all the".

Section 4.4, paragraph 7, nit:
> paque, the client still treats it as opaque but the server MUST ensure that i
>                                      ^^^^^^
Use a comma before 'but' if it connects two independent clauses (unless they
are closely connected and short).

Section 4.4, paragraph 16, nit:
> , the client should then release all of the tokens used for this body unless
>                                  ^^^^^^^^^^
Consider using "all the".

Section 4.5, paragraph 1, nit:
> r a request that uses Q-Block1, the Observe value [RFC7641] MUST be the same
>                                ^^^^^^^^^^^
After 'the', do not use a verb. Make sure that the spelling of 'Observe' is
correct. If 'Observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 4.5, paragraph 2, nit:
>  a response that uses Q-Block2, the Observe value MUST be the same for all t
>                                ^^^^^^^^^^^
After 'the', do not use a verb. Make sure that the spelling of 'Observe' is
correct. If 'Observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 4.5, paragraph 3, nit:
> ferent from Block2 usage where the Observe value is only present in the firs
>                                ^^^^^^^^^^^
After 'the', do not use a verb. Make sure that the spelling of 'Observe' is
correct. If 'Observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 5, paragraph 2, nit:
> that the server has not received all of the blocks of the request body that
>                                  ^^^^^^^^^^
Consider using "all the".

Section 5, paragraph 4, nit:
> as a CBOR Sequence [RFC8742]. It comprises of one or more missing block numb
>                                  ^^^^^^^^^^^^
Did you mean "comprises" or "consists of"?

Section 5, paragraph 6, nit:
> sing blocks is as follows: ; A notional array, the elements of which
>                            ^
Loose punctuation mark.

Section 7.1, paragraph 2, nit:
>  It is implementation specific as to whether there should be any further req
>                                ^^^^^^^^^^^^^
Consider shortening this phrase to just "whether", or rephrase the sentence to
avoid "as to".

Section 7.2, paragraph 9, nit:
> D consider the body stale, remove any body, and release Tokens and Request-T
>                                  ^^^^^^^^
Did you mean "anybody"?

Section 7.2, paragraph 10, nit:
> limit the potential wait needed calculated when using PROBING_WAIT. NON_PROB
>                                ^^^^^^^^^^
"needed calculated" is only accepted in certain dialects. For something more
widely acceptable, consider "to be calculated".

Section 7.2, paragraph 14, nit:
> G_WAIT. Note: For the particular DOTS application, PROBING_RATE and other
>                                  ^^^^
An apostrophe may be missing.

Section 7.2, paragraph 15, nit:
> s. Even when not negotiated, the DOTS application uses customized defaults as
>                                  ^^^^
An apostrophe may be missing.

Section 7.2, paragraph 19, nit:
> rived for each body for at least a 24 hour period and it is known that there
>                                    ^^^^^^^
When a number forms part of an adjectival compound, use a hyphen: "24-hour"

Section 7.2, paragraph 19, nit:
> each body for at least a 24 hour period and it is known that there are no ot
>                                  ^^^^^^^^^^
Use a comma before 'and' if it connects two independent clauses (unless they
are closely connected and short).

Section 7.2, paragraph 19, nit:
>  situation re-evaluated for another 24 hour period until there is no report
>                                    ^^^^^^^
It appears that a hyphen is missing.

Section 7.2, paragraph 19, nit:
> PAYLOADS values, a peer may continue indicate that there are some missing pa
>                            ^^^^^^^^^^^^^^^^^
Probably a preposition is missing after 'continue'.

Section 7.2, paragraph 22, nit:
> tinue) Response Code on receipt of all of the MAX_PAYLOADS payloads to preven
>                                    ^^^^^^^^^^
Consider using "all the".

Section 7.2, paragraph 22, nit:
> t unnecessarily delaying. If not all of the MAX_PAYLOADS payloads were receiv
>                                  ^^^^^^^^^^^^^
Consider using "all the".

Section 7.2, paragraph 24, nit:
> xt set of payloads on receipt of all of the MAX_PAYLOADS payloads to prevent
>                                  ^^^^^^^^^^
Consider using "all the".

Section 7.2, paragraph 24, nit:
> e server unnecessarily delaying. Otherwise the client SHOULD delay for NON_R
>                                  ^^^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 10.1.3, paragraph 5, nit:
> - Tag by matching the token with the sent request. CoAP CoAP
>                                      ^^^^
Did you mean "scent"?

Section 10.2, paragraph 2, nit:
> n is not required for Q-Block2; the observe detail can thus be ignored. 10.2
>                                ^^^^^^^^^^^
After 'the', do not use a verb. Make sure that the spelling of 'observe' is
correct. If 'observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 10.2.1, paragraph 2, nit:
> The same process is repeated when an Observe is triggered, but no loss is ex
>                                  ^^^^^^^^^^
After 'an', do not use a verb. Make sure that the spelling of 'Observe' is
correct. If 'Observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 10.2.3, paragraph 1, nit:
> y Figure 10 shows the example of an Observe that is triggered but for which s
>                                  ^^^^^^^^^^
After 'an', do not use a verb. Make sure that the spelling of 'Observe' is
correct. If 'Observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 10.2.4, paragraph 1, nit:
> t Figure 11 shows the example of an Observe that is triggered but only the fi
>                                  ^^^^^^^^^^
After 'an', do not use a verb. Make sure that the spelling of 'Observe' is
correct. If 'Observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 10.3.3, paragraph 5, nit:
> t-Tag by matching the token with the sent request. CoAP CoAP C
>                                      ^^^^
Did you mean "scent"?

Section 12.3, paragraph 3, nit:
> blocks+cbor-seq o Encoding: - o Id: TBA3 o Reference: [RFCXXXX] Th
>                                ^^
Possible spelling mistake found

Section 13.2, paragraph 4, nit:
> try] Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c.,
>                          ^
Add a space between sentences

Section 13.2, paragraph 9, nit:
> org/info/rfc8610>. [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P
>                                    ^
Add a space between sentences

"A.1.", paragraph 7, nit:
>  It is up to the implementation as to whether the application process stops t
>                                ^^^^^^^^^^^^^
Consider shortening this phrase to just "whether", or rephrase the sentence to
avoid "as to".

"A.2.", paragraph 4, nit:
>  It is up to the implementation as to whether the application process stops t
>                                ^^^^^^^^^^^^^
Consider shortening this phrase to just "whether", or rephrase the sentence to
avoid "as to".

"B.1.", paragraph 1, nit:
>  use of Q-Block1 Option with a reliable transport as shown in Figure 20. Ther
>                              ^^^^^^^^^^^^^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"reliable transport".

"B.1.", paragraph 2, nit:
> shown in Figure 20. There is no acknowledgment of packets at the CoAP layer,
>                                ^^^^^^^^^^^^^^
Do not mix variants of the same word ('acknowledgment' and 'acknowledgement')
within a single text.

"B.2.", paragraph 1, nit:
>  of the use of Q-Block2 Option with a reliable transport is shown in Figure
>                                    ^^^^^^^^^^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"reliable transport".

Document references draft-ietf-core-echo-request-tag-11, but
draft-ietf-core-echo-request-tag-12 is the latest available revision.

[Ballot comment]
[[ comments ]]

[ general ]

* I share some others' (no citation) concern about "creeping TCPism".
  I'll defer to others with vastly more transport layer experience.


[[ nits ]]

[ section 3 ]

* "less packet interchanges" -> "fewer packet interchanges", perhaps

[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated especially on the intended status/lack of public implementations).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

!!! I was about to ballot a DISCUSS on this point... In the absence of a section about existing implementations for such a new transport, I really wonder whether standard track should be used rather then experimental. Did the authors/WG run some simulations ?

Happy to have read Colin Perkins' review for the Transport ART, which has provided me with some confidence in this brand new transport protocol. I am also trusting the TSV Area Directors on this point.

-- Section 1 --
I had in mind that constrained network are well protected either at layer-2 or by having an air-gap or firewall at their edges, so, a DoS seems quite improbable in those deployments. Should this 'use case' really be part of the introduction? Or is it simply linked to the DOTS use case ? In either case, the DoS should be more detailed.

-- Section 3 --
Any reason why 'CON' is not expanded/explained on first use ?

[Ballot discuss]
I am concerned about the convergence of three different provisions in this spec:

- In (4.1), it says "To reliably get a rejection message, it is therefore
  REQUIRED that clients use a Confirmable message for determining
  support for Q-Block1 and Q-Block2 Options."

IIUC this mandates that at least one request will use CON.

- (7.1): all the blocks of a single body over an
  unreliable transport MUST either all be Confirmable or all be Non-
  confirmable.

- (7.2) However, the other CON congestion
  control parameters will need to be tuned to cover this change.  This
  tuning is out of scope of this document as it is expected that all
  requests and responses using Q-Block1 and Q-Block2 will be Non-
  confirmable (Section 3.2).

I can't reconcile (4.1) with the last sentence in (7.2). Moreover, if my reading of (4.1) is correct, it's not sufficient to declare congestion control guidance out of scope when it's a mandated part of the protocol.

[Ballot comment]
Thank you for the examples. They were useful in providing an overview of the protocol.

Thanks also to Colin Perkins for an especially thoughtful TSVART review. Please address his comments, although his concerns about (7.1) are IMO mostly subsumed by my DISCUSS.

- It would be useful to introduce the "token", "request tag", and "Etag" concepts before using them. Reading front-to-back, I spent most of Section 4 confused.

- (4.4) It would be useful to state that clients MUST (SHOULD?) NOT request retransmission of blocks from ETags that are not "fresh" -- IIUC, they probably don't exist anymore, and anyway the server has no way of knowing which non-fresh ETag to serve beacuse it says "The ETag Option should not be used in the request for missing blocks"

BTW, s/should/SHOULD

- (7.2) If NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT both "have the same value as computed for EXCHANGE_LIFETIME", why are they different variables? Or is that they SHOULD have the same value but might not? A normative word would be helpful here.

### Summary

Document Shepherd: Marco Tiloca
Area Director: Francesca Palombini

The document defines two new options for the Constrained Application Protocol (CoAP), namely Q-Block1 and Q-Block2. The two options enable effective block-wise transfers of large data payload, also under network conditions where asymmetrical transient packet loss may be experienced.

The main use case addressed by this document is a network under Distributed Denial of Service (DDoS) attack, where DDoS mitigation agents are still required to exchange large amount of data using CoAP. This use case is especially targeted in the DOTS Working Group, where the use of the two new options is suggested in its DOTS Telemetry, see https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/

Compared to the similar options Block1 and Block2 defined in RFC 7959 --- which are based on synchronous, lock-step exchanges of blocks, and thus can be ineffective or even prohibitive to use under a DDoS situation --- the new options enable faster transmission rates with less packet interchanges, as well as faster recovery of lost blocks.

The document also defines congestion control procedures to be used when the Q-Block1 and Q-Block2 Options are used over an unreliable transport.

The document is intended for Standards Track.

Version -11 addressed Last Call comments from GenART about providing clarifications and small fixes.

### Review and Consensus

The document has been discussed on multiple IETF meetings and CoRE interim meetings, and has gone through multiple expert reviews.

During and after Working Group Last Call, effort was also put in better reflecting how design choices align with the intended scope of the document, i.e. to serve especially use cases with asymmetrical transient packet loss and particularly the DOTS Telemetry, see https://datatracker.ietf.org/doc/html/rfc8782  and  https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/

Consensus has been reached on the scope, content and level of detail of the document.

### Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

### Other Points

The document registers:

* Two new option numbers in the "CoAP Option Numbers" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry.
* One new Media-Type in the "Media Types" registry.
* One new related CoAP Content-Format in the "CoAP Content-Formats" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry.

A Pull-Request of an author's implementation to "libcoap" is available at https://github.com/obgm/libcoap/pull/611

Feedback from the implementation activity has contributed to the design and refinement of specific aspects, notably:

- Limiting new mechanics for congestion control only to CoAP Non-Confirmable messages.
- Not mixing CoAP Confirmable and Non-Confirmable messages for a same request/response body.
- The 'Continue' indication of successfully received blocks.
- The discovery of server support for the Q-Block1 and Q-Block2 Options.
- Further lessons learned highlighted as "Implementation note" in the document.

### Checklist

- [X] Does the shepherd stand behind the document and think the document is ready for publication?
- [X] Is the correct RFC type indicated in the title page header?
- [X] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
- [X] Is the intent of the document accurately and adequately explained in the introduction?
- [X] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
- [X] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?

- [X] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
- [X] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
- [X] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
- [X] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
'Does not apply'
- [X] If this is a "bis" document, have all of the errata been considered?
'Does not apply'

**IANA** Considerations:

- [X] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
- [X] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
- [X] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
- [X] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
- [X] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
- [X] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
'Does not apply'
- [X]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?
'Does not apply'

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-core-new-block-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the CoAP Option Numbers registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

two new values are to be registered as follows:

Number: [ TBD-at-Registration ]
Name: Q-Block1
Reference: [ RFC-to-be ]

Number: [ TBD-at-Registration ]
Name: Q-Block2
Reference: [ RFC-to-be ]

IANA notes that the authors suggest values of 19 and 31 for these two registrations.

In the application namespace of the Media Type registry located at:

https://www.iana.org/assignments/media-types/

a new media type will be registered as:

Name: missing-blocks+cbor-seq
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Third, in the CoAP Content-Formats registry also on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

a new registration is to be made as follows:

Media Type: application/missing-blocks+cbor-seq
Encoding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

IANA notes that the authors suggest the value 272 for this registration.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-04-28):

From: The IESG
To: IETF-Announce
CC: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-new-block@ietf.org, francesca.palombini@ericsson.com, marco.tiloca@ri.se
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Faster Transmission) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments WG
(core) to consider the following document: - 'Constrained Application
Protocol (CoAP) Block-Wise Transfer Options
  for Faster Transmission'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-04-28. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies alternative Constrained Application Protocol
  (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options.

  These options are similar to the CoAP Block1 and Block2 Options
  defined in RFC 7959, not a replacement for them, but do enable faster
  transmission rates for large amounts of data with less packet
  interchanges.  Also, Q-Block1 and Q-Block2 Options support faster
  recovery should any of the blocks get lost in transmission.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-new-block/



No IPR declarations have been submitted directly on this I-D.

### Summary

Document Shepherd: Marco Tiloca
Area Director: Francesca Palombini

The document defines two new options for the Constrained Application Protocol (CoAP), namely Q-Block1 and Q-Block2. The two options enable effective block-wise transfers of large data payload, also under network conditions where asymmetrical transient packet loss may be experienced.

The main use case addressed by this document is a network under Distributed Denial of Service (DDoS) attack, where DDoS mitigation agents are still required to exchange large amount of data using CoAP. This use case is especially targeted in the DOTS Working Group, where the use of the two new options is suggested in its DOTS Telemetry, see https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/

Compared to the similar options Block1 and Block2 defined in RFC 7959 --- which are based on synchronous, lock-step exchanges of blocks, and thus can be ineffective or even prohibitive to use under a DDoS situation --- the new options enable faster transmission rates with less packet interchanges, as well as faster recovery of lost blocks.

The document also defines congestion control procedures to be used when the Q-Block1 and Q-Block2 Options are used over an unreliable transport.

The document is intended for Standards Track.

### Review and Consensus

The document has been discussed on multiple IETF meetings and CoRE interim meetings, and has gone through multiple expert reviews.

During and after Working Group Last Call, effort was also put in better reflecting how design choices align with the intended scope of the document, i.e. to serve especially use cases with asymmetrical transient packet loss and particularly the DOTS Telemetry, see https://datatracker.ietf.org/doc/html/rfc8782  and  https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/

Consensus has been reached on the scope, content and level of detail of the document.

### Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

### Other Points

The document registers:

* Two new option numbers in the "CoAP Option Numbers" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry.
* One new Media-Type in the "Media Types" registry.
* One new related CoAP Content-Format in the "CoAP Content-Formats" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry.

A Pull-Request of an author's implementation to "libcoap" is available at https://github.com/obgm/libcoap/pull/611

Feedback from the implementation activity has contributed to the design and refinement of specific aspects, notably:

- Limiting new mechanics for congestion control only to CoAP Non-Confirmable messages.
- Not mixing CoAP Confirmable and Non-Confirmable messages for a same request/response body.
- The 'Continue' indication of successfully received blocks.
- The discovery of server support for the Q-Block1 and Q-Block2 Options.
- Further lessons learned highlighted as "Implementation note" in the document.

### Checklist

- [X] Does the shepherd stand behind the document and think the document is ready for publication?
- [X] Is the correct RFC type indicated in the title page header?
- [X] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
- [X] Is the intent of the document accurately and adequately explained in the introduction?
- [X] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
- [X] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?

- [X] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
- [X] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
- [X] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
- [X] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
'Does not apply'
- [X] If this is a "bis" document, have all of the errata been considered?
'Does not apply'

**IANA** Considerations:

- [X] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
- [X] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
- [X] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
- [X] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
- [X] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
- [X] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
'Does not apply'
- [X]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?
'Does not apply'

### Summary

Document Shepherd: Marco Tiloca
Area Director: Francesca Palombini

The document defines two new options for the Constrained Application Protocol (CoAP), namely Q-Block1 and Q-Block2. The two options enable effective block-wise transfers of large data payload, also under network conditions where asymmetrical transient packet loss may be experienced.

The main use case addressed by this document is a network under Distributed Denial of Service (DDoS) attack, where DDoS mitigation agents are still required to exchange large amount of data using CoAP. This use case is especially targeted in the DOTS Working Group, where the use of the two new options is suggested in its DOTS Telemetry, see https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/

Compared to the similar options Block1 and Block2 defined in RFC 7959 --- which are based on synchronous, lock-step exchanges of blocks, and thus can be ineffective or even prohibitive to use under a DDoS situation --- the new options enable faster transmission rates with less packet interchanges, as well as faster recovery of lost blocks.

The document also defines congestion control procedures to be used when the Q-Block1 and Q-Block2 Options are used over an unreliable transport.

The document is intended for Standards Track.

### Review and Consensus

The document has been discussed on multiple IETF meetings and CoRE interim meetings, and has gone through multiple expert reviews.

During and after Working Group Last Call, effort was also put in better reflecting how design choices align with the intended scope of the document, i.e. to serve especially use cases with asymmetrical transient packet loss and particularly the DOTS Telemetry, see https://datatracker.ietf.org/doc/html/rfc8782  and  https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/

Consensus has been reached on the scope, content and level of detail of the document.

### Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

### Other Points

The document registers:

* Two new option numbers in the "CoAP Option Numbers" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry.
* One new Media-Type in the "Media Types" registry.
* One new related CoAP Content-Format in the "CoAP Content-Formats" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry.

A Pull-Request of an author's implementation to "libcoap" is available at https://github.com/obgm/libcoap/pull/611

Feedback from the implementation activity has contributed to the design and refinement of specific aspects, notably:

- Limiting new mechanics for congestion control only to CoAP Non-Confirmable messages.
- Not mixing CoAP Confirmable and Non-Confirmable messages for a same request/response body.
- The 'Continue' indication of successfully received blocks.
- The discovery of server support for the Q-Block1 and Q-Block2 Options.
- Further lessons learned highlighted as "Implementation note" in the document.

### Checklist

- [X] Does the shepherd stand behind the document and think the document is ready for publication?
- [X] Is the correct RFC type indicated in the title page header?
- [X] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
- [X] Is the intent of the document accurately and adequately explained in the introduction?
- [X] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
- [X] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?

- [X] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
- [X] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
- [X] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
- [X] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
'Does not apply'
- [X] If this is a "bis" document, have all of the errata been considered?
'Does not apply'

**IANA** Considerations:

- [X] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
- [X] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
- [X] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
- [X] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
- [X] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
- [X] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
'Does not apply'
- [X]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?
'Does not apply'

### Summary

Document Shepherd: Marco Tiloca
Area Director: Francesca Palombini

The document defines two new options for the Constrained Application Protocol (CoAP), namely Q-Block1 and Q-Block2. The two options enable effective block-wise transfers of large data payload, also under network conditions where asymmetrical transient packet loss may be experienced.

The main use case addressed by this document is a network under Distributed Denial of Service  (DDoS) attack, where DDoS mitigation agents are still required to exchange large amount of data using CoAP. This use case is especially targeted in the DOTS Working Group, where the use of the two new options is suggested in its DOTS Telemetry, see https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/

Compared to the similar options Block1 and Block2 defined in RFC 7959 --- which are based on synchronous, lock-step exchanges of blocks, and thus can be ineffective or even prohibitive to use under a DDoS situation --- the new options enable faster transmission rates with less packet interchanges, as well as faster recovery of lost blocks.

The document also defines congestion control procedures to be used when the Q-Block1 and Q-Block2 Options are used over an unreliable transport.

The document is intended for Standards Track.

### Review and Consensus

The document has been discussed on multiple IETF meetings and CoRE interim meetings, and has gone through multiple expert reviews.

During and after Working Group Last Call, effort was also put in better reflecting how design choices align with the intended scope of the document, i.e. to serve especially use cases with asymmetrical transient packet loss and particularly the DOTS Telemetry, see https://datatracker.ietf.org/doc/html/rfc8782  and  https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/

Consensus has been reached on the scope, content and level of detail of the document.

### Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

### Other Points

The document registers:

* Two new option numbers in the "CoAP Option Numbers" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry.
* One new Media-Type in the "Media Types" registry.
* One new related CoAP Content-Format in the "CoAP Content-Formats" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry.

A Pull-Request of an author's implementation to "libcoap" is available at https://github.com/obgm/libcoap/pull/611

Feedback from the implementation activity has contributed to the design and refinement of specific aspects, notably:

- Limiting new mechanics for congestion control only to CoAP Non-Confirmable messages.
- Not mixing CoAP Confirmable and Non-Confirmable messages for a same request/response body.
- The 'Continue' indication of successfully received blocks.
- The discovery of server support for the Q-Block1 and Q-Block2 Options.
- Further lessons learned highlighted as "Implementation note" in the document.

### Checklist

- [X] Does the shepherd stand behind the document and think the document is ready for publication?
- [X] Is the correct RFC type indicated in the title page header?
- [X] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
- [X] Is the intent of the document accurately and adequately explained in the introduction?
- [X] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
- [X] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?

- [X] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
- [X] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
- [X] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
- [X] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
'Does not apply'
- [X] If this is a "bis" document, have all of the errata been considered?
'Does not apply'

**IANA** Considerations:

- [X] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
- [X] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
- [X] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
- [X] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
- [X] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
- [X] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
'Does not apply'
- [X]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?
'Does not apply'