Subject: [6tisch] Review of draft-ietf-6tisch-6top-protocol-09

From: Nicola Accettura <[email-masked]>
Date: Fri, 2 Mar 2018 11:23:09 +0100

Dear all,

I have reviewed draft-ietf-6tisch-6top-protocol-09, I have just one remark.

The protocol is sub-optimal, requiring additional mechanisms to fix
inconsistencies, and being in the end not energy efficient as desired.

In figure 4 at page 7, the L2 ACK to the 6P Response is used as the 3rd
part into a 3-way negotiation (even though it is identified as 2-way
transaction; similar arguments can be reproduced for the 3-way transaction,
that should be indeed a 4-way negotiation). This is confirmed by the
current implementation of OpenWSN (
https://github.com/openwsn-berkeley/openwsn-fw/blob/develop/openstack/02b-MAChigh/sixtop.c#L924)
where one or more cells are added to the schedule of mote B after receiving
the L2 ACK.  Not sure if this should be called as layer violation, I
understand that sometimes cross-layers tricks must be taken into account.
However, the point that I see as a possible performance issue, is that the
closure of the 3-way negotiation is decided by node B, that has to
retransmit a 6P Response until it is correctly acknowledged. *If after all
retransmissions the L2 ACK is not received, there will be an inconsistency,
as also described in Figure 31 at page 31 of the draft. It is very likely
that a L2 ACK would be lost due to the very well understood exposed
terminal problem.* This happens in fact when bootstrapping very dense
networks, since all transactions will happen simultaneously on the minimal
shared cell.

*Even though the protocol was intended to be easy and simple, an additional
mechanism to deal with inconsistencies and fix them is needed.*
Instead, *an option could be to avoid inconsistencies, without then having
to make patches by elaborating mechanisms to fix them. *Easily and simply,
by enabling the following things (while detailing I am referring to Figure
4 in the draft):

   1. Node B schedules RX cells after transmitting the 6p Response and
   without waiting for the L2 ACK.
   2. Node A schedules TX cells after receiving the 6p Response.
   3. Node A sends an acknowledgment at 6p layer (6p ACK) after receiving
   the 6p Response using the new allocated dedicated cells, where the only
   possibility of collision would be very very unlikely.
   4. Node B starts a 6p timeout waiting for the reception of the 6p ACK,
   if this one has not been received yet, and if the 6p Response has been
   retransmitted the maximum number of times. When the timeout expires, the RX
   cells previously allocated (at the previous point 1.) are deleted by node
   B's schedule. Actually, this timeout will not be activated most of the
   times, since the 6p ACK would be received just after the first 6p Response
   received by node B in Figure 31.

>From an energy-saving point of view, there are two choices:

   - (more energy-efficient) sending a single 6p ACK that will avoid node B
   to retransmit many times the 6p Response if the L2 ACKs were missed.
   - (less energy-efficient) as in the current draft version, with the
   energy consumption resulting as the sum of the following: (i) node B
   retransmitting many times the 6p Response; (ii) node A transmitting packets
   that will not be received, due to inconsistencies, (iii) new 6p
   transactions to fix the inconsistencies.

Best regards
Nicola