Re: [Dots] DOTS Interop tests Update

[[e-mail]]

Hi Jon, Kaname, all,

Thank you for sharing the outcome of this interop.

For items related to draft-ietf-dots-robust-blocks, I suggest to make the edits at: https://tinyurl.com/dots-robust-latest. We may add a note to warrant operators about the need to assess the implications of using non-default values (including for *-wait parameters), but it seems to me that is so obvious.

Cheers,
Med

De : Dots <[e-mail]> De la part de Jon Shallow
Envoyé : jeudi 18 août 2022 19:39
À : [e-mail]
Objet : [Dots] DOTS Interop tests Update

Hi all,

Over the last 2 days, Kaname and I did some interop tests - in particular to test out the RFC9177 "Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission" and the associated DOTS usage draft https://www.ietf.org/archive/id/draft-ietf-dots-robust-blocks-03.html.

This was between a proprietary implementation and open source go-dots.  Both are using libcoap to provide the underlying CoAP layer.

As ever, there were a few minor issues in the respective DOTS applications implementations which were resolved.  No updates to libcoap were required, but Q-Block was used extensively.

Out of this, several things were raised, which are detailed below.  Kaname, please add to this in case I missed something.

Issue 1:
======

It became obvious that MAX_PAYLOADS must be the same for both the idle-config and mitigating-config definitions.  Otherwise, if there is a mitigating state change at one end, then MAX_PAYLOADS changes and hence we are in violation of (and get significant transmission delays)

RFC9177 7.2. Non-confirmable (NON)
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),

So, for
draft-ietf-dots-robust-blocks 3. DOTS Attributes for Robust Block Transmission

OLD:
max-payloads:
This attribute echoes the MAX_PAYLOADS parameter in [I-D.ietf-core-new-block].

This is an optional attribute.
NEW:
max-payloads:
This attribute echoes the MAX_PAYLOADS parameter in [RFC9177].

This is an optional attribute.  However, if defined, it MUST have an equal value in the 'idle-config' and 'mitigating-config' configurations.  If only one of the 'idle-config' and 'mitigating-config' definitions are defined in a message exchange, then the other (missing) definition MUST be updated to the same value.
END NEW

Issue 2:
======

NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT

RFC9177 7.2. Non-confirmable (NON) states

    Note that MAX_PAYLOADS, NON_MAX_RETRANSMIT, NON_TIMEOUT, NON_PROBING_WAIT, and
   NON_PARTIAL_TIMEOUT can be negotiated between DOTS peers, e.g., as per [DOTS-QUICK-BLOCKS].
    When explicit values are configured for NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT, these
    values are used without applying any jitter.

draft-ietf-dots-robust-blocks 3. DOTS Attributes for Robust Block Transmission has

    Implementation Note 1:
      'non-probing-wait' ideally should be left having some jitter and so should not be hard-coded
      with an explicit value. It is suggested to use a base value (using NON_TIMEOUT instead of
      NON_TIMEOUT_RANDOM) and, then, the jitter (ACK_RANDOM_FACTOR - 1) is added to each
      time the value is checked.
   Implementation Note 2:
      If any of the signal channel session configuration parameters is updated, the 'non-probing-wait'
      and 'non-partial-timeout' values should be recalculated according to the definition algorithms
      in Section 7.2 of [I-D.ietf-core-new-block].

If 'non-probing-wait' and 'non-partial-timeout' end up with negotiated values that are considerably different from the values as computed by the definition algorithms in Section 7.2 of [RFC9177], then it is likely that the Q-Block recovery mechanisms will fail.  Any recommendations here are definitely out of scope without extensive testing.  It is recommended that 'non-probing-wait' and 'non-partial-timeout' are not negotiated by DOTS, and hence removed from. draft-ietf-dots-robust-blocks all together.

Issue 3:
======

draft-ietf-dots-robust-blocks 3. DOTS Attributes for Robust Block Transmission, typo

OLD:
NON_PROBING_WAIT: is used to limit the potential wait needed calculated when using PROBING_WAIT.
NEW
NON_PROBING_WAIT: is used to limit the potential wait needed calculated when using PROBING_RATE.


Issue 4:
======

RFC9132 4.4.1.3. Processing Mitigation Requests, has

   The DOTS client MUST include the same ETag value in subsequent GET requests to retrieve the rest
   of the representation.

This statement is erroneous and should be deleted to remove confusion as it is likely to return a 2.03 response instead of a 2.05 response as per

RFC7252 5.10.6.2.  ETag as a Request Option

   A server can issue a 2.03 Valid response (Section 5.9.1.3) in place
   of a 2.05 Content response if one of the ETags given is the entity-
   tag for the current representation, i.e., is valid; the 2.03 Valid
   response then echoes this specific ETag in a response option.



Regards

Jon


_________________________________________________________________________________________________________________________

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.