Re: [6tisch-security] developments on 6tisch join scheduling

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Michael

About your subdivision:

One may note that to root sees it all, and it the ultimate limit of the bandwidth that may be given to join process. 
The bigger the network the slower a given JA can accept new joins. And the deeper the JA, the more overall resources will be consumed by a join.
Since this is dynamic and dependent on the network, it may be that we need the root to provide JAs with a MTBJ (mean time between joins) that depends on the rank or something.

We can wonder if the root itself could be the proxy, being triggered by a DAR message as you described. The root can afford to maintain an EST session.
The root would arbitrate when that request is being served. And that the root may instruct in the DAC when the device is entitled to continue its join process.
For this purpose, the DIO may contain new information about root capabilities in the DODAG Configuration option. 

Cheers,

Pascal


> -----Original Message-----
> From: 6tisch-security [mailto:[e-mail]] On Behalf Of
> Michael Richardson
> Sent: mercredi 17 août 2016 00:47
> To: tisch-security <[e-mail]>
> Cc: [e-mail]
> Subject: [6tisch-security] developments on 6tisch join scheduling
> 
> 
> During discussions at IETF96, it became clear that the join ordering/time
> sequence envisioned for 6tisch would be less possible than I thought.
> The bad news is that a new mechanism might be hard to actually design.
> The good news is that I think a new mechanism would put 6tisch join and ANIMA
> bootstrap almost identical.
> 
> To go back, the proposal was:
>   1) a new pledge would send a NA with an EARO, which would turn into a
>      DAC/DAR process up to the 6LBR.  The 6LBR would let the JCE know
>      about the new node through mechanism TBD.
>      The new pledge would receive a NA in reply, which, for the pledge
>      would acknowledge that they might be knocking on the right door.
>      (A network which didn't like that node would reply in some negative
>      fashion, which naturally could also be forged)
> 
>   2) the JCE would reach out (via the proxy) to the pledge, on a schedule
>      determined by the JCE.  The JCE would control the order of joining,
>      and since CoAP would be used with using something like:
>           draft-wang-6tisch-6top-protocol-00
>      all joining nodes would remain quiet except when responding to
>      queries from the JCE.
> 
> The goal of having the pledge be passive was one of bandwidth conservation,
> the JCE would enroll only as many pledges as it felt it had available bandwidth in
> the upper parts of the MESH DODAG tree.  A 6tisch network might allocate a
> rather small amount of bandwidth for join messages, and utilizing the bandwidth
> responsabily is important.  That means never wasting any energy among the
> lower parts of the DODAG when the packets would just get dropped further
> upwards.
> 
> In discussions, it appears that the EARO as described in
> draft-thubert-6lo-rfc6775-update-00 might be replaced by the Crypto-ID of
> draft-sarikaya-6lo-ap-nd-02, and the process is slightly different.
> 
> One additional reason why the passive pledge turns out to be a problem is that
> the JCE does not actually know the wake/sleep schedule for the pledge.
> In the 6tisch case, it ought to be possible for the pledge to sync up to the
> schedule and so the proxy will know when it can transmit to it, but in order to
> keep the proxy from having to store a lot of data coming from the JCE, the JCE
> also needs to know the schedule out at the edge.  This does not seem
> unsolveable, but it was an additional concern raised.
> 
> Meanwhile, in ANIMA bootstrap, the initial contact is through a GRASP discovery
> (or DNSSD) to find a proxy.  The new pledge uses the proxy to initiate an EST
> session using the proxy.  The enrollment process in the ANIMA case is driven by
> the pledge, on the assumption that the ANIMA ACP has sufficient bandwidth for
> normal congestion control present in TCP and CoAP to deal with a limits.
> 
> What is needed is a way to adjust things so that the pledges will attempt to join
> in a way that does not overwhelm the network, and more so, that the proxy
> nodes can easily police that they are doing so.
> 
> So the idea is to use the ANIMA GRASP discovery mechanism to find a proxy, but
> in addition, in the reply, to get some kind of number to seed a backoff algorithm
> that causes the pledge to attempt to initiate the join process at times
> deterministic to the network.  I'm not talking about an exponential backoff.
> 
> This is where the hard part is, how to come up with a simple to describe, and
> simple to code algorithm which would fill up the available bandwidth, and be
> easily subdividable.
> 
> By subdividable, I mean, if we pass 5% of the join bandwidth to proxy A, at rank
> 3, that it would be able to easily pass some percent of that bandwidth to a new
> proxy at rank 4 in a way that does not mean reconfiguring the entire mesh to
> delegate bandwidth.
> 
> Removing the subdivable property, some simple pseudo-random number
> generator,
> with the right seed would be the right idea.   A good PRNG ought to span
> the available time space evenly.  I don't have a solution, but I'm trying to write
> up the requirements more clearly.
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works  -=
> IPv6 IoT consulting =-
> 
>