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
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
