thanks for your comments. Could you please summarize how the timeout will
work in the 2 and 3 step transactions:
I see it in this way:
A sends to B an ADD, if A packet is lost, B will never realize and A will
timeout. Idem if B response fails ( A timeouts)
A sends to B an ADD. If A packet is lost, B never realizes and A timeouts.
If B receives the packet but Response fails. A timeouts as before and B
timeouts for not receiving the confirmation. If the confirmation is lost B
timeouts and A should cancel or timeout because it does not receive ACK at
the MAC layer.
Is this your suggestion?
What if A resets? how you now at B that A has reset? do this require a
STATUS call from A to B when it join the network again?
2016-12-01 22:34 GMT+01:00 Yasuyuki Tanaka <yasuyuki9.tan...@toshiba.co.jp>:
> 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...
> 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?
>> 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...
> 6tisch mailing list
Dr. Xavier Vilajosana Guillén
Wireless Networks Research Group
Internet Interdisciplinary Institute (IN3)
Universitat Oberta de Catalunya
+34 646 633 681| xvilajos...@uoc.edu | Skype: xvilajosana
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 5. Edifici B3
08860 Castelldefels (Barcelona)
6tisch mailing list