Xavi,
The response to Nicola is very good.
Many thanksQin
On Monday, March 26, 2018, 1:53:26 AM EDT, Xavi Vilajosana Guillen
<[email protected]> 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 <[email protected]>:
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
[email protected]
https://www.ietf.org/mailman/ listinfo/6tisch
--
| Dr. Xavier Vilajosana
Wireless Networks Lab
Internet Interdisciplinary Institute (IN3)
Professor
(+34) 646 633 681
[email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
