Subject: [6tisch] SF Timeout calculation (Ticket #53)

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Sat, 29 Oct 2016 13:44:06 -0300

Dear all,
           Yesterday, we had a discussion about ticket #53
from the issue tracker, on the way to calculate the
SF0 timeout value.
           There is current a proposal to calculate the timeout
on SF0 between the arrival of the MAC-layer ACK for the
request packet and the arrival of the response packet.
In order to achieve this calculation, the 6P protocol must
signal the arrival of the request ACK packet so as to start
the timer countdown.
           Using this method, we avoid very long timeouts set
to the max value of the number of TXATTEMPTS and the
maximum backoff value.
Graphically:

SF        |REQUEST|       |timer-----|RESPONSE|
                          ^
6P         |REQUEST|      |         |RESPONSE|
MAC LAYER   |REQUEST| |ACK|        |RESPONSE| |ACK|

I would like to know if your thougthts about this idea.
Thank you.
Regards,

                                Diego

-- 
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

---

From: Nicola Accettura <[email-masked]>
Date: Sat, 29 Oct 2016 20:18:29 +0200

Diego, all,

the timeout obviously must start when the ack is received. I agree in total.

Though, you still need to get the timeout proportional to TXATTEMPTS and
also to the maximum backoff window. Why?

Call A the node that is requesting cells, and B the node that is asked for
cells. Node A sends a request and gets a mac layer ack from B. A starts the
timeout. B sends a packet, but it's lost. Sends another packet and it is
lost... until the last attempt which is successful: B gets a link layer ack
from A. So B allocates cells as RX.

This confirms that the timeout should be proportional to TXATTEMPTS. And to
the maxium backoff window. If there is only one shared cell, according to
'minimal', the timeout is proportional also to the slotframesize. If some
implementation considers more than one shared cell per slotframe, the
timeout can be smaller. At this point, I would say that the unity of
measure of the timeout should be the number of executed shared cells, so
that the timeout can be safely be proportional just to the product of
TXATTEMPTS and the maximum backoff window.

Yes, this causes to have a very long timeout, with possible (and actually
frequent) desynchronizations. Especially when the network is forming, all
nodes will ask for dedicated cells, many 6P packets will get lost.
Keepalives will be triggered, but this worsen the situation. Everything is
very very bad.

Is that possible to have a shorter timeout?

My answer is 'yes'. But we need something else: a 6P ACK.

In fact, assume that A sent a request, B acked at MAC layer. Then B (maybe
after many tries, if the responses have been lost, and this is possible in
the 'minimal' shared cell due to collisions in big networks) is finally
able to send an answer that is correctly received by A and A sends an ack
at mac layer. B adds cells as RX and expects A to open the same cells as
TX.

'Good!' one would say.

Wrong! Node A has acknowledged at MAC layer the correct reception of the
answer by B but will process the 6P packet after that. If the timeout is
too short, that packet will be considered out of time. And the TX cells
will not be allocated. With some RX cells open on node B.

One can think of a timeout to garbage collect on B. But I'm not sure this
would be very efficient, there's the probability of false positive.

A 6P ack would make the 6P negotiation reliable. B can 'half' open the RX
side after receiving the mac layer ack from A. A will open the TX side
after sending the mac layer ack, it the 6P response was in time. It will
send the 6P ack possibly in the newly created dedicated cell, so
decongesting the shared cell of 'minimal'. If B receives the 6P ack, it
will be sure that the RX side is open completely without possible
impairment with the node A schedule knowledge.

Instead, if the 6P response was out of time, A will not send any 6P ack,
will not open the TX side. B will not receive any 6P ack within a timeout
(that can be the same length as that starting on the A side after the
reception of the mac layer ack to the request packet) and when that expires
will delete the RX cells that were 'half' opened.

With this, it is not possible to get suspicious cells allocations on the RX
side. There's still the possibility that a TX side is open with the RX side
not open. But for that, 6P or SF will manage a relocation.

Think about the 6P packet as the third part of a 3-way-handshake.

Of course, it's obvious that I'm strongly in favor of a 6P ack definition,
more than having a big timeout.

Does it make sense?

Nicola

2016-10-29 18:44 GMT+02:00 Prof. Diego Dujovne <[email-masked]>:

> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Qin Wang <[email-masked]>
Date: Mon, 31 Oct 2016 15:20:53 +0000 (UTC)

Hi Nicola,
I want to confirm my understanding first. 
Your proposal is to introduce a new 6P message, i.e. 6P ACK message, into a transaction, then the sequence of a original 2-way ADD transaction will be: (1) node A SF0 sets "adding TX cells" OPEN, and 6top layer sends ADD request to nodeB(2) node B 6top layer receives ADD Request, SF0 sets "adding RX cells" OPEN, and 6top layer sends ADD Response to node A(3) node A 6top layer receives ADD Response, SF0 adds TX cells and sets "adding TX cells" CLOSED, and 6top layer sends 6P ACK to node B(4) node B 6top layer receives 6P ACK, SF0 adds RX cells and sets "adding RX cells" CLOSE.
Is my understanding correct? In addition, the proposed scheme will not need Timeout. Is it what you mean?
But, I still think the scheme can not avoid a Timeout. Otherwise, how node A or node B can stop a Failed transaction if something happens?
ThanksQin

    On Saturday, October 29, 2016 2:18 PM, Nicola Accettura <[email-masked]> wrote:

 Diego, all,

Though, you still need to get the timeout proportional to TXATTEMPTS and also to the maximum backoff window. Why?

Call A the node that is requesting cells, and B the node that is asked for cells. Node A sends a request and gets a mac layer ack from B. A starts the timeout. B sends a packet, but it's lost. Sends another packet and it is lost... until the last attempt which is successful: B gets a link layer ack from A. So B allocates cells as RX.

This confirms that the timeout should be proportional to TXATTEMPTS. And to the maxium backoff window. If there is only one shared cell, according to 'minimal', the timeout is proportional also to the slotframesize. If some implementation considers more than one shared cell per slotframe, the timeout can be smaller. At this point, I would say that the unity of measure of the timeout should be the number of executed shared cells, so that the timeout can be safely be proportional just to the product of TXATTEMPTS and the maximum backoff window.

Yes, this causes to have a very long timeout, with possible (and actually frequent) desynchronizations. Especially when the network is forming, all nodes will ask for dedicated cells, many 6P packets will get lost. Keepalives will be triggered, but this worsen the situation. Everything is very very bad.

In fact, assume that A sent a request, B acked at MAC layer. Then B (maybe after many tries, if the responses have been lost, and this is possible in the 'minimal' shared cell due to collisions in big networks) is finally able to send an answer that is correctly received by A and A sends an ack at mac layer. B adds cells as RX and expects A to open the same cells as TX. 

'Good!' one would say. 

Wrong! Node A has acknowledged at MAC layer the correct reception of the answer by B but will process the 6P packet after that. If the timeout is too short, that packet will be considered out of time. And the TX cells will not be allocated. With some RX cells open on node B.

One can think of a timeout to garbage collect on B. But I'm not sure this would be very efficient, there's the probability of false positive.

A 6P ack would make the 6P negotiation reliable. B can 'half' open the RX side after receiving the mac layer ack from A. A will open the TX side after sending the mac layer ack, it the 6P response was in time. It will send the 6P ack possibly in the newly created dedicated cell, so decongesting the shared cell of 'minimal'. If B receives the 6P ack, it will be sure that the RX side is open completely without possible impairment with the node A schedule knowledge.

Instead, if the 6P response was out of time, A will not send any 6P ack, will not open the TX side. B will not receive any 6P ack within a timeout (that can be the same length as that starting on the A side after the reception of the mac layer ack to the request packet) and when that expires will delete the RX cells that were 'half' opened.

With this, it is not possible to get suspicious cells allocations on the RX side. There's still the possibility that a TX side is open with the RX side not open. But for that, 6P or SF will manage a relocation.

Of course, it's obvious that I'm strongly in favor of a 6P ack definition, more than having a big timeout.

Does it make sense?

Nicola

Dear all,

SF        |REQUEST|       |timer-----|RESPONSE|
                          ^          6P         |REQUEST|      |         |RESPONSE|
MAC LAYER   |REQUEST| |ACK|        |RESPONSE| |ACK|

                                 Diego

______________________________ _________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/ listinfo/6tisch

---

From: Nicola Accettura <[email-masked]>
Date: Mon, 31 Oct 2016 17:23:55 +0100

Hi Qin,

I'm very happy for your feedback.

I was just considering the transaction as a 6P one, you have bettered off
that by introducing also the relationship between 6P and SF0 in each part
of the transaction. This is perfect now!

Actually I did not propose to delete the timeout. I perfectly agree with
you in saying that we need timeouts to preserve the system from Failed
transactions.

I was proposing instead to have a timeout on both sides of the transaction,
but shorter than the one that would be required if the transaction was
2-way:

   1. node A will start the timeout after receiving the mac-layer ack from
   node B for the ADD request: if node A receives an ADD response from B
   during the timeout window, the transaction will continue, otherwise, the
   transaction is considered as failed
   2. node B will start the timeout after receiving the mac-layer ack from
   node A for the ADD response: if node B receives a 6P ACK from A during the
   timeout window, the transaction will continue, otherwise, the transaction
   is considered failed

Please, note that, if A received the ADD response in the 'minimal' shared
cell and the dedicated TX cells are allocated just after that reception,
the 6P ACK will be sent during the same slotframe in the first dedicated TX
cell.

Just speaking about possible extensions for more complex uses: the 6P ACK
could also hold a flag to declare it as a NACK. If the timeout on node A
was expired, and it received a 6P answer out of time by B, it can send back
a NACK to let B stop its own timeout and let it delete the RX cells
previously half-opened.

What do you think?

Nicola

2016-10-31 16:20 GMT+01:00 Qin Wang <[email-masked]>:

> Your proposal is to introduce a new 6P message, i.e. 6P ACK message, into
> a transaction, then the sequence of a original 2-way ADD transaction will
> be:
> (1) node A SF0 sets "adding TX cells" OPEN, and 6top layer sends ADD
> request to nodeB
> (2) node B 6top layer receives ADD Request, SF0 sets "adding RX cells"
> OPEN, and 6top layer sends ADD Response to node A
> (3) node A 6top layer receives ADD Response, SF0 adds TX cells and sets
> "adding TX cells" CLOSED, and 6top layer sends 6P ACK to node B
> (4) node B 6top layer receives 6P ACK, SF0 adds RX cells and sets "adding
> RX cells" CLOSE.
>
> But, I still think the scheme can not avoid a Timeout. Otherwise, how node
> A or node B can stop a Failed transaction if something happens?
>
> Thanks
> Qin
>
>
>
> This confirms that the timeout should be proportional to TXATTEMPTS. And
> to the maxium backoff window. If there is only one shared cell, according
> to 'minimal', the timeout is proportional also to the slotframesize. If
> some implementation considers more than one shared cell per slotframe, the
> With this, it is not possible to get suspicious cells allocations on the
> RX side. There's still the possibility that a TX side is open with the RX
> side not open. But for that, 6P or SF will manage a relocation.
>
> <https://www.ietf.org/mailman/listinfo/6tisch>
>
>
>

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Mon, 31 Oct 2016 14:44:08 -0300

Dear all,
             I answer inline.
Regards,

                      Diego

2016-10-31 13:23 GMT-03:00 Nicola Accettura <[email-masked]>:

> I was proposing instead to have a timeout on both sides of the
> transaction, but shorter than the one that would be required if the
> transaction was 2-way:
>
>    1. node A will start the timeout after receiving the mac-layer ack
>    from node B for the ADD request: if node A receives an ADD response from B
> This is what I proposed on the initial mail; 6P propagates the MAC layer
ACK, thus becoming a 6P ACK.

>
>    1. Node B will start the timeout after receiving the mac-layer ack
>    from node A for the ADD response: if node B receives a 6P ACK from A during
>    the timeout window, the transaction will continue, otherwise, the
>    transaction is considered failed
>
> (This is 2, but numbering is automatic and gmail fails to understand this
is inline answering)
And this is the expected reverse path, doing the same as the forward path.

> the 6P ACK will be sent during the same slotframe in the first dedicated TX

Why negotiations should be done in dedicated cells? From my point of view,
dedicated cells are for data and shared cells for any kind of signalling
and/or negotiation.

> a NACK to let B stop its own timeout and let it delete the RX cells
Again, this is a possible change for 6P (and not SF0). I ask Qin and Xavi
what is their opinion
about it.

>> But, I still think the scheme can not avoid a Timeout. Otherwise, how
>> node A or node B can stop a Failed transaction if something happens?
>>
>> Thanks
>> Qin
>>
>>
>>
>> Call A the node that is requesting cells, and B the node that is asked
>> for cells. Node A sends a request and gets a mac layer ack from B. A starts
>> the timeout. B sends a packet, but it's lost. Sends another packet and it
>> is lost... until the last attempt which is successful: B gets a link layer
>> ack from A. So B allocates cells as RX.
>>
>> In fact, assume that A sent a request, B acked at MAC layer. Then B
>> (maybe after many tries, if the responses have been lost, and this is
>> possible in the 'minimal' shared cell due to collisions in big networks) is
>> finally able to send an answer that is correctly received by A and A sends
>> an ack at mac layer. B adds cells as RX and expects A to open the same
>> cells as TX.
>>
>> 'Good!' one would say.
>>
>> Of course, it's obvious that I'm strongly in favor of a 6P ack
>> definition, more than having a big timeout.
>>
>> Does it make sense?
>>
>> Nicola
>>
>>
>> 2016-10-29 18:44 GMT+02:00 Prof. Diego Dujovne <[email-masked]
>> >:
>>
>> Dear all,

---

From: Nicola Accettura <[email-masked]>
Date: Mon, 31 Oct 2016 19:18:49 +0100

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

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Mon, 31 Oct 2016 16:48:37 -0300

Nicola,
            I would try to focus on the draft, however, let me answer
briefly
the shared/dedicated point of view below.
Regards,

                               Diego

> requires its own TSCH ack from B to A.

First, I do not expect packets which are not Unicast during a negotiation.
What the SF needs to calculate the
timeout is any type of signalling confirming that the A->B request packet
has arrived to B. If this signal is
a different packet, it will take longer to arrive, but its meaning is not
different from what we need to start the timeout countdown.
So, if there is no time during the timeslot to bring upstream (to the SF)
the MAC ACK, then, it will do it in the next transmission opportunity,
which may happen in the next available slot. But the timeout countdown will
not start until that event happens.
In the way back, (the request response from B to A) there will be a MAC ACK
too, which will be in turn brought upstream (to the SF) in the same way as
it was brought the request from A to B, if there is no time in the current
timeslot, it will be done during the next transmission opportunity.

> Shared or dedicated cells can be used either for signaling and/or data.

I understand your point on the flexibility to use any of them for different
purposes, but I would prioritize higher reliability (dedicated cells) for
data, while leaving negotiations for shared cells. As a matter of fact, 6P
now allows SFs to allocate either type of cells.

>
> '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

I see that a balance on the schedule is needed  to address both scalability
and reliability. You can base your whole scheduling on shared or dedicated
cells, it is up to the SF now to decide where to expand and to decide which
type of traffic goes where. Before, there was the assumption of having only
a single best-effort track. Now we have two type of cells to decide on at
the SF. It is not specified yet on the SF0 draft, but a decision on this
matter must be taken.

> the payload IEs, and these two payloads can coexist in the same

I expect seeing opportunistic piggybacking instead of reserving a whole new
cell only for negotiation. In fact, the new cell must be negotiated itself
through the SF. Again, this may be a implementation specific, but it would
reduce power consumption.

---

From: Qin Wang <[email-masked]>
Date: Mon, 31 Oct 2016 20:19:56 +0000 (UTC)

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 Requestt2: Node A 6top sends out ADD Request, ending with MAC-ACK successt3: Node B 6top processes ADD Requestt4: Node B SF0 processes ADD Requestt5: Node B 6top prepares ADD Responset6: Node B 6top sends out ADD Response, ending with MAC-ACK successt7: Node A 6top processes ADD Response.t8: Node A 6top sends out 6P ACK, ending with MAC-ACK successt9: 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?
ThanksQin

    On Monday, October 31, 2016 2:18 PM, Nicola Accettura <[email-masked]> wrote:

 Hi Diego,

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. 

'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

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Mon, 31 Oct 2016 18:05:56 -0300

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-masked]>:

> 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.
>

---

From: Nicola Accettura <[email-masked]>
Date: Mon, 31 Oct 2016 23:09:15 +0100

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-masked]>:

>> (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)

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Mon, 31 Oct 2016 19:18:32 -0300

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-masked]>:

> 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).
>
> 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
> 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.
>
> 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:
>
>>> 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
>>> 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

---

From: Nicola Accettura <[email-masked]>
Date: Mon, 31 Oct 2016 23:29:12 +0100

Diego,

defining priorities about the management of packets is implementation
specific, I guess. But I can be wrong.

To be honest, from what I saw in practical implementations, the best is to
give the highest priority to 6P packets both on shared and dedicated cells,
because they are in charge to enlarge/reduce bandwidth starting from
'minimal'.

Data will be always be created and, if you don't give priority to 6P
negotiations, they will quickly fill up queues while congesting the small
bandwidth available. Data must be able to travel only if the network is
sufficiently capable - if there are dedicated cells. To get dedicated cells
you need first 6P negotiations.

If the network has sufficient bandwith (dedicated cells have been allocated
very quickly), data will use the average bandwidth and there will not be
many negotiations.

I know it's counter-intuitive: if you give more priority to 6P packets you
will in fact allow data to stay very comfortable in the dedicated cells
allocated.

Nicola

2016-10-31 20:48 GMT+01:00 Prof. Diego Dujovne <[email-masked]>:

> In the way back, (the request response from B to A) there will be a MAC
> ACK too, which will be in turn brought upstream (to the SF) in the same way
> as it was brought the request from A to B, if there is no time in the
> current timeslot, it will be done during the next transmission opportunity.
>
>
>>
> I understand your point on the flexibility to use any of them for
> different purposes, but I would prioritize higher reliability (dedicated
> cells) for data, while leaving negotiations for shared cells. As a matter
> of fact, 6P now allows SFs to allocate either type of cells.
>
>
>>
> I see that a balance on the schedule is needed  to address both
> scalability and reliability. You can base your whole scheduling on shared
> or dedicated cells, it is up to the SF now to decide where to expand and to
> decide which type of traffic goes where. Before, there was the assumption
> of having only a single best-effort track. Now we have two type of cells to
> decide on at the SF. It is not specified yet on the SF0 draft, but a
> decision on this matter must be taken.
>
>
>>
> I expect seeing opportunistic piggybacking instead of reserving a whole
> new cell only for negotiation. In fact, the new cell must be negotiated
> itself through the SF. Again, this may be a implementation specific, but it
> would reduce power consumption.
>
>
>>
>> Thoughts?
>>
>> Nicola
>>
>>
>
>
>
> --
> DIEGO DUJOVNE
> Profesor Asociado

---

From: Nicola Accettura <[email-masked]>
Date: Mon, 31 Oct 2016 23:49:37 +0100

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-masked]>:

>> I guess that the aim is that we don't want the ADD response to arrive
>> when the timeout is expired.
>>
>> This happens if the timeout is shorter than the unpredictable time we
>> want to estimate.
>>
>> 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.
>>
>> 2016-10-31 22:05 GMT+01:00 Prof. Diego Dujovne <[email-masked]
>> >:
>>
>>> Qin,
>>>> According to my understanding, the most unpredictable time is t2, t6
>>>> and t8, because they are associated with Retry and the length of slotframe.
>>>> (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
>>>> 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.
>>>>

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Mon, 31 Oct 2016 19:53:34 -0300

Nicola,
           I created a new thread to discuss this item.
Can you continue there so as separate the topics?
Thank you.
Regards,

                               Diego

2016-10-31 19:29 GMT-03:00 Nicola Accettura <[email-masked]>:

> If the network has sufficient bandwith (dedicated cells have been
> allocated very quickly), data will use the average bandwidth and there will
> not be many negotiations.
>
>> First, I do not expect packets which are not Unicast during a
>> negotiation. What the SF needs to calculate the