Diego, from what I saw it does not help. That is a way to associate requests to responses in the transaction. If the timeout expires on A, a response arriving out of time will not be considered.
If the 6P response from B to A is out of time for A, that response should be immediately trashed: the cells to be allocated listed in the 6P response could have been allocated to other neighbors by A. Nicola 2016-10-31 23:18 GMT+01:00 Prof. Diego Dujovne <[email protected]>: > Nicola, > One recent inconsistency check on 6P is the > Schedule Generation, defined on the 6top protocol > draft on: > > 4.3.11. Generation Management > > section. Maybe this helps reducing the inconsistency > you are mentioning without increasing the timeout. > Regards, > > Diego > > > 2016-10-31 19:09 GMT-03:00 Nicola Accettura <[email protected]>: > >> 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 <[email protected] >> >: >> >>> 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 <[email protected]>: >>> >>>> 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 < >>>> [email protected]> 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 >>> >> >> > > > -- > 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 [email protected] https://www.ietf.org/mailman/listinfo/6tisch
