Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block

[[e-mail]]

Hi Christian,

Once again, thank you for the comprehensive review.

Responses part 2.  A new version (-04) of the draft has been published and
can be found at https://datatracker.ietf.org/doc/draft-ietf-core-new-block/


Part 1 responses were covered in the main by version -03, so you may want to
look at the -02 to -04 differences.

The Congestion Control section has been re-written to simplify how things
work and has a new set of definitions. There is a separation of Confirmable
and Non-Confirmable Congestion Control with the stated assumption that all
of a body is sent as Non-Confirmable or Confirmable.

Otherwise, see inline.

Regards

Jon

> 
> * The list of pros and cons (with the cons being almost trivial) does
>   not explain to the reader why these are not a replacement; I suggest
>   to add:

[Jon] Another disadvantage addition
NEW
To reduce the transmission times for CON transmission of large bodies,
NSTART needs to be increased from 1, but this affects congestion control
where other parameters need to be tuned  (Section 4.7 of [RFC7252]).  Such
tuning is out of scope of this document.

> 
> * "If the client transmits a new body of data with a new Request-Tag
>   to": Processing parallel requests is something Request-Tag opens up. I
>   don't see why there's a MUST to that; the server certainly MAY drop
>   the old request, but it may just as well process them in parallel.

[Jon] The intent here was that garbage collection would take place sooner
than later - especially when running in a lossy environment and the client
has updated information to transmit. I agree that Request-Tag enables the
possibility of sending multiple block requests with different payloads, and
so there is a possibility that the client starts sending body A, then
decides to send body B and terminate A, but a packet from B arrives before a
packet from body A is received and so things fail as A does not complete.

OLD
   If the client transmits a new body of data with a new Request-Tag to
   the same resource on a server, the server MUST remove any partially
   received body held for a previous Request-Tag for that resource.
NEW
  If a server receives payloads with different Request-Tags for the same
resource, it should continue to process all the bodies as it has no way of
determining which is the latest version, or which body, if any, the client
is terminating the transmission for.

  If the client elects to stop the transmission of a complete body, it	
  SHOULD "forget" all tracked tokens associated with the body's	
 Request-Tag so that a reset message is generated for the invalid	
 token in the 4.08 (Request Entity Incomplete) response.  The server	
 on receipt of the reset message SHOULD delete the partial body.
END

> 
> * "If the server receives a duplicate block with the same Request-Tag":
>   Why? Being silent is the default on nonterminal blocks alredy, but in
>   a situation like figure 5 if the 2.04 is lost, that rule would make
>   it impossible for the client to ever get a successful response.
> 
>   A better rule here may be to say that it processes it all the same
>   (and if the payload is distinct from the first transmission's payload,
>   it should err out.)

[Jon] Fair point
OLD
   If the server receives a duplicate block with the same Request-Tag,
   it SHOULD silently ignore the packet.
NEW
   If the server receives a duplicate block with the same Request-Tag,
   it SHOULD  ignore the payload of the packet, but MUST still respond as if
the block was received for the first time.
> 
> * "If the server receives multiple requests (implied or otherwise) for
>   the same block, it MUST only send back one instance of that block.":
>   This might be read as "ever" rather than "per incoming request", where
>   probably the latter is meant.

[Jon] This text has already been updated following another review
"OLD
If the server receives multiple requests
   (implied or otherwise) for the same block, it MUST only send back one
   instance of that block.
NEW
If the request includes multiple Q-Block2
   Options and these options overlap (e.g., combination of M being set
   (this and all the later blocks) and being unset (this individual
   block)) resulting in an individual block being requested multiple
   times, the server MUST only send back one instance of that block.
   This behavior is meant to prevent amplification attacks."

> 
> * "The ETag Option MUST NOT be used": This is more a factural than a
>   normative statement; it *can* not be used there as the server would
>   respond thusly. It may be used, but then that indicates that the
>   client is trying to verify a freshness. (However, the client should
>   not *start* sending an ETag once it learned the current resource's
>   ETag when still attempting to pull out more blocks, but that's also not
>   a normative requirement but a consequence of those two requests not
>   being matchable any more.)

[Jon] OK
OLD
   The ETag Option MUST NOT be used in the request as the server could
   respond with a 2.03 (Valid Response) with no payload.  If the server
   responds with a different ETag Option value (as the resource
   representation has changed), then the client SHOULD drop all the
   payloads for the current body that are no longer valid. 
NEW
   The ETag Option should not be used in the request for missing blocks as
the server could respond with a 2.03 (Valid Response) with no payload. It
can be used in the request if the client wants to check the freshness of the
currently cached body response.

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 body response SHOULD be restarted with a different ETag
Option value. Any subsequent missing block requests MUST respond using the
latest ETag Option value.

 If the server responds during a body update with a different ETag Option
value (as the resource representation has changed), then the client should
treat the partial body with the old ETag as no longer being fresh. 
END
> 
> * "then the client SHOULD drop all the payloads for the current body":
>   "Drop" is overly prescriptive; the client may well keep them, but
>   just can't consider them fresh any more. (If the client has ample
>   caching abilities, they might come in handy if the resource goes back
>   to that ETag state). Same for later "the client MUST remove any
>   partially received".

[Jon] See previous response, otherwise
OLD
   If the server transmits a new body of data (e.g., a triggered
   Observe) with a new ETag to the same client as an additional
   response, the client MUST remove any partially received body held for
   a previous ETag.
NEW
   If the server transmits a new body of data (e.g., a triggered
   Observe) 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.
> 
> * "For Confirmable transmission, the client SHOULD continue to": As
>   above in the other direction, that's not news.

[Jon] Again, we are not looking for a response (well, a request in this case
as needed by Block2), just an ACK
OLD
   For Confirmable transmission, the client SHOULD continue to
   acknowledge each packet as well as issuing a separate GET, POST, PUT,
   FETCH, PATCH, or iPATCH for the missing blocks.
NEW
   For Confirmable transmission, the server continues to acknowledge	
  each packet, but a response is not required (whether separate or	
  piggybacked) until successful receipt of the body or, if some of the	
  payloads are sent as Non-confirmable and have not arrived, a	
  retransmit missing payloads response is needed.
> 
> * "If there is insufficient space to create a response PDU": I don't
>   understand what that means. (Where are request options reflected
>   back?).

[Jon] This was triggered by a question by Michael Richardson " So, given a
Christmas-Tree-Packet (largest packet, every possible option space used,
every extension turned on...) how much data can I get back? :-)" and not
fully thought through.
It could happen though with Location-Path, Location-Query, Q-Block2, ETag,
Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE  in response to
a POST.
OLD
   If there is insufficient space to create a response PDU with a block
   size of 16 bytes (SZX = 0) to reflect back all the request options as
   appropriate, a 4.13 (Request Entity Too Large) is returned without
   the Size2 Option.
NEW
   If there is insufficient space to create a response PDU with a block
   size of 16 bytes (SZX = 0) to send back all the response options as
   appropriate, a 4.13 (Request Entity Too Large) is returned without
   the Size1 Option.

> 
> * "If the client requests missing blocks, this is treated as a new
>    request.": I don't think the client should even make these follow-up
>    requests Observe, as it already has an ongoing observation. They'd be
>    sent on a different token too, so setting Observe would be opening
>    observation up on that token, which AFAIU is not intended. (Figure 7
>    example looks good to me in that respect.)
> 
>    (It may make sense to ask the client to keep Observe to make the
>    requests matchable just for the sake of staying in atomic-request
>    mode. Either way, the server should then not accept that observation
>    as it's not for a block 0.)

[Jon] The intent here was that just a new Token should be used.
OLD
   If the client requests missing blocks, this is treated as a new
   request.  The Observe value may change but MUST still be reported.
   If the ETag value changes then the previously received partial body
   should be destroyed and the whole body re-requested.
NEW
   If the client requests missing blocks, this is treated as a new
   Request and the Observe Option MUST NOT be included.   If the ETag value
changes, then the previously received partial body
   should be considered as not fresh and the whole body re-requested.

> 
> * "First is CBOR encoded Request-Tag": Why? Each 4.08 response can be
>   matched by the token to a unique request that already had a
>   Request-Tag, and the client needs to have kept that token around
>   matched to the transfer to make sense of it.
> 
>   No need to move that value around between subsystems, and just
>   dropping it from here would also remove the need for the "If the
>   client does not recognize the Request-Tag" clause (which would
>   otherwise need clarification as to what it'd mean if it recognizes it
>   but it doesn't match what the request was for).

[Jon] Good question - it does make sense for the Request-Tag to be tracked
alongside the Token in the client.
OLD
   The data payload of the 4.08 (Request Entity Incomplete) Response
   Code is encoded as a CBOR Sequence [RFC8742].  First is CBOR encoded
   Request-Tag followed by 1 or more missing CBOR encoded missing block
   numbers.
NEW
   The data payload of the 4.08 (Request Entity Incomplete) response
   is encoded as a CBOR Sequence [RFC8742].  There are one or more missing
   CBOR encoded missing block numbers.

OLD
       ; This defines an array, the elements of which are to be used
       ; in a CBOR Sequence:
       payload = [request-tag, + missing-block-number]
       request-tag = bstr
       ; A unique block number not received:
       missing-block-number = uint
NEW
       ; This defines an array, the elements of which are to be used
       ; in a CBOR Sequence:
       payload = [+ missing-block-number]
       request-tag = bstr
       ; A unique block number not received:
       missing-block-number = uint 

OLD
   A 4.08 (Request Entity Incomplete) 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 re-transmits the missing payloads using the Request-Tag and
   Q-Block1 to specify the block number, SZX, and M bit as appropriate.
   The Request-Tag value to use is determined from the payload of the
   4.08 (Request Entity Incomplete) Response Code.  If the client does
   not recognize the Request-Tag, the client can ignore this response.
NEW (option presentation has been reformatted)
  4.08 (Request Entity Incomplete)

  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 number, SZX, and M bit as appropriate.	
 

 The Request-Tag value to use is determined from the token in the	
 4.08 (Request Entity Incomplete) response and then finding the	
 matching client request which contains the Request-Tag that is	
  being used for this Q-Block1 body. END
> 
> * "limit the array count to 23 (Undefined value)": 23 is the maximum
>   length of a zero-byte length indication, not indefinite-length (31).
>   Both using 23 and 31 here makes sense (up to 23 to have definite
>   length that can be updated in-place, or exceeding that switch to
>   indefinite length if they still fit), but the paragraph seems to be
>   mixing them up.

[Jon] OK
OLD
      Arrays (Section 3.2.2 of [RFC8949]), limit the array count to 23
      (Undefined value) so that the array data byte can be updated with
      the overall length once the payload length is confirmed or limited
      to MAX_PAYLOADS count.
NEW
      Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit the array
count to
      23 so that the initial byte with the array major type and data length
in the additional information can be updated with the overall count once the
payload count is confirmed.  Further restricting the count to MAX_PAYLOADS
means that congestion control is less likely to be invoked on the server.

> 
> * "Each new request MUST use a unique token": Like above, this is
>   stating something that's not intended to be changed.

[Jon] RFC7252 does not require Tokens to be unique - e.g. empty token values
are acceptable.  Hence this statement.
> 
> Congestion Control:
> 
> * "Each NON 4.08 (Request Entity Incomplete) Response Codes is subjected
>    to PROBING_RATE.": That is unexpected here. At most one such
>    response is sent to each request message, so why is additional
>    congestion control needed?

[Jon] The intention here was that in the previous paragraph that it was not
the individual packets that are subject to PROBING_RATE, but a single body
comprising of multiple packets is subject to PROBRING_RATE - and hence
limiting any individual responses to PROBING_RATE rather than the
potentially full set of responses
OLD
   PROBING_RATE parameter in CoAP indicates the average data rate that
   must not be exceeded by a CoAP endpoint in sending to a peer endpoint
   that does not respond.  The body of blocks will be subjected to
   PROBING_RATE (Section 4.7 of [RFC7252]).
NEW
   PROBING_RATE parameter in CoAP indicates the average data rate that
   must not be exceeded by a CoAP endpoint in sending to a peer endpoint
   that does not respond.  The single body of blocks will be subjected to
   PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets.
If the wait time between sending bodies that are not being	
 responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the	
 gap time is limited to NON_PROBING_WAIT.

Note: For the particular DOTS application, PROBING_RATE and other
transmission parameters are negotiated between peers.  Even when	
 not negotiated, the DOTS application uses customized defaults as	
 discussed in Section 4.5.2 of [RFC8782].
END
> 
>    On the other hand, *ever* NON request is subject to PROBING_RATE, so
>    why point out the body of blocks and "GET or similar" particularly?

[Jon] It is only GET or FETCH.  The intention here is to not request bodies
of data at too high a rate.
OLD
   Each NON GET or similar request using Q-Block2 Option is subjected to
   PROBING_RATE.
NEW
   Each NON GET or FETCH request using Q-Block2 Option is subjected to
PROBING_RATE.
> 
> * "a delay is introduced of ACK_TIMEOUT": As I understand MAX_PAYLOADS,
>   this is (rather implicitly) introduced as the package count up to
>   which it is OK to exceed PROBING_RATE temporarily (but after that it
>   kicks in all the harder by requiring to wait until complete-sent-bytes
>   over PROBING_RATE has expired). If that holds, at that time a much
>   larger delay than just ACK_TIMEOUT is needed to get a response from
>   the server: About 3 hours (see later note on parameters).

[Jon] Now limited to 247 seconds (NON_PROBING_WAIT).  See re-write of
Congestion Control section.
> 
>   This is the crucial point in the document, and for it a recommendation
>   alone is not good enough. The protocol can be run with a vastly
>   increased PROBING_RATE (however externally determined) and from the
>   point of MAX_PAYLOADS just observe it. Or it has to get feedback from
>   the server; a single 4.08 is probably enough to kick off another
>   vollley of blocks. (How many? MAX_PAYLOADS for every response?).
>   Both can be permitted, but just waiting ACK_TIMEOUT isn't doing any
>   good.

[Jon] See re-write of Congestion Control section where things should now be
simpler and more logical.  There is an introduction of new variable
definitions.
> 
> * "For NON transmissions": This seems to imply that the full exchange of
>   a body is either NON or CON; I don't see where that'd come from. I'd
>   have expected to read something like "Each individual request can be
>   NON or CON independent of the others. In particular, it can be
>   convenient to send the ultimate payload...".

[Jon]The DOTS environment will only be using NON.  To make Congestion
Control simple,
the expectation is that all transmissions are NON or (not recommended) are
all CON. The draft now generally records this expectation.
> 
> * "If a Confirmable packet is used, then the transmitting peer MUST wait
>   for the ACK": Why? A NSTART > 1 would give it leisure to still
>   transmit.

[Jon] Text has been removed in the clean-up.
> 
> * General on congestion control: It may help implementors if this were
>   split up into newly introduced rules and concepts (that is,
>   MAX_PAYLOADS and the answer to whether you may send MAX_PAYLOADS
> en
>   block again after having only even one response from the last round,
>   and probably the recommended parameters of the "Also on parameters"
>   comment), and another subsection on how Q-Block behaves well when
>   observing these.

[Jon] Should now be covered in the updated Congestion Control section.
> 
> Caching:
> 
> * "are not part of the cache key": How about "are removed as part of the
>   block assembly and thus do not reach the cache"?

[Jon] OK.
OLD
   As the entire body is being cached in the proxy, the Q-Block1 and
   Q-Block2 Options are not part of the cache key.
NEW
   As the entire body is being cached in the proxy, the Q-Block1 and
   Q-Block2 Options are removed as part of the
block assembly and thus do not reach the cache.
> 
> * "When the next client completes building the body": If the proxy
>   chooses not to let them happen in parallel (which it may, see above on
>   parallel requests, although the server might still not support it and
>   cancel one of them), why bother letting the first finish just to abort
>   it? (IOW: If the proxy does not intend to see both through, which it
>   could if it held back the second until the first is through on the
>   uplink, it could just as well err out of one of them early, but it may
>   also rather see both through.)

[Jon] It has to be assumed that traffic to/from the origin client and origin
server may not both support Q-Blockx and potentially may have a different
SZX.  Thus passing a request or a response through at the block level
introduces a new set of challenges (but not impossible to fix).  To keep
this simple, my thinking was that the passing through can only take place at
the body level.  Again, the arrival of packets is not necessarily
sequential, so client A's body may start transmitting to the origin server
first, but client B's body starts to arrive first - the same being true for
the proxy as a client may stop transmitting for whatever reason (restart,
network loss etc.).  However this is covered by the above update "  If a
server receives payloads with different Request-Tags for the same resource,
it should continue to process all the bodies".

OLD
   and the new body representation transmission starts with a new
   Request-Tag value.
NEW
   and the new body representation transmission starts with a new
   Request-Tag value.  Note that it cannot be assumed that the proxy will
always receive a complete body from a client.
> 
> * Examples:
> 
>   * Figure 5: The ... between e3 request and response indicate the
>     MAX_TRANSMIT_SPAN before sending the 4.08 response. I suppose there
>     should be the same kind of delay between the failed e5 transmission
>     and the e4 response.

[Jon] Agreed and added in
> 
>   * If the second burst had 3 requests out of which 2 made it, is there
>     any guidance for which of them the 4.08 would come back on? (In the
>     end, none of them is terminal).

[Jon] The client should tracking all Tokens of the burst (hence
implementation note about bottom 32bits unique and top 32 bits matching
block number for ease of tracking) for a response and so it will make no
difference at to which token is used for the 4.08 response.  From an
implementation perspective, it probably is easier to track the last opaque
token that has the same Request-Tag. 
OLD
   missing ones in one go (Figure 5).  It does so by indicating which
   blocks have been received in the data portion of the response.
NEW
   missing ones in one go (Figure 5).  It does so by indicating which
   blocks have been received in the data portion of the response. The Token
just needs to be one of those that have been received for this Request-Tag ,
so the client can derive the Request-Tag.
> 
>   * If that e4 response gets lost, does the whole mechanism recover from
>     it in any way?

[Jon] In this example, if e4 and e5 get lost, there will be no
4.08/2.01/2.04/5.xx etc. response, so it is up to the client as to whether
it sends the request again or gives up.  See 9.1
  "Under high levels of traffic loss, the client can elect not to retry
   sending missing blocks of data.  This decision is implementation
   specific."
> 
>     Generally, the all-NON and all-CON examples don't look to me like
>     what I'd be doing with this spec; the mixed "a CON every
>     MAX_PAYLOADS" appears much more realistic.

[Jon] It is unsafe to use CON in the  (potentially lossy) DOTS environment
(up to 93 secs timeout per payload with the defaults).  Hence why we are
separating out the NON / CON usage.
> 
>   * Figure X: The request ahs M unset and thus indicats a request for
>     just that block. If more than one is expected, it should say
>     QB2:0/1/1024.
[Jon] With Figure 7, with the M bit set, block 3 would get returned for a
second time.  Draft-ietf-core-new-block-03 also has a Figure 8 which does
exactly what you describe.
> 
> * New Content Format: I think this needs a media type registration to go
>   with it first; based on that, a content format can be registered.

[Jon] Med has responded to this and draft updated.
> 
> * General on MAX_TRANSMIT_SPAN and other timing parameters: I'm not
> sure
>   they're 1:! applicable here. For example, MAX_TRANSMIT_SPAN is defined
>   in terms of reliable transmission, but used for NONs as well. (So is
>   the alternative ot 2x ACK_TIMEOUT).

[Jon] I hear you about the use of MAX_TRANSMIT_SPAN and ACK_TIMEOUT in a NON
environment. Hence re-write of Congestion Control section defining new
variables that can be used for NON.
> 
>   For the purpose of delaying a 4.08 or a follow-up GET, it may make
>   more sense to define a new parameter based on MAX_LATENCY and the
> time
>   it takes the sender to pump out the options (which I don't think we
>   have a good factor for, but may even be negligible here).
> 
>   Could read like this:
> 
>   > The timing parameter MAX_BLOCK_JITTER is introduced, and by default
>   > takes a value of MAX_LATENCY + MAX_PAYLOADS * MTU / BANDWIDTH.

[Jon]  Lets plug in some numbers here.  MAX_LATENCY = 100, MAX_PAYLOADS =
10, MTU = 1280bytes and BANDWIDTH = 1Mbps.

[Jon] MAX_BLOCK_JITTER = 100 + (10 * 1280 * 8)/(1 000 000) = 100.1.  So
BANDWITH of 1Mbps has negligible effect on the calculation. 1Kbps makes
MAX_BLOCK_JITTER 200 seconds.
>   >
>   > With Q-Block2, a client can ask for any missing blocks after not
>   > having received any further response for the duration of
>   > MAX_BLOCK_JITTER.

[Jon] 100+ seconds delay is way too much time to wait for any missing blocks
in my opinion.

[Jon] RFC7252 also states (and the intention is that recovery works well)
" as MAX_LATENCY is not
      intended to describe a situation when the protocol works well, but
      the worst-case situation against which the protocol has to guard."
>   >
>   > With Q-Block1, a server holds off any response for MAX_BLOCK_JITTER
>   > unless all blocks have been received. Only then it evaluates whether
>   > to respond with a 2.0x code, a 4.08 with payload, or not at all
>   > (because it responded to a later request).

[Jon] I am not convinced that this is necessarily the way to go.  The new
Congestion Control more cleanly handles this.
> 
>   This also brings me back to the earlier matter of 2.31: What is a
>   server supposed to send when no packages were lost, but it's pasing
>   the timeout and wants to help the client flush out more packages by
>   confirming something? It says 4.08 in 3.3, but it's not like there's a
>   hole in the contiguous range. Does it need to send 4.08 enumerating
>   all (or at least some) numbers between the first unreceived and what's
>   indicated by Size1? Or can it just send 2.31 and the client knows all
>   it needs to know b/c the response came to the largest block that was 
>   sent and 2.31 indicates that everything is good up to that point?

[Jon] The previous draft states (under Congestion Control) that the client
waits for ACK_TIMEOUT before transmitting the next set of MAX_PAYLOADS
blocks.  The server should wait for "two times ACK_TIMEOUT " (3.3) before
indicating issue.  Apart from perhaps having a new name for ACK_TIMOUT I
think that these are reasonable values for Non-Confirmable - and are used in
the new Congestion Control section.

[Jon] I have reworked Congestion Control to use 2.31 (NON only) as a signal
to say that all of the current MAX_PAYLOADS payloads of a body have been
received, so allowing the client to continue transmitting the next set of
MAX_PAYLOADS payloads without the need to wait any longer.
> 
> * Also on parameters: This document is describing flow control stuff
>   around a situation CoAP was not originally designed for. Wouldn't it
>   make sense to include a set of parameters (PROBING_RATE, MAX_LATENCY,
>   ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt that
>   PROBING_RATE will be left to 1 byte/second for any DOTS application
>   using this (for sending 10KiB in the initial 10-package MAX_PAYLOADS
>   burst would mark that connection as unusable for about 3 hours if they
>   all get lost), so better give justifiable numbers here than rely on
>   implemnetors to come up with unreviewed numbers or disregard
>   PROBING_RATE altogether.

[Jon] Answered by Med, and some new text added.
> 
>   I don't know if it needs additional justification, but an increased
>   N_START may be justifiable there.

[Jon] It may be, but tuning the other associated parameters is really out of
the cope of this draft. This text has been added
NEW
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.  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.
> 
> * Somewhere (never comes up but I think it should): When CONs are used,
>   a 4.08 (or 2.31?) response to a later request can indicate to the
>   client that an earlier CON request has been processed successfully. If
>   the client can match that up (and it should be able to), then it can
>   (and should) cancel that particular CON request.

[Jon] I think that this is covered by my update above with the text
" NEW
   For Confirmable transmission, the server continues to acknowledge	
  each packet, but a response is not required (whether separate or	
  piggybacked) until successful receipt of the body or, if some of the	
  payloads are sent as Non-confirmable and have not arrived, a	
  retransmit missing payloads response is needed."

And in my previous part 1 response (updated)
NEW
For Confirmable transmission, the server continues to acknowledge	
 each packet, but a response is not required (whether separate or	
 piggybacked) until successful receipt of the body or, if some of the	
  payloads are sent as Non-confirmable and have not arrived, a	
  retransmit missing payloads response is needed.
> 
> Best regards
> Christian
> 
> --
> There's always a bigger fish.
>   -- Qui-Gon Jinn