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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to