Hi Qin,
I think nodeA=>nodeB request process includes two parts, one is Tx
from nodeA to nodeB, another part is for nodeB's MAC to process the
Request message. As you mentioned, failure of the first part can be
identified by mac-ack from nodeB, but not the second part. Right?
Yes, that's right! I believe we are now on the same page about the
approach using timeout.
In this sense, ability to identify failure without inconsistency
occurred in the second part is the only advantage of the generation
counter, which is achieved by consuming four bits in every 6P packet
and keeping inter-transaction state for every neighbor. In my opinion,
this advantage is a little thing for the price to pay...
Best,
Yatch
On 2016/12/01 21:45, Qin Wang wrote:
Hi Yasuyuki,
I think nodeA=>nodeB request process includes two parts, one is Tx from nodeA
to nodeB, another part is for nodeB's MAC to process the Request message. As you
mentioned, failure of the first part can be identified by mac-ack from nodeB, but
not the second part. Right?
Thanks
Qin
On Wednesday, November 30, 2016 1:49 PM, Yasuyuki Tanaka
<yasuyuki9.tan...@toshiba.co.jp> wrote:
Thanks, Qin.
(1) Timeout in nodeA can be triggered either by failure in
nodeA=>nodeB request process and by failure in nodeB=>nodeA response
process (i.e the process in above example). nodeA cannot tell exact
reason for a event of Timeout by itself. In another word, nodeA
cannot tell there is a inconsistency between its schedule and
nodeB's schedule just based on Timeout. Right?
That is right; failure in the nodeA=>nodeB case is what I called
"false positive." But, nodeA could lower the possibility of false
positive by using MAC-layer ACK, implementation efforts. If nodeA
doesn't receive a MAC-layer ACK to its request frame, nodeA can
consider the transaction as having failed without inconsistency.
(2) sending CLEAR, or STATUS, or LIST usually happens after a
inconsistency is found, and the function of generation counter is
exactly to find out the inconsistency. Make sense?
I'd say the generation counter is not the only way to detect
inconsistency. STATUS/LIST could detect it as well, although
STATUS/LIST always fails with RC_ERR_GEN in a case of inconsistency
according to the latest draft.
The generation counter can find inconsistency as you mentioned, but it
has disadvantages:
- It needs 6P to keep per-neighbor states (ignore SeqNum for now) even
when there is no ongoing transaction.
- It cannot detect inconsistency until a subsequent transaction; it
may take a long time.
The reactive approach using timeout doesn't have such disadvantages;
furthermore, it's simpler than the the schedule generation management,
in my opinion.
I still cannot see why the generation management at 6P is really needed...
Best,
Yatch
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
