Subject: [6tisch] draft-duquennoy-6tisch-asf-00

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Aug 2017 18:25:02 -0400

The ID explains how the slots are created from a hash of MAC address:

Receiver-based slotframe:  Nodes have one receive (option Rx) cell at
      coordinates derived from a hash of their MAC address.  For
      transmitting to a given neighbor, nodes maintain a cell (options
      Tx, Shared) at coordinates derived from a hash of the neighbor's
      MAC address.  For instance, a node may maintain such a transmit
      cell for each known neighbor in the IPv6 NDP cache, or to a subset
      such as the RPL preferred parent(s) or TSCH time source(s).

And this makes lots of sense to me, if the MAC addresses are uniformly
distributed EUI-64 based addresses....

Much less so if the addresses are 2-byte addresses assigned by a Join Coordinator.

While nodes have EUI-64 address built-in (I am still uncertain, btw, in the
6lo context if an ND can discover both long and short L2 addresses...) and
they could use it, it isn't clear that nodes will know the long address of
all neighbors.

So I wonder some things:
1) a naive Join Coordinator will hand out incrementing short addresses.
   Nodes closer to the J(R)C will get lower numbers, and be higher in the LLN
   mesh.  What happens to the simulation if the addresses are skewed in this
   fashion?

2) can the JRC hand out short addresses in a way that benefits ASF?

3) could/should the RPL rank be incorporated in some way into the hash?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Aug 2017 12:09:01 -0400

Simon Duquennoy <[email-masked]> 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?

    > 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.

    > 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.

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!

---

From: Simon Duquennoy <[email-masked]>
Date: Mon, 28 Aug 2017 11:12:10 +0200

I was having trouble reaching the list lately; resending here.
Simon

On Wed, Aug 23, 2017 at 6:47 PM, Simon Duquennoy <[email-masked]>
wrote:

> On Wed, Aug 23, 2017 at 6:09 PM, Michael Richardson <[email-masked]
> > wrote:
>
>>
> Agree. I will look closely into this issue.
>
>
> Agree
> 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, the pending frame bit idea basically increases likelihood of schedule
> collision. Maybe acceptable as we already are on shared slots anyway.
>
> Simon
>
>
>
>>
>> --