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