Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Ben, 

Please see inline. The latest changes can be tracked at: https://tinyurl.com/new-block-latest. 

Cheers,
Jon & Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[e-mail]]
> Envoyé : jeudi 13 mai 2021 23:52
> À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>
> Cc : The IESG <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Re: Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11:
> (with DISCUSS and COMMENT)
> 
> Hi Med,
> 
> On Thu, May 06, 2021 at 05:35:19PM +0000,
> [e-mail] wrote:
> > Hi Ben,
> >
> > Thank you for the review. All the changes can be tracked at:
> https://tinyurl.com/new-block-latest.
> 
> (Apparently I waited long enough to be able to just use rfcdiff on
> the published -12; PR #26 posted with a couple nits from that diff.)
> 

Merged the PR. Thank you.

> > Please see inline.
> >
> > Cheers,
> > Jon & Med
> >
> > > -----Message d'origine-----
> > > De : Benjamin Kaduk via Datatracker [mailto:[e-mail]]
> Envoyé
> > > : jeudi 6 mai 2021 03:58 À : The IESG <[e-mail]> Cc :
> > > [e-mail]; [e-mail];
> > > [e-mail]; [e-mail]; [e-mail] Objet :
> > > Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11:
> > > (with DISCUSS and COMMENT)
> > >
> > > Benjamin Kaduk has entered the following ballot position for
> > > draft-ietf-core-new-block-11: Discuss
> > >
> > > When responding, please keep the subject line intact and reply to
> > > all email addresses included in the To and CC lines. (Feel free
> to
> > > cut this introductory paragraph, however.)
> > >
> > >
> > > Please refer to https://www.ietf.org/iesg/statement/discuss-
> > > criteria.html
> > > for more information about DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found
> here:
> > > https://datatracker.ietf.org/doc/draft-ietf-core-new-block/
> > >
> > >
> > >
> > > -----------------------------------------------------------------
> ---
> > > -
> > > -
> > > DISCUSS:
> > > -----------------------------------------------------------------
> ---
> > > -
> > > -
> > >
> > > I have a concern about the MAX_PAYLOADS congestion-control
> parameter.
> > > In Section 7.2 it is stated that both endpoints only SHOULD have
> the
> > > same value.  I don't see how this can be anything less than MUST,
> > > given that we attribute semantics to whether NUM modulo
> MAX_PAYLOADS
> > > is zero or non-zero in the processing of the Q-Block2 option.  If
> > > the endpoints disagree on the value of MAX_PAYLOADS they will
> > > disagree on the semantics of Q-Block2 -- how can that be
> interoperable?
> > > (Being able to negotiate the value does not seem inherently
> > > problematic, but since it is relevant for protocol semantics it
> > > seems like the value must be identical on both endpoints.) This
> > > seems especially important to have clarity on given that the
> current
> > > specification allows for MAX_PAYLOADS to be decreased at runtime
> in
> > > response to congestion feedback over a 24-hour period, with no
> > > synchronization between peers provided ("Note that the CoAP peer
> > > will not know about the MAX_PAYLOADS change until it is
> > > reconfigured".)
> > >
> > >
> >
> > Implementation testing with MAX_PAYLOAD being different in the
> peers showed things worked badly (unnecessary timeouts/recovery) but
> continued to work.
> >
> > If the peers were negotiating and installing a new common value
> (application layer), there was a brief period of instability.
> 
> I still think there's a fundamental mismatch between "this is a
> parameter that is part of the protocol and part of request/response
> semantics" and "this is a parameter that each endpoint is allowed to
> vary unilaterally".
> This holds even if we attempt to set things up so in the former case
> the behavior degrades somewhat gracefully, with one direction
> transmitting as expected and the other only making slow progress.
> 
> If this was just a local parameter for how to batch and pace
> transmissions, that would be fine, and letting it vary (even if not
> recommended) between peers would also be fine.
> 
> But the -12 currently has text like (§4.4):
> 
>    In a request for any block number, the M bit unset indicates the
>    request is just for that block.  If the M bit is set, this has
>    different meanings based on the NUM value:
> 
>    NUM is zero:  This is a request for the entire body.
> 
>    'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero:  This is
>       used to confirm that the current MAX_PAYLOADS_SET (the latest
>       block having block number NUM-1) has been successfully received
>       and that, upon receipt of this request, the server can continue
> to
>       send the next MAX_PAYLOADS_SET (the first block having block
>       number NUM).  This is the 'Continue' Q-Block-2 and conceptually
>       has the same usage (i.e., continue sending the next set of
> data)
>       as the use of 2.31 (Continue) for Q-Block1.
> 
>    Any other value of NUM:  This is a request for that block and for
> all
>       of the remaining blocks in the current MAX_PAYLOADS_SET.
> 
> That is, the semantics of a request are supposed to depend on the
> value of MAX_PAYLOADS.  The semantics of what the sender sent can
> disagree with the semantics of what the receiver interprets, if there
> is skew in this value.
> 
> Now, maybe it happens that things work out okay if the client and
> server have different MAX_PAYLOADS values, in that setting the M bit
> does not have to be tied to a specific MAX_PAYLOADS_SET and rather
> means "give me a chunk of up to your max-transmit-window of
> payloads", and the receiver's value determines whether the "up to"
> means a full window's worth or not, but that's not what we say it
> means.  For Proposed Standards, I think we need to be accurate about
> what the semantics actually are, not just what they are in the ideal
> case, if the MAX_PAYLOADS value is allowed to vary between peers.
> And if skew is allowed, we need to say that behavior degrades in case
> of skew and how, but that progress will still be made.
> 
> (Even if the semantics actually are "give me a chunk of up to your
> max-window", things can still end up behaving badly if the skew is
> quite significant -- if I think I'm asking for a window of up to 10
> blocks but I get back 100, I may not be able to handle the full
> response.)
> 
> 
> > Please note that this is a value that is unlikely to change: 1500
> byte packets and MAX_PAYLOADS(10) gives a set of 15,000 bytes. With
> an up to NON_TIMEOUT (2 secs) delay, average data rates are of the
> order of 60kbps (1500 * 8 * 10 / 2), so providing the congested
> network can handle 60Kbps, all will be OK. If higher values, then the
> 'Continue' will come back quicker than the NON_TIMEOUT.
> 
> If it's unlikely to change, then what's wrong with making it a fixed
> parameter (subject to change by out-of-band agreement)?

These are fair observations. We made the following changes: 

(1)

OLD:
   MAX_PAYLOADS should be configurable with a default value of 10.  Both
   CoAP endpoints SHOULD have the same value (otherwise there will be
   transmission delays in one direction) and the value MAY be negotiated
   between the endpoints to a common value by using a higher level
   protocol (out of scope of this document).

NEW:
   MAX_PAYLOADS should be configurable with a default value of 10.  Both
   CoAP endpoints MUST have the same value (otherwise there will be
   transmission delays in one direction) and the value MAY be negotiated
   between the endpoints to a common value by using a higher level
   protocol (out of scope of this document).

(2) replaced this text with a note:

OLD: 
   If the CoAP peer reports that at least one payload has not arrived
   for each body for at least a 24-hour period and it is known that
   there are no other network issues over that period (e.g., DDoS
   attacks), then the value of MAX_PAYLOADS can be reduced by 1 at a
   time (to a minimum of 1) and the situation re-evaluated for another
   24-hour period until there is no report of missing payloads under
   normal operating conditions.  Following a period of 24 hours where no
   packet recovery was required, the value of MAX_PAYLOADS can be
   increased by 1 (but without exceeding the default value) for a
   further 24-hour evaluation.  The newly derived value for MAX_PAYLOADS
   should be used for both ends of this particular CoAP peer link.  Note
   that the CoAP peer will not know about the MAX_PAYLOADS change until
   it is reconfigured.  As a consequence of the two peers having
   different MAX_PAYLOADS values, a peer may continue indicating that
   there are some missing payloads as all of its MAX_PAYLOADS_SET may
   not have arrived.  How the two peer values for MAX_PAYLOADS are
   synchronized is out of the scope.

NEW:
      Note: Assuming 1500-byte packets and the MAX_PAYLOADS_SET having
      10 payloads, this corresponds to 1500 * 10 * 8 = 120 Kbits.  With
      a maximum delay of 2 seconds between MAX_PAYLOADS_SET, this
      indicates an average speed requirement of 60 Kbps for a single
      body should there be no responses.  This transmission rate is
      further reduced by being subject to PROBING_RATE.

> >
> > >
> > >       If the FETCH request includes the Observe Option, then the
> > > server
> > >       MUST use the same token as used for the initial response
> for
> > >       returning any Observe triggered responses so that the
> client
> > > can
> > >       match them up.
> > >
> > >       The client should then release all of the tokens used for
> this
> > >       body unless a resource is being observed.
> > >
> > > If a resource is being observed, should the client release all
> the
> > > other tokens (than the one used for the initial response)?
> >
> > There is no reason why the client cannot release all the other
> tokens.
> >
> > >
> > > Also, is the "initial response" the first response for the
> blockwise
> > > transfer (which might be a 2.31 or 4.08 for NON requests), or the
> > > first one with response code 2.05?
> >
> > The "initial all data received response" - i.e. 2.01 or 2.05.
> 
> I'd suggest adding that clarification.

Sure. We made the following change:  

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

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

> 
> > >
> > >    2.31 (Continue)
> > >
> > >       This Response Code can be used to indicate that all of the
> > > blocks
> > >       up to and including the Q-Block1 Option block NUM (all
> having
> > > the
> > >       M bit set) have been successfully received.  The token used
> > > MUST
> > >       be one of the tokens that were received in a request for
> this
> > >       block-wise exchange.  However, it is desirable to provide
> the
> > > one
> > >       used in the last received request.
> > >
> > > Can the client release any tokens upon receipt of such a
> response?
> >
> > Yes.  If going with the Implementation Note #6., the lower 32 bits
> tracker must not be released.
> 
> Since we mention releasing tokens for other response codes, it would
> feel natural to mention it here as well, to me.

Added this NEW text: 

      The client should then release all of the tokens used for this
      MAX_PAYLOADS_SET.

> 
> > >
> > >    4.02 (Bad Option)
> > >
> > >       This Response Code MUST be returned for a Confirmable
> request
> > > if
> > >       the server does not support the Q-Block Options.  Note that
> a
> > >       reset message must be sent in case of Non-confirmable
> request.
> > >
> > > Reset only needs to be sent if the server is not ignoring the
> > > request entirely, though, right?
> >
> > The request will be rejected. Please see:
> >
> >    A Non-confirmable
> >    message with an unrecognized critical option is either rejected
> with
> >    a Reset message or just silently ignored (Sections 5.4.1 and 4.3
> of
> >    [RFC7252]).
> 
> I don't think I understand.  "either rejected ... or just silently
> ignored"
> says that "just silently ignore" is a valid way to handle such a
> message.
> So, if "silently ignore" is a valid option for the server, I don't
> see how we can say "must be sent" without deviating from RFC 7252.
> 

Fair point: s/must be sent/may be sent. We don't want to deviate from 7252.


> > >    For Confirmable responses, the client continues to acknowledge
> > > each
> > >    packet.  Typically, the server acknowledges the initial
> request
> > > using
> > >    an ACK with the payload, and then sends the subsequent
> payloads as
> > >    CON responses.  The server will detect failure to send a
> packet,
> > > but
> > >    the client can issue, after a MAX_TRANSMIT_SPAN delay, a
> separate
> > >    GET, POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks
> as
> > >    needed.
> > >
> > > Starting out with "for confirmable responses" implies that we're
> > > going to separately cover non-confirmable responses later, or at
> > > some point transition to statements of general applicability (to
> > > both confirmable and non-confirmable responses).  Where does that
> happen?
> >
> > It is in this section. The text you quoted is what is specific to
> CON responses.
> 
> I would have preferred a more explicit signal that the subsequent
> paragraphs apply to both the confirmable and non-confirmable cases,
> but the only option I'm coming up with at the moment ("for both
> confirmable and non-confirmable responses" to start the subsequent
> paragraph") is not great.
> 

We reordered the text so that the text about confirmable is positioned at the end of the section. 

> > > Section 5
> > >
> > >    The data payload of the 4.08 (Request Entity Incomplete)
> response
> > > is
> > >    encoded as a CBOR Sequence [RFC8742].  It comprises of one or
> > > more
> > >
> > > I think we want some qualifying text that reaffirms that the
> > > behavior being described is applicable only to the
> > > application/missing-
> > > blocks+cbor-seq content-type case, possibly by having the
> previous
> > > discussion state that "this section defines the behavior and
> > > semantics for 4.08 responses using the new content-type."
> >
> > Why is this needed?
> 
> The data payload of the 4.08 response as specified in RFC 7959 is not
> a CBOR sequence.  The current wording and paragraph structure doesn't
> provide a clear connection between the new content-type (as mentioned
> in the first sentence of the section) and this text, so a reader
> might misread this text (which has no normative keywords) as
> describing the preexisting situation for 4.08 responses, and that is
> not correct.  Even just adding the word "new" ("data payload of the
> new 4.08 (Request Entity Incomplete) response") would help clarify
> that the description is of the new behavior, not the preexisting
> behavior.

We understand your point better. Thanks. We made this change:

OLD: 
   The data payload of the 4.08 (Request Entity Incomplete) response is
   encoded as a CBOR Sequence [RFC8742].

NEW:
   The new data payload of the 4.08 (Request Entity Incomplete) response
   with Content-Type set to "application/missing-blocks+cbor-seq" is
   encoded as a CBOR Sequence [RFC8742].

> 
> > >
> > >    The Concise Data Definition Language [RFC8610] (and see
> Section
> > > 4.1
> > >    [RFC8742]) for the data describing these missing blocks is as
> > >    follows:
> > >
> > > (Should we mention that this is only informational and that the
> > > prose description is normative, in line with RFC 8610 being only
> an
> > > informative reference?)
> >
> > I'm not sure this is needed. What is authoritative is the CBOR
> sequence.
> 
> In my experience, it's quite common for documents to specifically say
> whether the protocol-description-language version or the prose
> version is authoritative in case of conflict.  Hopefully there is no
> conflict, but to have a clear and unambiguous specification, we have
> to say which version to use if there is a conflict.
> 

Let's then make things clear:

NEW:
   This CDDL syntax MUST be followed.

> > > Section 6
> > >
> > >    Implementation Note:  By using 8-byte tokens, it is possible
> to
> > >       easily minimize the number of tokens that have to be
> tracked by
> > >       clients, by keeping the bottom 32 bits the same for the
> same
> > > body
> > >       and the upper 32 bits containing the current body's request
> > > number
> > >       (incrementing every request, including every re-transmit).
> > > This
> > >       allows the client to be alleviated from keeping all the
> per-
> > >       request-state, e.g., in Section 3 of [RFC8974].
> > >
> > > If we're going to introduce structure into a nominally opaque
> > > identifier, we need to discuss the consequences of that in the
> > > security considerations.  draft-gont-numeric-ids-sec-
> considerations
> > > has some guidance in this regard.
> >
> > It is all opaque to the server, the client is just using it to make
> sure his requests are unique. If one can access the token, it can
> access more critical information. I'm not sure there is much to say
> as the messages are not supposed to be sent on clear. Tampering of
> the token is thus very difficult given we are not using NoSec.
> 
> It's only NOT RECOMMENDED to use NoSec, which means we still have to
> accurately document the security considerations if NoSec is used.
> 

Added this NEW text: 

  "However, if using NoSec, Section 5.2 of [RFC8974] needs to be considered for	
  security implications."

Section 11 is also updated with this NEW text: 

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

   If NoSec is being used, Section D.5 of [RFC8613] discusses the
   security analysis and considerations for unprotected message fields
   even if OSCORE is not being used.

_________________________________________________________________________________________________________________________

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.