Re: [Anima-bootstrap] developments on 6tisch join scheduling

> 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

If you are asking for *content* in a Discovery Response, you are actually
asking for GRASP rapid mode (an objective included in the response message).

I'm not suggesting that this is a problem.

Regards
   Brian

On 17/08/2016 10:46, Michael Richardson wrote:
> 
> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> _______________________________________________
> Anima-bootstrap mailing list
> Anima-bootstrap@ietf.org
> https://www.ietf.org/mailman/listinfo/anima-bootstrap
> 