Xavi, The response to Nicola is very good. Many thanksQin On Monday, March 26, 2018, 1:53:26 AM EDT, Xavi Vilajosana Guillen <xvilajos...@uoc.edu> wrote: Dear Nicola, Thank you so much for your proposal and review of the draft. We did not answer before as we wanted to discuss all the comments we received during the IETF meeting last week. We did so and hence we can answer your comments. Note that I am copying here Figure 4 for reference
In your comments you propose to commit the cells at B when the 6P Response is sent, and then send a 6P-level ACK as a new packet to A, using the already allocated but still not confirmed cells. An inconsistency (e.g 6P ACK or 6P Response lost) will be detected as we are proposing in the draft, mainly because the last L2 ACK is lost. In our opinion your proposal introduces a slight advantage when the first 6P Cell is added to a schedule using the minimal cell. However it introduces a 3rd message overhead that is not needed when some cells are already in the schedule (which may be the general case in most of the 6tisch networks) Note that the minimal cell is only needed at bootstrap, and is the SF which decides the traffic that goes through it. In MSF for example, the cell traffic is balanced so all types of packets can flow through it considering its capacity. In addition, we discussed the integration of mechanisms of ASF into MSF, in particular the fact that the initial traffic directly flies through the hashed cells. In that case, the problem you are trying to address dissapears. Specifically, we see the following disadvantages: 1) if this mechanims only applies to a 6P ADD command. We are adding complexity to the mechanism without a major gain (only to ADD the first cell when nodes boot, considering the SF is not using some already pre-allocated cells. (e.g Hashing))2) if this applies to all mechanismo it is not clear how DELETE or RELOCATE works. If a cell is deleted before the end of the transaction, it can lead to a loss of connectivity between the nodes before finishing the transaction3) It is not clear how the current 3-step transaction will work with this new approach.4) Your proposal relies in the reception of the last L2 ACK for the proposed 6P ACK packet, if you do not receive it, the transaction is cancelled at B, but not at A leading to the same inconsistency you mention for the current mechanism. kind regards and thanks again for your review and comments.X 2018-03-02 11:23 GMT+01:00 Nicola Accettura <nick.accett...@gmail.com>: 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): - Node B schedules RX cells after transmitting the 6p Response and without waiting for the L2 ACK. - Node A schedules TX cells after receiving the 6p Response. - 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. - 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 -- | Dr. Xavier Vilajosana Wireless Networks Lab Internet Interdisciplinary Institute (IN3) Professor (+34) 646 633 681 xvilajos...@uoc.edu http://xvilajosana.org http://wine.rdi.uoc.edu | | Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain |
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch