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
