[Dots] DOTS Interop tests Update

[Jon Shallow <[e-mail]>]

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