I'd like to keep 6P simple, and just have a mechanism to detect inconsistencies. I believe roll-back to a previous schedule generation adds too much complexity. From an implementation point of view, cells that are in the process of being reserved (i.e. 6P add request sent but no response received yet) should be marked as "reserved" and only committed to the schedule once the 6P transaction if over. I believe this captures Nicola's idea, but turning it into a recommendation for implementers, rather than a protocol feature.
On Mon, Nov 21, 2016 at 9:56 PM, Xavi Vilajosana Guillen < xvilajos...@uoc.edu> wrote: > Hi Yatch, > my 2 cents inline > > >> I've been thinking about how to handle inconsistencies. I know the >> current draft has an inconsistency detection mechanism with generation >> management; just wondering if there is another way or a supplemental >> mechanism to deal with such a situation. >> >> We decided at the IETF meeting last week to reduce the number of > generation counters from 2 to 1 (2bits field) as now 6P commands can add > different types of cells so we need to account for transactions now. I > state that here to outline that the proposed mechanism is very simple. At > every transaction we increment a generation counter. It cannot happen that > the two sides of the transaction have inconsistent counters. If this > happens, then the schedules are reset. I agree that this is detected after > the error has occurred. > > >> I thought that the 2-phase commit (2PC) protocol could be useful >> here. Then, I found the nice idea by Nicola in the ML archive. In >> terms of the 2PC protocol, 6P ACK is Commit. 6P NACK (mentioned in >> another email by Nicola) is Abort or Rollback. >> # We may need another type of message to acknowledge Commit or Abort. >> >> An advantage of this approach is that 6P can resolve an inconsistency >> when it occurs at the least cost, by cancelling the concerned >> operation alone. An apparent disadvantage is adding further complexity >> to 6P. >> > > it adds complexity and more messages over the air, which are costly and > can also fail (e.g external interference). What happens if we loose the 6P > NACK? How the NACK sender know that the NACK has been received? > >> >> What others think...? >> > > I like to answer with another question. What causes less overhead, 2 bits > per each 6P command or 1 or 2 extra packets per transaction (assuming only > write/state modification transactions). For me the former is way simpler. > > regards, > X > > > >> >> Best, >> Yatch >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> > > > > -- > Dr. Xavier Vilajosana Guillén > Research Professor > Wireless Networks Research Group > Internet Interdisciplinary Institute (IN3) > Universitat Oberta de Catalunya > > +34 646 633 681| xvilajos...@uoc.edu | Skype: xvilajosana > http://xvilajosana.org > http://wine.rdi.uoc.edu/ > > Parc Mediterrani de la Tecnologia > Av. Carl Friedrich Gauss, 5. Edifici B3 > 08860 Castelldefels (Barcelona) > > > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
