Qin, Diego, I'll try to explain better my point of view.
Referring to the very helpful scheme that Qin presented, I would say that time between t3 and t5 will happen almost instantaneously with respect to the timeslot duration, since those are operations triggered by the correct reception of an ADD request by node B. The problem stands out in calculating the time between t5 and t6, this is the timeout calculation we should focus on. Since the time between t3 and t5 is very small, it does not change the following reasoning to say that we want to compute the timeout as function of [t3...t6]. So, my point of view starts by the same premises as Diego's. What I'm worried about is the value to assign to this timeout. Let's forget by now about the 6P ACK (maybe it's better to open another thread for that later). I guess that the aim is that we don't want the ADD response to arrive when the timeout is expired. If the ADD response arrives after the timeout, the MAC frame containing the 6P ADD response will be acked anyway. This will produce a disagreement on the scheduled cells between A and B. Node A, although it received the 6P ADD answer, it will consider that answer out of time and it will not add any TX cell. At the same time, node B will add RX cells, because it was acknowledged by A for the correct delivery of the 6P ADD response. Node A, since it feels not satisfied (still no allocated cells), will continue asking for new cells to B. Cells available will terminate very quickly on B if there are many motes competing to get bandwidth to B. This happens if the timeout is shorter than the unpredictable time we want to estimate. If the timeout is long enough for containing the maximum of that unppredictable time, i.e., the time interval [t3...t6], the 6P ADD answer will always arrive while node A is waiting for the answer. If it does not arrive in this maximum time, it will never arrive. Let's evaluate that maximum. Timeslot long 10 ms, slotframe 101 timeslots, maxRetries 3. As in Qin example. There is also the first try, so TXATTEMPTS = maxRetries + 1 = 4. Each try to send a packet happens randomly in the current backoff interval. In the worst case, the backoff time is chosen in the biggest backoff interval [0, 2^macMaxBE - 1]. In the really worst case, node B will choose to transmit in 2^macMaxBE shared cells. If macMaxBE is 4 (as in OpenWSN, but 7 according to the IEEE802.15.4e standard), the time to transmit the packet just the first time could be in 2^4 = 16 shared slots. In other words, if there is only one shared cell, according to 'minimal', that time will be around 16 seconds. This is the worst case, I know, but we want to be sure that timeout does not expire before the actual time that node B can take to ship the ADD response to A. 16 seconds is just the time for sending a packet. That must be multiplied by TXATTEMPTS = 4. So the timeout should be more than 1 minute long. If it expires and node A has not received the 6P ADD response, it means that it won't receive that 6P ADD response later, and, as a consequence, there will be no inconsistency. The formula that I have in mind for the timeout calculation is: timeout = 2^macMaxBE * TXATTEMPT [# executed shared cells] and I would let the unity of measure be the number of shared cells. In other words, if timeout comes to be 64, this means that the timeout will expire just after the 64th shared cell. I'm not expressing the timeout in seconds, because the number of shared cells per slotframe could be more than one. In fact, the backoff mechanism is only computed on shared cells. If then is still preferable to express the timeout in seconds, and assuming that there is a single shared cell in a slotframe, the timeout formula should look like the following: timeout = 2^macMaxBE * TXATTEMPT * Slotframe_length_in_seconds [seconds] Do you see why I'm saying that the timeout that does not produce inconsistencies is very long? What do you feel is incorrect in my approach? Nicola 2016-10-31 22:05 GMT+01:00 Prof. Diego Dujovne <diego.dujo...@mail.udp.cl>: > Qin, > Well, my scheme tried to avoid any uncertainty from the > MAC layer, including t2,t6 and t8. I only represented t2 on the mail. > I would like to keep the timeout calculation only for preparation and > processing stages, thus letting the MAC timeout and retransmissions > count on their own layer. > Regards, > > Diego > > > 2016-10-31 17:19 GMT-03:00 Qin Wang <qinwang6...@yahoo.com>: > >> Hi Nicola and Diego, >> >> Since we agree Timeout is needed no matter what schemes we will choose, >> let's make calculation about the Timeout in different schemes. >> Assume: >> t1: Node A 6top prepares ADD Request >> t2: Node A 6top sends out ADD Request, ending with MAC-ACK success >> t3: Node B 6top processes ADD Request >> t4: Node B SF0 processes ADD Request >> t5: Node B 6top prepares ADD Response >> t6: Node B 6top sends out ADD Response, ending with MAC-ACK success >> t7: Node A 6top processes ADD Response. >> t8: Node A 6top sends out 6P ACK, ending with MAC-ACK success >> t9: Node B 6top processes 6P ACK >> >> According to my understanding, the most unpredictable time is t2, t6 and >> t8, because they are associated with Retry and the length of slotframe. >> Assume slot duration is 10ms and slotframe length is 101, maxRetry is 3, >> then, t2 and t6 could be 3 seconds, and t8 could be 3 seconds also if >> Shared cell is used. >> >> (1) Current scheme. Timeout starts when SF0 on node A issues command to >> 6top to ask ADD cells. Then the value of Timeout is function of (t1,..t7) >> (2) Diego's scheme. Timeout starts when SF0 on node A gets MAC-ACK >> success from 6top. Then the value of Timeout is function of (t3,..t7) >> (3) Nicola's scheme. (I'm not sure the formula to calculate the value of >> Timeout. But my feeling is each Timeout has to include at least one long >> and unpredictable Time, i.e. t2, or t6, Nicola: would you please add it?) >> >> Comparing (1) and (2), I agree that (2) is much better than (1), because >> (2) does not take t2 into account in (2), reducing almost half of >> uncertainty. >> >> I haven't figured out the advantage of (3) over (2). Nicola, would you >> please give me your explanation? >> >> Thanks >> Qin >> >> >> >> On Monday, October 31, 2016 2:18 PM, Nicola Accettura < >> nick.accett...@gmail.com> wrote: >> >> >> Hi Diego, >> >> thank you for your answer too. >> >> However there are two points I would like to point out. >> >> First, the mac-layer ack is in fact the TSCH ack, that travels on the air >> during the same timeslot of the data packet. It is sent if the data packet >> is unicast, either on shared or on dedicated cells. The 6P ACK I'm >> proposing is NOT a TSCH ack, it is a data packet sent from A to B and it >> requires its own TSCH ack from B to A. >> >> Second, I'm totally not aligned on "...dedicated cells are for data and >> shared cells for any kind of signalling and/or negotiation." and I believe >> this is not the distinction between those types of cells. >> >> Shared or dedicated cells can be used either for signaling and/or data. >> >> 'Minimal'. as an example, has got a single shared cell. One can run >> minimal without any other more sophisticated scheduling technique just >> using that shared cell for both signaling and data. The same is possible if >> someone uses a dynamic schedule and uses also dedicated cells. I don't see >> any reason for forbidding dedicated cells to vehiculate both signaling and >> data. The difference is that in shared cells there's contention. >> >> I would add that it could be possible to piggyback 6P signaling with data >> from upper layers, if there is space in the MTU. It is the encapsulation >> that makes the distinction between data and 6P signaling. Data go >> encapsulated within the IEEE802.15.4e packet payload, while 6P goes into >> the payload IEs, and these two payloads can coexist in the same >> IEEE802.15.4e frame. >> >> Thoughts? >> >> >> Nicola >> >> >> >> > > > -- > DIEGO DUJOVNE > Profesor Asociado > Escuela de Informática y Telecomunicaciones > Facultad de IngenierÃa - Universidad Diego Portales - Chile > www.ingenieria.udp.cl > (56 2) 676 8125 >
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
