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

From: Marco Tiloca <[email-masked]>
Date: Mon, 7 Dec 2020 18:35:28 +0100

Dear all,

Following the recent clarifications from the authors [1], this mail
starts a Working Group Last Call on:

https://tools.ietf.org/html/draft-ietf-core-new-block-02

This WGLC will end on Tuesday, 22nd of December.

This WGLC is also copied to the DOTS WG mailing list.

Best,
Marco and Jaime

[1] https://mailarchive.ietf.org/arch/msg/core/MJRxWldea5EOchYJRBOmkdvjiLI/

-- 
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: Marco Tiloca <[email-masked]>
Date: Mon, 21 Dec 2020 09:10:02 +0100

Hi all,

Please, see below some comments for this WGLC.

Best,
/Marco

[General]

* s/CoAP endpoint sender/CoAP sender endpoint

* Please, replace the references to RFC 7049 with references to RFC 8949.

* There are six instances of "CoAP session", which is not defined in RFC
7252 or RFC 7959. Do you simply mean "block-wise transfer" ?

[Section 1]

* I think that the heading of the current Section 1.1 can be removed, so
that Section 1 starts simply with "The Constrained Application Protocol ..."

* s/and further updated/and was further updated

* s/loss; which/loss, which

* s/informs the CoAP endpoint sender either successful receipt or/either
informs the CoAP sender endpoint of a successful receipt or

* s/that have been not yet been received/that have not yet been received

* s/will both generally/will both be generally

* The last paragraph in Section 1.4 can be expanded to mention OSCORE as
an alternative when DTLS is not used.

[Section 3.4]

* As to "If the server receives multiple requests (implied or otherwise)
for the same block ..." , I guess the word "requests" does not mean CoAP
requests, since the paragraph is talking about a single actual CoAP
request. In fact, it seems to refer to the multiple needed blocks
indicated by the multiple Q-Block2 options in a same CoAP request.

   If I'm interpreting correctly, this tries to cover a strange behavior
from the client that sends multiple Q-Block2 Options in a same CoAP
requests with the M bit set, such as: 2/1/1024 , 3/1/1024, 4/1/1024; but
still the server has to send back blocks 2, 3, 4 ... until the last one
only once each.
  
   If this is correct, how about the following rephrasing?
  
   "If the request includes multiple Q-Block2 Options and asks for a
same block multiple times (e.g., through the M bit set), the server MUST
only send back one instance of that block.

* s/if this is the case/if this is not the case

* s/Option whichever is/Option, whichever is

[Section 3.7]

* s/and MUST have the same value/and MUST preserve the same value in
each of those payloads.

(just to avoid reading it as Size1 and Size2 must have the same value)

[Section 9]

* I suggest to add one more example in the end, where Q-Block2 is used
in a request with the M bit set. As a separate continuation of the
example in Figure 7, this can be the case where, after observe being
triggered one more time, only the first block for a new ET=24 reaches
the client, which can use a single QB2:1/1/1024.

[Section 11]

* As mentioned for Section 1, more can be said here for when OSCORE is used.

-- 
Marco Tiloca
Ph.D., Senior Researcher

---

From: <[email-masked]>
Date: Tue, 22 Dec 2020 18:01:26 +0000

Hi Marco, 

Many thanks for the comments.

All good points. We released a new version that addresses those. A diff to track the changes can be seen at: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-new-block-03

Cheers,
Jon & Med

> -----Message d'origine-----
> De : core [mailto:[email-masked]] De la part de Marco Tiloca
> Envoyé : lundi 21 décembre 2020 09:10
> À : [email-masked] WG ([email-masked]) <[email-masked]>
> Cc : [email-masked]
> Objet : Re: [core] WG Last Call on draft-ietf-core-new-block
> 
> Hi all,
> 
> * I think that the heading of the current Section 1.1 can be
> removed, so that Section 1 starts simply with "The Constrained
> Application Protocol ..."
> 
> * s/informs the CoAP endpoint sender either successful receipt
> or/either informs the CoAP sender endpoint of a successful receipt
> or
> 
> * The last paragraph in Section 1.4 can be expanded to mention
> OSCORE as an alternative when DTLS is not used.
> 
> 
> [Section 3.4]
> 
> * As to "If the server receives multiple requests (implied or
> otherwise) for the same block ..." , I guess the word "requests"
> does not mean CoAP requests, since the paragraph is talking about a
> single actual CoAP request. In fact, it seems to refer to the
> multiple needed blocks indicated by the multiple Q-Block2 options in
> a same CoAP request.
> 
>    If I'm interpreting correctly, this tries to cover a strange
> behavior from the client that sends multiple Q-Block2 Options in a
> same CoAP requests with the M bit set, such as: 2/1/1024 , 3/1/1024,
> 4/1/1024; but still the server has to send back blocks 2, 3, 4 ...
> until the last one only once each.
> 
> same block multiple times (e.g., through the M bit set), the server
> MUST only send back one instance of that block.
> 
> * I suggest to add one more example in the end, where Q-Block2 is
> used in a request with the M bit set. As a separate continuation of
> the example in Figure 7, this can be the case where, after observe
> being triggered one more time, only the first block for a new ET=24
> reaches the client, which can use a single QB2:1/1/1024.
> 
> 
> [Section 11]
> 
> > [1]
> https://mailarchive.ietf.org/arch/msg/core/MJRxWldea5EOchYJRBOmkdvji
> LI
> > /
> >
> 
> --
> Marco Tiloca
> Ph.D., Senior Researcher
> 

_________________________________________________________________________________________________________________________

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: Christian Amsüss <[email-masked]>
Date: Wed, 23 Dec 2020 06:00:42 +0100

Hello new-block authors, hello CoRE,

I've finally managed to have another look at the document (and it's
still the 22nd *somewhere*...).

My over-all summary is that while this document has matured quite a bit
(and turned out better than I had expected for the special-purpose
blocks it is), I think that the topic of response suppression and
congestion control sections still have to be sharpened, and the examples
could pick a more realistic balance between going all-NON and all-CON
(or explain why that's something that wouldn't be done even though the
text reads like that's what's expected to be used but maybe it's just
me).

Except for the first item (which is coming back to the notes for the
WGLC), all should be more or less sequential in the document (with
forward/back references as needed).

* On the downref to No-Response: I don't see the downref as too big an
  issue. It's a bit odd that that document didn't go through the CoRE
  WG, but my impression is that it's widely used (on a "when the library
  I maintain broke it people filed issues" level), and both OSCORE and
  groupcomm-bis (which is to replace RFC7390) reference it. It's an
  informative reference because they don't mechanically depend on it,
  but it shows how well No-Response has been taken up.

  (Frankly, I'd support a retroactive adoption. I don't suppose we can
  do that with "adults"?).

  From how I understand Q-Block to be intended to work, No-Response does
  not cover all of the behavior (as it's timeout based); still, that
  document lays good groundwork for what's done here in a rather precise
  way (see comment on "For Confirmable transmission, the server MUST
  continue" later on) where this document needs the examples to be fully
  understood.

  Based on the later text on MAX_TRANSMIT_SPAN, why not at least
  acknowledge the equivalence? Maybe like this:

  > The behavior of endpoints following this draft can equivalently b
  > described in terms of the No-Response option {{?RFC7967}}:
  >
  > For a message with a Q-Block1 option with M=1 that is followed by
  > another message on the same Request-Tag within MAX_TRANSMIT_SPAN [
  > or MAX_BLOCK_JITTER, see later ], the default value for No-Response
  > is 8 (suppressing the 4.xx code that would be returned due to the
  > incomplete request); an explicitly set No-Response option would
  > override that."

  although I'd still advocate just using No-Response for the whole
  definition even if No-Response is not typically expressed.

  (I'm not really sure what the correct response would be for an
  individual non-terminal request if it were to be answered due to an
  explicit No-Response:0 -- might be 2.31 Continue that's just not
  used in this specification because it's always suppressed? I'll come
  back to that -- but then it'd rather be No-Response: 10).

* intro: WebSockets (capitalization)

* 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:

  * The Q-Block options do not support stateless operation / random
    access.

  * Proxying of Q-Block is limited to caching full representations.

  (The latter might be mitigated by additional text around caching, but
  I doubt it's worth the effort given it's not part of the use case).

* "compromises of": I don't understand that sentence.

* "the asymmetrical packet loss is not a benefit here": It never is;
  what is meant here?

* "Updated CoAP Response Code": "This document updates" sounds like a
  formal update to RFC7959, which it neither is nor needs to be.
  Phrasing it along the lines of "adds a media type that can be used
  with 4.08" would ease that.

* "Only C and U columns are marked": "The Q-Block1 option is critical, and
  unsafe for proxies to forward" would be easier to read -- which
  checkboxes are marked is visible alrady from the table. (Or just leave
  it for the later paragraphs that say that in more detail).

* "Q-Block1 Option is useful with": ... and FETCH. (Also in "Using the
  Q-Block1 option" first paragraph).

* "Is opaque in nature, but it is RECOMMENDED" on being a counter and
  starting off random: Like other similar suggestions (ETag), this is
  implementation guidance level and not required for interoperability.
  Maybe phrase this the same way as the recommendations on tokens?

* "For Confirmable transmission, the server MUST continue": This reads
  like new-block could change anything about that, when all it does is
  do things on the response level. [1] has a good note on that
  separation topic.

  [1]: https://tools.ietf.org/html/rfc7967#section-2

* "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. 

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

* "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.

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

* "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".

* "For Confirmable transmission, the client SHOULD continue to": As
  above in the other direction, that's not news.

* "If there is insufficient space to create a response PDU": I don't
  understand what that means. (Where are request options reflected
  back?).

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

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

* "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.

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

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?

   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?

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

  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.

* "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...".

* "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.

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

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"?

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

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

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

  * If that e4 response gets lost, does the whole mechanism recover from
    it in any way?

    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.

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

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

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

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

  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?

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

  I don't know if it needs additional justification, but an increased
  N_START may be justifiable there.

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

Best regards
Christian

-- 
There's always a bigger fish.
  -- Qui-Gon Jinn

---

From: <[email-masked]>
Date: Thu, 24 Dec 2020 09:40:13 -0000

Hi Christian,

Thanks for this and the time spent thinking about it.  Some items have
already become separate threads.

Otherwise responses inline - part 1.  Some of the changes can be seen at
https://tinyurl.com/new-block-latest 

Regards

Jon

> -----Original Message-----
> From: Christian Amsüss [mailto: [email-masked]]
> Sent: 23 December 2020 05:01
> To: [email-masked]
> Cc: [email-masked]; [email-masked] WG ([email-masked])
> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block
> 
> I've finally managed to have another look at the document (and it's still
the
> 22nd *somewhere*...).
> (and turned out better than I had expected for the special-purpose blocks
it
> is), I think that the topic of response suppression and congestion control
> sections still have to be sharpened, and the examples could pick a more
> realistic balance between going all-NON and all-CON (or explain why that's
> something that wouldn't be done even though the text reads like that's
> what's expected to be used but maybe it's just me).
> 
> 
WGLC),
> all should be more or less sequential in the document (with forward/back
> references as needed).
> 

[Jon] OK
>   * The Q-Block options do not support stateless operation / random

[Jon] Actually Q-Block2 does now support this following the redefinition of
the M bit usage in a previous iteration (with M=0 you can ask for any
individual block).

[Jon] For stateless, Request-Tag is included so this should be fine.
https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless-06#section-4
.2
>   I doubt it's worth the effort given it's not part of the use case).
[Jon] I am not entirely convinced that Block1/2 have got the caching by
block properly sorted out - e.g. what happens when different clients make
requests with different SZX and Block2 is part of the cache key.  The
limiting to caching full representations is there so that a new can of worms
is not opened up.

[Jon] I will see if I can think of any further cons.
> * "compromises of": I don't understand that sentence.

[Jon] OK  s/compromises of/comprises of/
> * "the asymmetrical packet loss is not a benefit here": It never is;

[Jon] OK.  How about (which is obvious, but a reminder to the implementer)
OLD
However, the asymmetrical packet loss is not a benefit here.
NEW
However, the use of Confirmable messages will not work if there asymmetrical
packet loss. 
>   with 4.08" would ease that.

[Jon]
OLD
1.2.  Updated CoAP Response Code (4.08)

   This document updates the 4.08 (Request Entity Incomplete) by
   defining an additional message format for reporting on payloads using
   the Q-Block1 Option that are not received by the server.
NEW
1.2.  CoAP Response Code (4.08) Usage

This document adds a media type for the 4.08 (Request Entity
 Incomplete) response defining an additional message format for
 reporting on payloads using the Q-Block1 Option that are not received 
 by the server.
>   it for the later paragraphs that say that in more detail).

[Jon] OK. Gone with Critical etc.
>   Q-Block1 option" first paragraph).

[Jon] OK
>   Maybe phrase this the same way as the recommendations on tokens?

[Jon]
OLD
The Request-Tag is opaque
   in nature, but it is RECOMMENDED that the client treats it as an
   unsigned integer of 8 bytes in length.  An implementation may want to
   consider limiting this to 4 bytes to reduce packet overhead size.
   The server still treats it as an opaque entity.  The Request-Tag
   value MUST be different for distinct bodies or sets of blocks of data
   and SHOULD be incremented whenever a new body of data is being
   transmitted between peers.  The initial Request-Tag value SHOULD be
   randomly generated by the client.
NEW
The Request-Tag is opaque, the server still treats it as opaque but the
client SHOULD ensure that it is unique for every different body of
transmitted data.

Implementation Note: It is suggested that the client treats the Request-Tag
as an
   unsigned integer of 8 bytes in length.  An implementation may want to
   consider limiting this to 4 bytes to reduce packet overhead size.
The initial Request-Tag value should be randomly generated and then
subsequently incremented  by the client whenever a new body of data is being
   transmitted between peers.

OLD
   The ETag is opaque in nature, but it is RECOMMENDED that the server
   treats it as an unsigned integer of 8 bytes in length.  An
   implementation may want to consider limiting this to 4 bytes to
   reduce packet overhead size.  The client still treats it as an opaque
   entity.  The ETag value MUST be different for distinct bodies or sets
   of blocks of data and SHOULD be incremented whenever a new body of
   data is being transmitted between peers.  The initial ETag value
   SHOULD be randomly generated by the server.
NEW
   The ETag is opaque, the client still treats it as opaque but the server
SHOULD ensure that it is unique for every different body of transmitted
data.

Implementation Note: It is suggested that the server treats the ETag as an
   unsigned integer of 8 bytes in length.  An implementation may want to
   consider limiting this to 4 bytes to reduce packet overhead size.
The initial ETag value should be randomly generated and then subsequently
incremented  by the server whenever a new body of data is being
   transmitted between peers. 

>   [1]: https://tools.ietf.org/html/rfc7967#section-2

[Jon] The intent here was that CON continues to work for each
request/response in that the request needs to be acknowledged, but a
response (piggybacked or separate) is not required.
OLD
For Confirmable transmission, the server MUST continue to acknowledge
   each packet.
NEW
For Confirmable transmission, the server continues to acknowledge
each packet, but a response is not required (whether separate or
piggybacked) until retransmission or successful receipt of the body.

[Jon] To be continued in part 2.