I was having trouble reaching the list lately; resending here. Simon
On Wed, Aug 23, 2017 at 6:47 PM, Simon Duquennoy <[email protected]> wrote: > On Wed, Aug 23, 2017 at 6:09 PM, Michael Richardson <[email protected] > > wrote: > >> >> Simon Duquennoy <[email protected]> wrote: >> > 1) As we're hashing the MAC address, the cells coordinates should be >> > uniformly distributed regardless of the input. Or are you concerned >> about the >> > hash function we selected, SAX? (which might indeed perform poorly >> in the >> > case of consecutive 2-byte addresses!). My implementation only >> supports >> > EUI-64 so far, so I haven't experimented with 2-byte addresses. >> >> I don't know; I'm saying we'd better check. >> Two addresses that differ by one bit is just not a lot of entropy to put >> *into* the hash. No hash function can extract more entropy than you put >> in. >> What it can do is smear the entropy around, and the question is how well >> does >> it work in practice? >> > > Agree. I will look closely into this issue. > > >> > 2) If we make the hash function configurable, with the help of the >> JRC, we >> > could ensure that nodes all get a unique slot assigned. If there is >> interest >> > I'm happy to include this in the draft. >> >> I think that hash function, if you want to make it configurable, should be >> done through DIO Options, not through the JRC. If randomized 2-byte >> addresses are better, it would be good to know that. >> > > Agree > > >> >> > 3) I don't think so, because nodes may have outdated views of their >> > neighbor's rank. I'm assuming what you have in mind is to provision >> more to >> > nodes close to the root. One possible way to handle dynamic loads >> would be to >> > use the frame pending bit in 802.15.4 frames, and schedule >> consecutive slots >> > on-demand. Thoughts? >> >> A child will always know what the parent's rank is, and a parent will >> always >> know what rank it announced to the child in the last DIO. The child >> could >> have missed a new DIO announcing a new rank, it is true. I think that we >> could make it work. >> > > Could make it work somehow but IMO the value of ASF is in the guaranteed > consistency at all times, i.e., no node ever has a transmit cell to a > neighbor that does not listen to it. When you transmit to a neighbor using > its hash as coordinates, you know the neighbor is listening. > > If the rank is part of the equation, there is a risk of transient > inconsistency. > > >> Yes, provisioning more bandwidth closer to the root is one thought I had. >> The pending frame bit could work to extend the duration of the slot, but >> that won't help if that slot is allocated to another child! >> > > Yes, the pending frame bit idea basically increases likelihood of schedule > collision. Maybe acceptable as we already are on shared slots anyway. > > Simon > > > >> >> -- >> Michael Richardson <[email protected]>, Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
