HI Yatch, 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: 2-step 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) 3-step 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? thanks! X 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... > > 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 > -- Dr. Xavier Vilajosana Guillén Research Professor Wireless Networks Research Group Internet Interdisciplinary Institute (IN3) Universitat Oberta de Catalunya +34 646 633 681| xvilajos...@uoc.edu | Skype: xvilajosana http://xvilajosana.org http://wine.rdi.uoc.edu/ Parc Mediterrani de la Tecnologia Av. Carl Friedrich Gauss, 5. Edifici B3 08860 Castelldefels (Barcelona)
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
