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

From: <[email-masked]>
Date: Wed, 6 Jan 2021 15:24:29 -0000

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

---

From: <[email-masked]>
Date: Wed, 6 Jan 2021 15:39:56 +0000

Hi all, 

One clarification below. 

Cheers,
Med

> -----Message d'origine-----
> De : core [mailto:[email-masked]] De la part de supjps-
> [email-masked]
> Envoyé : mercredi 6 janvier 2021 16:24
> À : [email-masked]; [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : Re: [core] WG Last Call on draft-ietf-core-new-block
> 
> Hi Christian,
> 
> 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.

[Med] Actually, -03 addresses the WGLC comments from Marco while -04 addresses those from Christian. A diff against -03 is thus sufficient to track the changes based on Christian's review.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Marco Tiloca <[email-masked]>
Date: Thu, 7 Jan 2021 13:17:14 +0100

Hi,

Thanks for this revision and for addressing my comments already in
version  -03.

Please, see below some more comments on this version -04.

Best,
/Marco

* s/There are one or more missing CBOR encoded missing block
numbers./There are one or more CBOR encoded missing block numbers.

*  Section 4 now includes the new paragraph: "The token to use for the
response SHOULD be the token that was used in the highest block number
received payload.  The Q-Block1 Option from the same packet SHOULD be
included."

   Consistently, the example in Figure 5 should also have QB1:3/0/1024
in the 4.08 response with Token T:0xe3, and QB1:1/1/1024 in the 4.08
response with Token T:0xe4.

   Since "SHOULD" is used, when is it still fine or expected to not
include Q-Block1 in a 4.08 response?

* When commenting the example in Figure 5, Section 9.1 reads: "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."

   Should this not be aligned with the SHOULD used in Section 4 about
using the Token from the same packet conveying the highest block number?
  
   You explained in your mail that the client keeps tracking all Tokens
in the burst anyway, so maybe it's better to rather align the text in
Section 4 with what suggested here in Section 9.1, i.e. responding with
any of those Token values is just fine.
  
   In such a case, the Q-Block1 option included in the 4.08 response has
still to be the one from the request conveying the highest block number.
Correct?

* The new text in Section 6.2 says: "... and the situation re-evaluated
for another 24 hour period until there is no report of missing payloads
under normal operating conditions."

   When that happens, I suppose MAX_PAYLOADS is right away restored to
the intended value, i.e. it is not incremented by 1 to start another
24-hour period evaluation. Correct?

* Section 6.2 says: "The request that the client sends to acknowledge
the receipt of all the current set of MAX_PAYLOADS payloads SHOULD
contain a special case Q-Block2 Option with NUM set to the first block
of the next set of MAX_PAYLOADS payloads and the M bit set to 1."

  Is it possible to reflect this in the example of Figure 6? It would
require the body to have more than MAX_PAYLOADS blocks thus resulting in
more bursts, which would be inherited by the examples in Figure 7 and
Figure 8.

* In Section 9, it would be good to have the parameters defined in
Section 6.2 and their values reflected in the examples, when applicable.
E.g., MAX_PAYLOADS is at least 4 in these examples; the asked
retransmissions are presumably due sometimes to MAX_PAYLOADS compared
against the value of the latest received Q-Block1/Q-Block2, while
sometimes to NON_RECEIVE_TIMEOUT.

* In the example in Figure 6, shouldn't the first request from the
client have the M bit set to 1 in the Q-Block2 option, i.e. as
QB2:0/1/1024 ? As per Section 3.4, that would indicate that the request
is in fact for the block 0 and for all of the remaining blocks within
the body.

On 2021-01-06 16:24, [email-masked] wrote:
> can be found at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new-block%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=MlMoSqfzcxDvyO41nqA2GfZ7QqYFfeaHvN8fwH7jgTY%3D&amp;reserved=0
>
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=tEJ8tHhaLeWl4dtblsDzyli5TBSmfnRTxdepcwxhYzY%3D&amp;reserved=0

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se

---

From: <[email-masked]>
Date: Fri, 8 Jan 2021 13:33:42 -0000

Hi Marco,

Thanks for this - and it is good to have another set of eyes checking things through.

Updates have been pushed to https://github.com/core-wg/new-block and the differences with the draft can be found at https://www.ietf.org/rfcdiff?url1=draft-ietf-core-new-block&url2=https://raw.githubusercontent.com/core-wg/new-block/master/draft-ietf-core-new-block.txt 

Otherwise, please see inline.

Regards

Jon

> -----Original Message-----
> From: Marco Tiloca [mailto: [email-masked]]
> Sent: 07 January 2021 12:17
> To: [email-masked]; [email-masked]; draft-ietf-core-new-
> [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block
> 
> Hi,
> 

[Jon] Fixed.
> received payload.  The Q-Block1 Option from the same packet SHOULD be

[Jon] The Q-Block1 option actually is not needed as it can be derived by the client from the remembered token (which is used to derive the Request-Tag.
OLD
The Q-Block1 Option from the same packet SHOULD be included.
NEW
The client will use the token to match the request to find what Request-Tag value is
currently being used.  Providing the highest received block number
will aid any troubleshooting.

> 
>    Consistently, the example in Figure 5 should also have QB1:3/0/1024 in the
> 4.08 response with Token T:0xe3, and QB1:1/1/1024 in the 4.08 response
> with Token T:0xe4.

[Jon] No change now needed.
> 
>    Since "SHOULD" is used, when is it still fine or expected to not include Q-
> Block1 in a 4.08 response?

[Jon] Q-Block1 is no longer needed.
> just needs to be one of those that have been received for this Request-Tag,
> so the client can derive the Request-Tag."
> 
>    Should this not be aligned with the SHOULD used in Section 4 about using
> the Token from the same packet conveying the highest block number?

[Jon] Agreed
> 
>    You explained in your mail that the client keeps tracking all Tokens in the
> burst anyway, so maybe it's better to rather align the text in Section 4 with
> what suggested here in Section 9.1, i.e. responding with any of those Token
> values is just fine.

[Jon] I think that it is useful for the client to have a hint about what is the latest block number received even if it does not make use it - it may help in debugging from packet captures etc. which is why I added in the SHOULD in section 4.  So, I would prefer to align this with section 4
OLD
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.
NEW
The token used in the response should be the token that was used in the highest block number received payload. The client can then derive the Request-Tag by matching the token with the sent request..

> 
>    In such a case, the Q-Block1 option included in the 4.08 response has still
> to be the one from the request conveying the highest block number.
> Correct?
[Jon] We are now dropping the need for Q-Block1 in the response.
> 
> 
> * The new text in Section 6.2 says: "... and the situation re-evaluated for
> another 24 hour period until there is no report of missing payloads under
> normal operating conditions."
> 
> the intended value, i.e. it is not incremented by 1 to start another 24-hour
> period evaluation. Correct?
[Jon] Updated for clarification
OLD
        report of missing payloads under normal operating conditions. Note
        that the CoAP peer will not know about the MAX_PAYLOADS change until
NEW
        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
> 
> 
> * Section 6.2 says: "The request that the client sends to acknowledge the
> receipt of all the current set of MAX_PAYLOADS payloads SHOULD contain a
> special case Q-Block2 Option with NUM set to the first block of the next set
> of MAX_PAYLOADS payloads and the M bit set to 1."
> 
>   Is it possible to reflect this in the example of Figure 6? It would require the
> body to have more than MAX_PAYLOADS blocks thus resulting in more
> bursts, which would be inherited by the examples in Figure 7 and Figure 8.

[Jon] Examples updated to include this information
> 
> 
> * In Section 9, it would be good to have the parameters defined in Section
> 6.2 and their values reflected in the examples, when applicable.
> retransmissions are presumably due sometimes to MAX_PAYLOADS
> compared against the value of the latest received Q-Block1/Q-Block2, while

[Jon] Examples updated to include this information
> 
> 
> * In the example in Figure 6, shouldn't the first request from the client have
> the M bit set to 1 in the Q-Block2 option, i.e. as
> QB2:0/1/1024 ? As per Section 3.4, that would indicate that the request is in
> fact for the block 0 and for all of the remaining blocks within the body.
 
[Jon] Good catch - corrected.

~Jon
> > Responses part 2.  A new version (-04) of the draft has been published
> > and can be found at
> >
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> > tracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new-
> block%2F&amp;data=04%7C01
> >
> %7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a980
> 9cf0
> >
> bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnknown
> %7CTWFpb
> >
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0
> >
> %3D%7C2000&amp;sdata=MlMoSqfzcxDvyO41nqA2GfZ7QqYFfeaHvN8fwH7j
> gTY%3D&am
> > p;reserved=0
> >
> >
> > 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
> >
> > 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.
> >
> > [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 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.
> >
> >    it SHOULD  ignore the payload of the packet, but MUST still respond
> > as if the block was received for the first time.
> > [Jon] This text has already been updated following another review "OLD
> >    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
> > [Jon] See previous response, otherwise OLD
> >    a previous ETag for that resource as it is unlikely the missing
> > blocks can be retrieved.
> > [Jon] Again, we are not looking for a response (well, a request in
> > this case as needed by Block2), just an ACK OLD
> > [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.
> > Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE  in
> > response to a POST.
> > OLD
> > [Jon] Good question - it does make sense for the Request-Tag to be
> > tracked alongside the Token in the client.
> > OLD
> >       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.
> >
> > [Jon] RFC7252 does not require Tokens to be unique - e.g. empty token
> > values are acceptable.  Hence this statement.
> >> Congestion Control:
> >>
> > [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
> > [Jon] It is only GET or FETCH.  The intention here is to not request
> > bodies of data at too high a rate.
> > OLD
> > [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.
> > Control simple, the expectation is that all transmissions are NON or
> > (not recommended) are all CON. The draft now generally records this
> > expectation.
> >>   MAX_PAYLOADS and the answer to whether you may send
> MAX_PAYLOADS en
> >    Q-Block2 Options are removed as part of the block assembly and thus
> > do not reach the cache.
> > [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
> >    Request-Tag value.  Note that it cannot be assumed that the proxy
> > will always receive a complete body from a client.
> >> * Examples:
> >>
> > 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
> >    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.
> > 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
> > [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.
> > [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.
> > [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.
> > [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.
> >>   >
> > [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
> > [Jon] I am not convinced that this is necessarily the way to go.  The
> > new Congestion Control more cleanly handles this.
> > [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.
> > [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
> > [Jon] I think that this is covered by my update above with the text "
> > NEW
> > And in my previous part 1 response (updated) NEW
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.
> >
> ietf.org%2Fmailman%2Flistinfo%2Fcore&amp;data=04%7C01%7Cmarco.tiloc
> a%4
> >
> 0ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09
> ecc4
> >
> 0cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC
> >
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&
> amp;sd
> >
> ata=tEJ8tHhaLeWl4dtblsDzyli5TBSmfnRTxdepcwxhYzY%3D&amp;reserved=0
> 
> --
> Marco Tiloca
> Ph.D., Senior Researcher
>

---

From: Marco Tiloca <[email-masked]>
Date: Fri, 8 Jan 2021 16:57:23 +0100

Hi Jon,

Thanks, the changes look good. Just a few minor things.

* In Section 3.4, about the second case:

  - s/can continue to sent/can continue to send

  - It should be as explicit as in Section 6.2, i.e. "... 'NUM modulo
MAX_PAYLOADS' is zero, while NUM is not zero: ..."

  - The word "current" can be misleading, if its relation with the value
of NUM in the Q-Block2 option is not clarified. Based on the new example
in Figure 8, I think you mean the latest set completely transferred to
the client, whose last block has block number (NUM - 1). A possible
overall rephrasing can be:
 
  "This is used to confirm that the current set of MAX_PAYLOADS payloads
(the latest one having block number NUM-1) has been successfully
received and that, upon receipt of this request, the server can continue
to send the next set of payloads (the first one having block number
NUM). This is the 'Continue' Q-Block-2."

* In Section 3.4, about the third case: I guess you mean: "This is a
request for that block and for all of the remaining blocks in the
current MAX_PAYLOADS set."

* Section 4 says: "The token to use ... any troubleshooting."

   Do you actually mean the highest block number received so far under
that Request-Tag, or the highest within the current set of MAX_PAYLOADS
payloads for which the server is requesting some missing blocks?
  
   The new example in Section 5 seems to cover the latter, which I guess
is what you intend.

* In Section 9.2:

  - Figure 7, the request should have the M bit set, i.e. QB2:0/1/1024
  
  - Figure 8, the last response should have block number 10, i.e.
QB2:10/0/1024
  
  - Figure 10, all responses should have ET=24

Best,
/Marco

On 2021-01-08 14:33, [email-masked] wrote:
> Updates have been pushed to https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fnew-block&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C2385ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=LN79Z8Ar4AICnpWDOFgkFi3g0Mwf72KPC0ewPW%2FZk3A%3D&amp;reserved=0 and the differences with the draft can be found at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new-block%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew-block%2Fmaster%2Fdraft-ietf-core-new-block.txt&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C2385ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=gIc2vkC1XGtyGb17WSmby%2FO9wzA2bMaxDUsl3jmOAL4%3D&amp;reserved=0 
>
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ri.se%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C2385ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637457096666457035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=iJgJcxZmwbaLrbmzIuzSjezxDRq47wwWcNvFC7ox8bw%3D&amp;reserved=0
>>
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

---

From: <[email-masked]>
Date: Fri, 8 Jan 2021 17:17:23 -0000

Hi Marco,

Thanks for this.

The new updates have been pushed to https://github.com/core-wg/new-block and the differences with the draft can be found at https://www.ietf.org/rfcdiff?url1=draft-ietf-core-new-block&url2=https://raw.githubusercontent.com/core-wg/new-block/master/draft-ietf-core-new-block.txt

The PR for the responses below can be found at https://github.com/core-wg/new-block/pull/11 

Otherwise see inline.

Regards

Jon

> Sent: 08 January 2021 15:57

[Jon] Fixed
> MAX_PAYLOADS' is zero, while NUM is not zero: ..."

[Jon] Updated to be more explicit.
> 
>   - The word "current" can be misleading, if its relation with the value of
> NUM in the Q-Block2 option is not clarified. Based on the new example in
> Figure 8, I think you mean the latest set completely transferred to the
> client, whose last block has block number (NUM - 1). A possible overall
> rephrasing can be:
> 
> (the latest one having block number NUM-1) has been successfully received
> and that, upon receipt of this request, the server can continue to send the
> next set of payloads (the first one having block number NUM). This is the
> 'Continue' Q-Block-2."

[Jon] Thanks - gone with your suggestion
> 
> 
> * In Section 3.4, about the third case: I guess you mean: "This is a request for
> that block and for all of the remaining blocks in the current MAX_PAYLOADS
> set."
[Jon] Yes, updated.
>    Do you actually mean the highest block number received so far under that
> Request-Tag, or the highest within the current set of MAX_PAYLOADS
>    The new example in Section 5 seems to cover the latter, which I guess is
> what you intend.

[Jon] Not sure that it really makes any difference.  Have updated the text to try to clarify
OLD
The token to use for the response SHOULD be the token that was used in the highest block number received payload. Note that the use of any received token would work, but providing the one used in the highest received block number will aid any troubleshooting. The client will use the token to match the request to find what Request-Tag value is currently being used.
NEW
The token to use for the response SHOULD be the token that was used in the highest block number received so far with the same Request-Tag value. Note that the use of any received token with the same Request-Tag would work, but providing the one used in the highest received block number will aid any troubleshooting. The client will use the token to determine what is the previously sent request to obtain the Request-Tag value to be used.
>   - Figure 7, the request should have the M bit set, i.e. QB2:0/1/1024
[Jon] Fixed - you spotted this before and I broke it again with a cut 'n paste.
>   - Figure 8, the last response should have block number 10, i.e.
[Jon] Fixed
>   - Figure 10, all responses should have ET=24

[Jon] Fixed (I only found one)
~Jon
> > Updates have been pushed to
> >
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Fcore-wg%2Fnew-
> block&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7
> >
> C2385ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e
> 8%7
> >
> C0%7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMD
> >
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=
> LN79
> >
> Z8Ar4AICnpWDOFgkFi3g0Mwf72KPC0ewPW%2FZk3A%3D&amp;reserved=0
> and the
> > differences with the draft can be found at
> >
> > ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new-
> block%26url2%3Dhttps%3
> > A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew-
> block%2Fmaster%2Fdraf
> > t-ietf-core-new-
> block.txt&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C23
> >
> 85ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8%
> 7C0%
> >
> 7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiL
> >
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=gIc
> 2vkC
> > 1XGtyGb17WSmby%2FO9wzA2bMaxDUsl3jmOAL4%3D&amp;reserved=0
> >
> >> To: [email-masked]; [email-masked];
> >> draft-ietf-core-new- [email-masked]
> >> *  Section 4 now includes the new paragraph: "The token to use for
> >> the response SHOULD be the token that was used in the highest block
> >> number received payload.  The Q-Block1 Option from the same packet
> >> SHOULD be included."
> > [Jon] The Q-Block1 option actually is not needed as it can be derived by
> the client from the remembered token (which is used to derive the
> Request-Tag.
> > OLD
> > The client will use the token to match the request to find what
> > Request-Tag value is currently being used.  Providing the highest
> > received block number will aid any troubleshooting.
> >
> >> 4.08 response with Token T:0xe3, and QB1:1/1/1024 in the 4.08
> >> * When commenting the example in Figure 5, Section 9.1 reads: "The
> >>    You explained in your mail that the client keeps tracking all
> >> Tokens in the burst anyway, so maybe it's better to rather align the
> >> text in Section 4 with what suggested here in Section 9.1, i.e.
> >> responding with any of those Token values is just fine.
> > [Jon] I think that it is useful for the client to have a hint about
> > what is the latest block number received even if it does not make use
> > it - it may help in debugging from packet captures etc. which is why I
> added in the SHOULD in section 4.  So, I would prefer to align this with
> section 4 OLD The Token just needs to be one of those that have been
> received for this
> > The token used in the response should be the token that was used in the
> highest block number received payload. The client can then derive the
> Request-Tag by matching the token with the sent request..
> >
> >>    In such a case, the Q-Block1 option included in the 4.08 response
> >> has still to be the one from the request conveying the highest block
> number.
> >> Correct?
> >> * The new text in Section 6.2 says: "... and the situation
> >> re-evaluated for another 24 hour period until there is no report of
> >> missing payloads under normal operating conditions."
> >>
> >>    When that happens, I suppose MAX_PAYLOADS is right away restored
> >> to the intended value, i.e. it is not incremented by 1 to start
> >> another 24-hour period evaluation. Correct?
> >         that the CoAP peer will not know about the MAX_PAYLOADS change
> > until NEW
> >> contain a special case Q-Block2 Option with NUM set to the first
> >> block of the next set of MAX_PAYLOADS payloads and the M bit set to 1."
> >>
> >> require the body to have more than MAX_PAYLOADS blocks thus
> resulting
> >> in more bursts, which would be inherited by the examples in Figure 7 and
> Figure 8.
> >> Section
> compared
> >> QB2:0/1/1024 ? As per Section 3.4, that would indicate that the
> >> request is in fact for the block 0 and for all of the remaining blocks within
> the body.
> >
> >>> 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
> >>>
> >>> 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.
> >>>
> >>> 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
> >>> 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.
> >>>
> >>>    it SHOULD  ignore the payload of the packet, but MUST still
> >>> respond as if the block was received for the first time.
> >>> "OLD If the server receives multiple requests
> >>> no payload. It can be used in the request if the client wants to
> >>> check the freshness of the currently cached body response.
> >>>
> >>> 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.
> >>>
> >>>       Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit
> >>> the array count to
> >>> [Jon] RFC7252 does not require Tokens to be unique - e.g. empty
> >>> token values are acceptable.  Hence this statement.
> >>>> Congestion Control:
> >>>>
> >>> was not the individual packets that are subject to PROBING_RATE, but
> >>> a single body comprising of multiple packets is subject to
> >>> PROBRING_RATE
> >>>    Each NON GET or FETCH request using Q-Block2 Option is subjected
> >>> to PROBING_RATE.
> >>> [Jon] Now limited to 247 seconds (NON_PROBING_WAIT).  See re-write
> >>> of Congestion Control section.
> >>> [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.
> >>>    Q-Block2 Options are removed as part of the block assembly and
> >>> thus do not reach the cache.
> >>> [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.).
> >>> 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.
> >>> [Jon] 100+ seconds delay is way too much time to wait for any
> >>> missing blocks in my opinion.
> >>>
> >>> [Jon] I am not convinced that this is necessarily the way to go.
> >>> The new Congestion Control more cleanly handles this.
> >>> 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.
> >>> [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
> >>> 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
> w
> .ri.se%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C2385ef89ef574a7
> c8
> >>
> 1f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637
> 45709
> >>
> 6666457035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMz
> >>
> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=iJgJcxZmwbaLrb
> mzIuz
> >> SjezxDRq47wwWcNvFC7ox8bw%3D&amp;reserved=0
> >>
> >
> 
> --
> Marco Tiloca
> Ph.D., Senior Researcher
>

---

From: Marco Tiloca <[email-masked]>
Date: Fri, 8 Jan 2021 19:18:30 +0100

Hi Jon,

> Thanks for this.

~snips

> The token to use for the response SHOULD be the token that was used in the highest block number received so far with the same Request-Tag value. Note that the use of any received token with the sam…

==>MT
Looks better.

To clarify, I meant Figure 5 (not Section 5), where the response with
Message ID M:0x91 uses Token T:0xe0. That's matching with the request
with Message ID M:0x19, i.e. the received payload with the highest block
number *in the current MAX_PAYLOADS payload set* to be still completed.

If the SHOULD above was followed, that response would have Token T:0xeb,
to match with the one used in "the highest block number received so
far", i.e. block number 10 in the request with Message ID M:0x1b.

But as per the text above, either Token value is fine to use in the
response, so the example is correct anyway.
<==

> [Jon] Fixed (I only found one)

==>MT
The other occurrence is the very last response, with Message ID M:0x9b :-)

Otherwise, it looks good to me. Thank you!

Best,
/Marco
<==

>>> until
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ri.se%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C8651a67881364348422608d8b3f94057%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637457230862239405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=po%2BnNJAbUW7Jf9cMFxoP8VXDd1%2FfS%2BsyTl4dePY5A9o%3D&amp;reserved=0
>>
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

---

From: <[email-masked]>
Date: Mon, 11 Jan 2021 10:33:10 -0000

Hi Marco,

The PR for the responses below can be found at https://github.com/core-wg/new-block/pull/12 (a couple of minor nits fixed since then which are in master)

Otherwise lease see inline.

Regards

Jon

> Sent: 08 January 2021 18:19
> To:[email-masked]; [email-masked]; draft-ietf-core-new-
> [email-masked]
> >>    Do you actually mean the highest block number received so far
> >> under that Request-Tag, or the highest within the current set of
> >> MAX_PAYLOADS payloads for which the server is requesting some
> missing blocks?
> >>
> >>    The new example in Section 5 seems to cover the latter, which I
> >> guess is what you intend.
> > [Jon] Not sure that it really makes any difference.  Have updated the
> > text to try to clarify OLD The token to use for the response SHOULD be
> > the token that was used in the highest block number received payload.
> Note that the use of any received token would work, but providing the one
> used in the highest received block number will aid any troubleshooting. The
> client will use the token to match the request to find what Request-Tag
> value is currently being used.
> > NEW
> > The token to use for the response SHOULD be the token that was used in
> the highest block number received so far with the same Request-Tag value.
> Note that the use of any received token with the same Request-Tag would
> work, but providing the one used in the highest received block number will
> aid any troubleshooting. The client will use the token to determine what is
> the previously sent request to obtain the Request-Tag value to be used.
> 
> ==>MT
> Looks better.
> 
> to match with the one used in "the highest block number received so far",
> i.e. block number 10 in the request with Message ID M:0x1b.
> 
> But as per the text above, either Token value is fine to use in the response,
> so the example is correct anyway.

[Jon] Changed highest to last (to simplify things), updated the examples accordingly. Updated 2.01,2.04 and 2.31 code with which token to use.
> The other occurrence is the very last response, with Message ID M:0x9b :-)

[Jon] Got it - And M:0x9b updated to M:0xc3 to be consistent.
~Jon
> >>> Thanks for this - and it is good to have another set of eyes
> >>> checking things
> >> through.
> >>>> Token just needs to be one of those that have been received for
> >>>> this Request-Tag, so the client can derive the Request-Tag."
> >>>>
> >>>>    Should this not be aligned with the SHOULD used in Section 4
> >>>> about using the Token from the same packet conveying the highest
> >>>> block
> >> number?
> >>> [Jon] Agreed
> >>>> Tokens in the burst anyway, so maybe it's better to rather align
> >>>> the text in Section 4 with what suggested here in Section 9.1, i.e.
> >>> what is the latest block number received even if it does not make
> >>> use it - it may help in debugging from packet captures etc. which is
> >>> why I
> >> added in the SHOULD in section 4.  So, I would prefer to align this
> >> with section 4 OLD The Token just needs to be one of those that have
> >> been received for this
> >>>>    In such a case, the Q-Block1 option included in the 4.08
> >>>> response has still to be the one from the request conveying the
> >>>> highest block
> >> number.
> >>>> Correct?
> >>>         that the CoAP peer will not know about the MAX_PAYLOADS
> >>> change until NEW
> >>>         report of missing payloads under normal operating
> >>> conditions. The
> >> newly
> >>>> * Section 6.2 says: "The request that the client sends to
> >>>> acknowledge the receipt of all the current set of MAX_PAYLOADS
> >>>> payloads SHOULD contain a special case Q-Block2 Option with NUM set
> >>>> to the first block of the next set of MAX_PAYLOADS payloads and the M
> bit set to 1."
> >>>>
> >>>>   Is it possible to reflect this in the example of Figure 6? It
> >>>> would require the body to have more than MAX_PAYLOADS blocks thus
> >> resulting
> >>>>> Part 1 responses were covered in the main by version -03, so you
> >>>>> may want to look at the -02 to -04 differences.
> >>>>>
> >>>>> 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
> >>>>>
> >>>>> [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
> >>>>> 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
> >>>>>   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
> >>>>> token in the 4.08 (Request Entity Incomplete) response.  The
> >>>>> server on receipt of the reset message SHOULD delete the partial
> body.
> >>>>> END
> >>>>>
> >>>>>>   This might be read as "ever" rather than "per incoming
> >>>>>> request",
> >> where
> >>>>> 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.
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> 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
> >>>>>    response, the client should remove any partially received body
> >>>>> held
> >> for
> >>>>> 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.
> >>>>>> * "First is CBOR encoded Request-Tag": Why? Each 4.08 response
> >>>>>> can
> >> be
> >>>>>        missing-block-number = uint NEW
> >>>>>   missing payloads using the same Request-Tag, Size1 and Q-Block1
> >>>>> to specify the block number, SZX, and M bit as appropriate.
> >>>>>
> >>>>>
> >>>>>       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.
> >>>>> [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
> >>>>> responded to based on PROBING_RATE exceeds
> NON_PROBING_WAIT,
> >>>> then the
> >>>>>>    On the other hand, *ever* NON request is subject to
> >>>>>> PROBING_RATE,
> >> so
> >>>>> [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 FETCH request using Q-Block2 Option is
> >>>>> subjected to PROBING_RATE.
> >>>>>>   increased PROBING_RATE (however externally determined) and
> from
> >>>> the
> >>>>>>   point of MAX_PAYLOADS just observe it. Or it has to get
> >>>>>> feedback
> >> from
> >>>>> [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
> >>>>> 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
> >>>>>> * "are not part of the cache key": How about "are removed as part
> >>>>>> of
> >> the
> >>>>>>   chooses not to let them happen in parallel (which it may, see
> >>>>>> above
> >> on
> >>>>> 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
> >>>>>    Request-Tag value.  Note that it cannot be assumed that the
> >>>>> proxy will always receive a complete body from a client.
> >>>>>> * Examples:
> >>>>>>
> >>>>>>     MAX_TRANSMIT_SPAN before sending the 4.08 response. I
> suppose
> >>>> there
> >>>>> 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
> >>>>> 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] 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
> >>>>>> * General on MAX_TRANSMIT_SPAN and other timing parameters:
> I'm
> >> not
> >>>>>> sure
> >>>>> So BANDWITH of 1Mbps has negligible effect on the calculation.
> >>>>> 1Kbps makes MAX_BLOCK_JITTER 200 seconds.
> >>>>>>   >
> >>>>> [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
> >>>>> [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
> >>>>> transmitting the next set of MAX_PAYLOADS payloads without the
> >>>>> need to wait any
> >>>> longer.
> >>>>>>   burst would mark that connection as unusable for about 3 hours
> >>>>>> if
> >> they
> >>>>> transmission, the server continues to acknowledge  each packet,
> >>>>> but a response is not required (whether separate or
> .ri.se%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C8651a6788136434
> 84
> >>
> 22608d8b3f94057%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637
> 45723
> >>
> 0862239405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMz
> >>
> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=po%2BnNJAbUW
> 7Jf9cMF
> >> xoP8VXDd1%2FfS%2BsyTl4dePY5A9o%3D&amp;reserved=0
> >>
> >
> 
> --
> Marco Tiloca
> Ph.D., Senior Researcher
>

---

From: Marco Tiloca <[email-masked]>
Date: Mon, 11 Jan 2021 12:38:47 +0100

Hi Jon,

Thanks, the updates look good.

As to the response codes in Section 3.3 "Using the Q-Block1 Option", 
wouldn't it make sense to mention also 2.05 (Content) ? Think of a FETCH
request with a big body, which is actually mentioned at the beginning of
Section 3.3 and in Section 3.1 (though missing the 2.05 response code
beside it).

Also, more in general, think of an observe registration, for which the
server eventually sends back a first notification (possibly split into
multiple payloads) with Q-Block2, with a certain Token value.

If the observation request used FETCH and was fragmented into several
payloads with Q-Block1, each of which with a different Token, it's still
true that the notifications can all have any of those Token values and
should have the one of the last received request payload.

However, later on the client has to retain that Token value as the one
associated to the observation, to match future notifications to come. In
this case, there is a deviation from the claim used for other response
codes, i.e. "The client should then release all of the tokens used for
this body." This should concern only 2.01 notifications (hence including
the Observe option) in response to observation requests with FETCH, so
it can be limited to the context of this section about Q-Block1.

Best,
/Marco

On 2021-01-11 11:33, [email-masked] wrote:
> Hi Marco,
>
> The new updates have been pushed to https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fnew-block&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C2744bb09ef5945b3d89808d8b61c4788%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459580455245128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ost7IW3KRdzPcvhj6NWjtypuEBpTlLQYYprW2T0tekk%3D&amp;reserved=0 and the differences with the draft can be found at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new-block%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew-block%2Fmaster%2Fdraft-ietf-core-new-block.txt&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C2744bb09ef5945b3d89808d8b61c4788%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459580455250109%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=h%2FG4febnGfQJJzEJFXCXEuBwAGNPlDPzub32L%2FLceUI%3D&amp;reserved=0
>
> The PR for the responses below can be found at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fnew-block%2Fpull%2F12&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C2744bb09ef5945b3d89808d8b61c4788%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459580455250109%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=jUmBoUDRubJVXoq2jcvvgZJ1ZVPtJUhKMX%2BEeZ0gtT4%3D&amp;reserved=0 (a couple of minor nits fixed since then which are in master)
>
>>>>> change until
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ri.se%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C2744bb09ef5945b3d89808d8b61c4788%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459580455250109%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=QKcdNBcFq%2BaG5omNRN1UjaRJ2E5EV%2FRiw0%2BQ%2FfuSyK0%3D&amp;reserved=0
>>
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

---

From: <[email-masked]>
Date: Mon, 11 Jan 2021 16:39:14 -0000

Hi Marco,

It is good that you are thinking this properly through.  FETCH was added later into this draft and the consequences were not properly thought through.

The PR for the responses below can be found at https://github.com/core-wg/new-block/pull/13 

Otherwise, see inline.

Regards

Jon

> Sent: 11 January 2021 11:39

[Jon] Thanks
> Section 3.3 and in Section 3.1 (though missing the 2.05 response code

[Jon] Thanks - added.  Also added in 2.02 and 2.05 as being expected response codes in 3.3.

[Jon] For the 2.02,  I struggle with why anyone would want to use a POST with a large payload to cause the resource to get deleted (instead of using DELETE) , but RFC7252 allows this to happen.

OLD
   Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH,
   PATCH, and iPATCH requests and their responses (2.01 and 2.04).
NEW
Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH, PATCH, and iPATCH requests and their responses (2.01, 2.02, 2.04, and 2.05).

[Jon] And added into 3.3 (2.05 is done further into this discussion)

NEW
2.02 (Deleted)

This Response Code indicates successful receipt of the entire body and the resource was deleted when using POST (See Section 5.8.2 [RFC7252]). The token used SHOULD be from the last received payload. The client should then release all of the tokens used for this body.

[Jon] OK
> should have the one of the last received request payload.

Jon[OK]
> it can be limited to the context of this section about Q-Block1.

[Jon] I was not aware that FETCH could return 2.01 or 2.04.  GET does not return these codes and it is only GET and FETCH that can Observe.  However, it is true what you say for 2.05, so I have added that the tracked Observe token must be the (if Q-Block1) the one used for Q-Block1 that has the M bit unset.  I have added in some FETCH examples into the draft.

NEW
2.05 (Content)

This Response Code indicates successful receipt of the entire FETCH request body (See Section 2 [RFC8132]) and the appropriate representation of the resource has been returned. The token used in the response MUST be the one in the FETCH request that has the Q-Block1 with the M bit unset. If the FETCH request includes the Observe Option, then the server MUST use the same token for returning any Observe triggered responses. The client should then release all of the tokens used for this body unless a resource is being observed.

~jon
> /Marco

<snip>

---

From: Marco Tiloca <[email-masked]>
Date: Mon, 11 Jan 2021 20:23:07 +0100

Hi Jon,

Thanks for the fast reaction. Please, see inline.

Best,
/Marco

On 2021-01-11 17:39, [email-masked] wrote:
> The new updates have been pushed to https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fnew-block&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C4c6021fd365344ae633908d8b64f6af1%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459799554192170%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=P5eiQyl8meRhZX9t6gtNqwc29ryqLRGnOUwmFQxAydo%3D&amp;reserved=0 and the differences with the draft can be found at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new-block%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew-block%2Fmaster%2Fdraft-ietf-core-new-block.txt&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C4c6021fd365344ae633908d8b64f6af1%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459799554197148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=IYKVrC1a56Cva5mR4xoM0VM5y6dhjtQ7M6L5PwlCqzA%3D&amp;reserved=0
>
> The PR for the responses below can be found at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fnew-block%2Fpull%2F13&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C4c6021fd365344ae633908d8b64f6af1%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459799554197148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=b9hq1V5X136oGB65e9Ni12V0weXoNa%2FY1DT8QtzFRqQ%3D&amp;reserved=0 
>
> Otherwise, see inline.
>
> Regards
>
> Jon
>

==>MT
Looks good.
<==

> [Jon] For the 2.02,  I struggle with why anyone would want to use a POST with a large payload to cause the resource to get deleted (instead of using DELETE) , but RFC7252 allows this to happen.

==>MT
If it's really about the client just asking to delete a resource, then a
DELETE is more efficient.

But, the client might just be asking the server to process its POST
payload, and it's the server that eventually takes the decision to
delete the resource, as a possible side-effect following the request
processing.

I think that's what the "if" wanted to suggest in RFC 7252, Section
5.8.2: "If the POST succeeds and results in the target resource being
deleted, the response SHOULD have a 2.02 (Deleted) Response Code."

Alternatively, the client may actually want to delete the resource as
somehow indicated in the payload, only following the processing of the
rest of the payload. This would not be possible with a DELETE (that has
no payload) and if supported by the application it is more efficient
than sending first a POST and then a DELETE.
<==

> Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH, PATCH, and iPATCH requests and their responses (2.01, 2.02, 2.04, and 2.05).

==>MT
Looks good.
<==

> This Response Code indicates successful receipt of the entire body and the resource was deleted when using POST (See Section 5.8.2 [RFC7252]). The token used SHOULD be from the last received payloa…

==>MT
Looks good.
<==

> [Jon] I was not aware that FETCH could return 2.01 or 2.04.  GET does not return these codes and it is only GET and FETCH that can Observe.  

==>MT
Oops, I actually meant 2.05 in the paragraph above. Sorry for the confusion.
<==

> However, it is true what you say for 2.05, so I have added that the tracked Observe token must be the (if Q-Block1) the one used for Q-Block1 that has the M bit unset.  I have added in some FETCH examples into the draft.
>
> NEW
> 2.05 (Content)
>

==>MT
Looks good.

As to the two new examples in Figures 11 and 12, please add the Observe
option with value 0 to the requests from the client, i.e. O:0, just like
you do in Figures 7 and 8.

Best,
/Marco
<==

-- 
Marco Tiloca
Ph.D., Senior Researcher

---

From: <[email-masked]>
Date: Tue, 12 Jan 2021 07:21:42 +0000

Hi Marco, all, 

With regards to 2.02, RFC7959 says the following: 

   Hence, for the methods defined in [RFC7252], Block1 is useful with
   the payload-bearing POST and PUT requests and their responses.
   Block2 is useful with GET, POST, and PUT requests and their payload-
   ^^^^^^                                                     ^^^^^^^^
   bearing responses (2.01, 2.02, 2.04, and 2.05 -- see Section 5.5 of
   ^^^^^^^^                 ^^^^
   [RFC7252]).

Which we think is broken. 

We don't echo that part in the new-block. 

Should we fill an errata against this?

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de Marco Tiloca
> Envoyé : lundi 11 janvier 2021 20:23
> À : [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Objet : Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block
> 
> Hi Jon,
> 
> >> response code beside it).

---

From: Marco Tiloca <[email-masked]>
Date: Tue, 12 Jan 2021 10:09:39 +0100

Hi Med,

Could you clarify why that part is broken?

From RFC 7252, Section 5.9.1.2  "2.02 Deleted" says:

   "This Response Code is like HTTP 204 "No Content" but only used in
response to requests that cause the resource to cease being available,
such as DELETE and, in certain circumstances, POST. The payload returned
with the response, if any, is a representation of the action result."

So, a 2.02 response can follow a POST request, and it can have a
payload, which might be split using Block2.

Best,
/Marco

-- 
Marco Tiloca
Ph.D., Senior Researcher

---

From: <[email-masked]>
Date: Tue, 12 Jan 2021 09:27:05 +0000

Re-,

The concern is what to put in that paylaod if the resource does not exist:

   If the POST succeeds and results in the target resource being
   deleted, the response SHOULD have a 2.02 (Deleted) Response Code.

Cheers,
Med

> De : Marco Tiloca [mailto:[email-masked]]
> Envoyé : mardi 12 janvier 2021 10:10
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
>    "This Response Code is like HTTP 204 "No Content" but only used
> in response to requests that cause the resource to cease being
> available, such as DELETE and, in certain circumstances, POST. The
> payload returned with the response, if any, is a representation of
> the action result."
> 
> >    ^^^^^^
> ^^^^^^^^
> >> Envoyé : lundi 11 janvier 2021 20:23 À : supjps-
> [email-masked];
> >> [email-masked]; [email-masked];
> >> [email-masked]
> ____________________________________________________________________
> __
> > ___________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce
> message
> > par erreur, veuillez le signaler a l'expediteur et le detruire
> ainsi que les pieces jointes. Les messages electroniques etant
> susceptibles d'alteration, Orange decline toute responsabilite si ce
> message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should
> not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender
> and delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that
> have been modified, changed or falsified.
> > Thank you.
> >
> 
> --
> Marco Tiloca
> Ph.D., Senior Researcher
>

---

From: <[email-masked]>
Date: Tue, 12 Jan 2021 15:26:10 -0000

Hi Marco and all,

Need clarity on how to do a (Q-)Block2 request for a specific block when the request needs (Q-)Block1.

Adding in the Observe option into Figures 11 & 12 caused other things to be updated (text is being updated) - e.g. the Observe option needs to be set on all of the Q-Block1 payloads making up the body.

However, I have run into not being sure what to do when a request needs Q-Block1 and the response needs Q-Block2 - and then we need to recover a missing Q-Block2 block.  Med and I have been discussing this offline. 

In the case of Q-Block1/Q-Block2 it is about what is the request needed to get a missing Q-Block2 block. In the case of Block1/Block2 it is all about the request needed to get the next Block2 block.

For whatever reason, a (Q-)Block2 block needs to be requested.  Given that the request has used (Q-)Block1 to handle the large body, do we just need to use the request method and matching options (with appropriate (Q-)Block2 NUM) without the payload, or do we have to use the payload as well and hence use multiple packets for the complete request?

If the server is caching the response, then a match can just be done on the cache-key if formed right.

If the server does not cache the response, then when using a FETCH, the FETCH will need to have the body to regenerate the response.

The closest I can find to this is in 2.7 rfc7959 which has

" In PUT and particularly in POST exchanges, both the request body and
   the response body may be large enough to require the use of block-
   wise transfers.  First, the Block1 transfer of the request body
   proceeds as usual.  In the exchange of the last slice of this block-
   wise transfer, the response carries the first slice of the Block2
   transfer (NUM is zero).  To continue this Block2 transfer, the client
   continues to send requests similar to the requests in the Block1
   phase, but leaves out the Block1 Options and includes a Block2
   request option with non-zero NUM."

In particular note the occurrence of the second "requests"  is plural in this line.
"   continues to send requests similar to the requests in the Block1
   phase"

This implies to me that there are multiple requests needed to make up the request with a full body to ask for a single block and that is the way to go - correct?

Secondly,

For a FETCH to cancel an Observe, again I can find no text giving clarity (as there are no references to payload), but have to assume that FETCH needs to be identical (apart from message id and Observe value which is now 1) including the payload - correct?

Regards

Jon

PS - We have worked out the wording for the 2.02 response.

> From: Marco Tiloca [mailto:[email-masked]]
> Sent: 11 January 2021 19:23
<snip>
> option with value 0 to the requests from the client, i.e. O:0, just like you do
> in Figures 7 and 8.
> 
> Best,
> /Marco
> <==
>