Subject: [Ace] Ordering Guarantee in CoAP-EAP

From: Dan Garcia Carrillo <[email-masked]>
Date: Tue, 30 Mar 2021 18:49:32 +0200

Hi ACE,

Last Thursday we had a conversation with Christian regarding possible 
optimizations on how to provide the requisite of the ordering guarantee 
for EAP.

This is currently achieved with an Option we define (SeqNum) to maintain 
a sequence number. This number is initialized randomly by the Controller 
and increased monotonically. This way the IoT device is able to know 
which is the next expected message.

In previous investigations, having into account that we are dealing with 
a lock-step protocol, we consider using the MSG-ID. The fact that they 
can be generated randomly was not a problem, since we considered that 
the CoAP engine store the recent MSG-IDs to detect duplicates, and any 
new message with an unregistered MSG-ID was considered the next expected 
message.

After our conversation with Christian, he pointed out that there may be 
implementations which may not keep track of recent MSG-IDs, hence we may 
need to rely on other mechanism to ensure the message sent is the one 
expeted.

To avoid defining a new option, we could use existing solutions to help 
provide ordered delivery:
- URI-Query
- Location-Path and Location-Query
- Echo Option

URI-Query:
We can use this as part of the request to specify accesing a resource 
with a subsequent value that indicates the step we are currently in 
(e.g., /b/x/n), 'b' -> bootstrapping service; 'x'-> resource for the 
currenty bootstrapping state; 'n'-> the current exchange

Location-Path and Location-Query:
In the response we would indicate the update on the current state and  
what is expected from the client in the next message, by adding the 
Location-Path and Location-Query Options. The problem is that currently 
these options are specified with 2.01 response code, not 2.04 Changed 
(the one we are using every time we update the bootstrapping state).

Our question is, would be possible to have this confirmation in the 
response?

Echo Option:
Finally, another option proposed by Christian is to use the Echo Option, 
starting in the first ACK from the server, to achieve the ordering 
guarantee. The server would state a number that has to be replied in 
another Echo Option in the next POST request from the server.

We feel that the mechamism finally chosen, that we are pursuing for the 
need of the EAP requirements, could be used for any lock-step protocol 
using CoAP as transport.

This is what we understood, please Christian comment if there is 
something to be clarified.

I think the option with the Echo Option we achieve a clean solution with 
a similar approach as we propose with the SeqNum Option.

Best Regards,

Dan.

[1] https://tools.ietf.org/html/draft-ietf-core-echo-request-tag-12