Subject: [6tisch] draft-richardson-6tisch-roll-join-priority-00 --- RPL DIO message

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Jul 2017 11:59:39 +0200

In draft-richardson-6tisch-join-enhanced-beacon-02, I changed the
Join Proxy from a bit to a priority.  (lower numbers are better)
I also removed the "I"nitate bit.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   TBD-XXX     |R|join priority|         network ID            |
   +-+-+-+-+-+-+-+-+-+-+-+---------+                               |

   J  the Join prority value contains a number from 0 to 0x7f.  Lower
   
As discussed on Monday, having a way for the DODAG root to influence
whether the Join Proxy is enabled or not seems like a good thing.

Here is the core text of roll-join-priority:

   A 6LR which would otherwise be willing to act as a Join Proxy, will
   examine the minimum priority field, and to that number, add any
   additional local consideration (such as upstream congestion).  The
   resulting priority, if less than 0x7f should enable the Join Proxy
   function.

       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = TBD01|Opt Length = 1|R| min. priority  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The document has some strawman text about how/if/when the min.priority
might be updated.  (Slightly confusing in this email, the "R" in the first
diagram is "Router Advertisement", while just above here, it is "Reserved")
I made the min.priority 7 bits since the join priority is 7 bits.

I was also thinking this morning that maybe it could be 8-bits, but be signed?

These documents could be combined, and I would suggest that if there was
no thought that the first one (enhanced-beacon) might be turned over the
IEEE.  Perhaps Pascal could explain that comment from Monday.

[email-masked] wrote:
    > A new version of I-D, draft-richardson-6tisch-roll-join-priority-00.txt
    > has been successfully submitted by Michael Richardson and posted to the
    > IETF repository.

    > Name: draft-richardson-6tisch-roll-join-priority Revision: 00 Title:
    > Enabling secure network join in RPL networks Document date: 2017-07-18
    > Group: Individual Submission Pages: 6 URL:
    > https://www.ietf.org/internet-drafts/draft-richardson-6tisch-roll-join-priority-00.txt

...

    > Abstract: [I-D.richardson-6tisch-join-enhanced-beacon] defines a method
    > by which a potential [I-D.ietf-6tisch-minimal-security] can announce
    > itself as a available for new Pledges to Join a network.  The
    > announcement includes a priority for join.  This document provides a
    > mechanism by which a RPL DODAG root can disable join announcements, or
    > adjust the base priority for join operation.

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

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 21 Jul 2017 05:17:09 +0200

Hi Michael,

In the EB, there is an Information Element described in 15.4
(Synchronization IE) that contains a field named Join Metric (in version
2012 was named Join Priority). I think would be good to change the name of
the field to avoid any misunderstanding, considering that this also goes
inside an IE in the EB.

I have also a question, why not a simple binary option to decide if a node
accepts Join or not? Having a range and having the nodes calculate a value
in that range and decide whether join or not seems a little bit fuzzy.
Would be easier just saying yes or no? What would mean a Join Priority of
0x7e vs another node advertising 0x2a? How to choose and what is the actual
meaning of lower priority different than 0?

sorry if I have misunderstood your point.
regards,

2017-07-19 11:59 GMT+02:00 Michael Richardson <[email-masked]>:

> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 21 Jul 2017 05:47:47 +0000

Hello Xavi

Fully Agreed on your point in join priority.

 This new thing is not a anyway, it is the expression of a willingness, aka a preference. IPv6 has introduced the concept in RAs with RFC 4191.

The preference is NOT a metric, it is NOT to be confused/aggregated with the Rank; and to the 802.15.4 join priority that we derive from Rank for the time distribution, your point exactly.

We are extending RFC 4191 in 2 ways: 1) to use more bits because nodes are not just selecting a router but a router within a mesh and this has consequences; also a Boolean does not allow to load balance, e.g. Hou's draft on parents selection based on number of children; 2) we are adding another value which is the Proxy Preference (is that being too rich?)

If the DAG root is getting saturated (e.g. bandwidth) it should be able to signal it with lowering preferences that is propagated in DIOS. If a node is even more saturated for its own reasons (e.g. neighbor cache) it should be able to signal that with a preference that it lower than that of its parent.

Balancing and saturation are relative things, we need to provide a rationalization to compare apple to apple. OF0 does exactly that for Rank.

In order to throttle the join process we need something similar to express willingness to accept more joins/children in an abstract fashion.

We can make the mechanism optional since the problem mostly affects large networks. But I think that we must be ready because there is a saturation point where the problem will show up and another where the join will perpetually fail.

Does that make sense?

Pascal

I like the number, which rationalizes the willingness. We'll have to provide rules

Regards,

Pascal

Le 21 juil. 2017 à 05:17, Xavier Vilajosana <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Michael,

In the EB, there is an Information Element described in 15.4 (Synchronization IE) that contains a field named Join Metric (in version 2012 was named Join Priority). I think would be good to change the name of the field to avoid any misunderstanding, considering that this also goes inside an IE in the EB.

I have also a question, why not a simple binary option to decide if a node accepts Join or not? Having a range and having the nodes calculate a value in that range and decide whether join or not seems a little bit fuzzy. Would be easier just saying yes or no? What would mean a Join Priority of 0x7e vs another node advertising 0x2a? How to choose and what is the actual meaning of lower priority different than 0?

2017-07-19 11:59 GMT+02:00 Michael Richardson <[email-masked]<mailto:[email-masked]>>:

                        1                   2                   3

       0                   1                   2

...

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

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Randy Turner <[email-masked]>
Date: Fri, 21 Jul 2017 02:46:54 -0400

Hi Guys,

We have AMI networks of 4000+ nodes, and we currently employ proprietary techniques similar to what is described to address all manner of saturation we see.
Any effort to standardize methods for alleviating these issues would be welcome, as was the past drafts (and any future drafts) on neighbor table management, which is a related issue.

Randy

> On Jul 21, 2017, at 1:47 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Xavi 
> 
> Le 21 juil. 2017 à 05:17, Xavier Vilajosana <[email-masked] <mailto:[email-masked]>> a écrit :
> 
>> Hi Michael,
>> 
>> 2017-07-19 11:59 GMT+02:00 Michael Richardson <[email-masked] <mailto:[email-masked]>>:
>> 
>> [email-masked] <mailto:[email-masked]> wrote:
>>     > https://www.ietf.org/internet-drafts/draft-richardson-6tisch-roll-join-priority-00.txt <https://www.ietf.org/internet-drafts/draft-richardson-6tisch-roll-join-priority-00.txt>
>> 
>> ...
>> 
>> Michael Richardson <[email-masked] <mailto:[email-masked]>>, Sandelman Software Works
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Jul 2017 12:40:53 +0200

Randy Turner <[email-masked]> wrote:
    > We have AMI networks of 4000+ nodes, and we currently employ
    > proprietary techniques similar to what is described to address all
    > manner of saturation we see.  Any effort to standardize methods for
    > alleviating these issues would be welcome, as was the past drafts (and
    > any future drafts) on neighbor table management, which is a related
    > issue.

That's exciting to hear!!!
Is there anything that needs to be added in this Proxy Priority to permit
you to replace your proprietary mechanism with what is here being proposed?

(Note I am sticking to the word "priority" rather than preference,
but I'm open to omitting the word Join if it would be confusing)

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Jul 2017 12:44:39 +0200

Xavier Vilajosana <[email-masked]> wrote:
    > (Synchronization IE) that contains a field named Join Metric (in
    > version 2012 was named Join Priority). I think would be good to change
    > the name of the field to avoid any misunderstanding, considering that
    > this also goes inside an IE in the EB.

okay.  So what do you suggest.  Would "Proxy Priority" be meaningful enough?

    > I have also a question, why not a simple binary option to decide if a
    > node accepts Join or not? Having a range and having the nodes calculate

That's what the previous revision had.
Malisa suggested it should be a priority.

Given that a pledge may well see announcements from different parts of the
DODAG, and perhaps even might see announcements from different DODAGs (same
instanceID, perhaps connected via backbone-router draft!), I think that
starting with a priority might be good.

If it turns out this is never useful, we could amend things later to say
that only 1 and 0x7f are useful; but we won't be saving any bytes that way.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Jul 2017 12:56:14 +0200

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > This new thing is not a anyway, it is the expression of a willingness,
    > aka a preference. IPv6 has introduced the concept in RAs with RFC 4191.

I resist mixing the word "preference" into the conversation...

    > The preference is NOT a metric, it is NOT to be confused/aggregated
    > with the Rank; and to the 802.15.4 join priority that we derive from
    > Rank for the time distribution, your point exactly.

I was thinking about whether or not the Join Priority should be incremented
by some number related to the rank.

I definitely think that Join Proxy should probably be calculated in some
way related to the number of free neighbor caches available for insecured
traffic.

    > We are extending RFC 4191 in 2 ways: 1) to use more bits because nodes

So, 4191 is about Route Advertisements.
This extension is about pledges finding Join Proxy.  There is a similarity,
but I had not thought that this Join Priority to be applied to RAs.

The "R" bit that is present in this extension identifies the sender as
willing to answer *unicast* Router Solicitations.   Such RS's would be sent
securely by host nodes which have already joined, but which may have lost
their default router due to a long sleep.  Note: host nodes, not routers.

The "R" bit might not be set by a router whose neighbor cache is full.
(It still has to send beacons to keep time!)

I am open to the idea that this priority might influence a host to decide
which router to send the RS to.

    > If the DAG root is getting saturated (e.g. bandwidth) it should be able
    > to signal it with lowering preferences that is propagated in DIOS. If a
    > node is even more saturated for its own reasons (e.g. neighbor cache)
    > it should be able to signal that with a preference that it lower than
    > that of its parent.

A 6LR which has a full neighbor cache should have a very undesireable Join
Priority (i.e. a bigger number).  It might however express a relatively low
minimum join priority in the DIOs to it's children if it still has available
bandwidth.  That would naturally push the joining nodes that can hear both to
attempting to join to the children, which reduces the pressure on the
neighbor cache entries.

    > In order to throttle the join process we need something similar to
    > express willingness to accept more joins/children in an abstract
    > fashion.

    > We can make the mechanism optional since the problem mostly affects
    > large networks. But I think that we must be ready because there is a
    > saturation point where the problem will show up and another where the
    > join will perpetually fail.

    > Does that make sense?

Agreed.

Pascal, let me bring this text from me back in:

    mcr>         These documents could be combined, and I would suggest that if
    mcr> there was no thought that the first one (enhanced-beacon) might be
    mcr> turned over the IEEE. Perhaps Pascal could explain that comment from
    mcr> Monday.

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 21 Jul 2017 13:02:04 +0200

According to RFC8180, Join Priority/Metric is already calculated as a function of the RPL rank. See Section 6.1. My suggestion was to use that as-is *if* the join is allowed by the binary option in this new IE.  

> On 21 Jul 2017, at 12:44, Michael Richardson <[email-masked]> wrote:
> 
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 21 Jul 2017 11:29:01 +0000

Hello Mališa

In my view:

-         A join preference expressed as binary is too restrictive:

o   We need to express a relative weight in a normalized way, because it will express things like the load of the neighbor cache and balancing can be valuable (see Hou's work).

o   We need something akin to an objective function to compute the join preference based on various sources of load, DAG wide, node local etc...

-         also,

o   You may use a node that is a preferred join parent for joining. RPL Rank may be a tie breaker.

o   Once it ihas joined, the node would select its parents as prescribed by RPL between the candidates of least Rank. We may use RFC 4191 or an extended version in DIO of it as tie breaker.

Take care,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Mališa Vucinic
Sent: vendredi 21 juillet 2017 13:02
To: Michael Richardson <[email-masked]>
Cc: [email-masked]; Xavier Vilajosana <[email-masked]>
Subject: Re: [6tisch] draft-richardson-6tisch-roll-join-priority-00 --- RPL DIO message

On 21 Jul 2017, at 12:44, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Randy Turner <[email-masked]>
Date: Fri, 21 Jul 2017 10:25:01 -0400 (EDT)

+1 - except I think a good policy would be for join priority/preference to override rank

One way to do this would be to run the objective function, have the OF produce a list of potential parents, in OF priority order, and then walk the list and find a parent with the best preference.  Just spit-balling here...

Randy

On July 21, 2017 at 7:29 AM "Pascal Thubert (pthubert)" <[email-masked]> wrote:

Hello Mališa

In my view:

o   We need to express a relative weight in a normalized way, because it will express things like the load of the neighbor cache and balancing can be valuable (see Hou’s work).

o   We need something akin to an objective function to compute the join preference based on various sources of load, DAG wide, node local etc…

-         also,

Take care,

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Jul 2017 19:48:33 +0200

Randy Turner <[email-masked]> wrote:
    > One way to do this would be to run the objective function, have the OF
    > produce a list of potential parents, in OF priority order, and then
    > walk the
    > list and find a parent with the best preference. Just spit-balling
    > here...

Doing that would involve exposing the DIOs to untrusted strange nodes.

That would disclose the PIOs, which many people were uncomfortable with.
I'm also not sure if it would fit into the Enhanced Beacon!
BUT, it would eliminate a multicast!

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 25 Jul 2017 07:53:23 +0000

I think we’ll have to agree that we agree, Randy.

At least if your words are about the selection of the join proxy, which should be done based on our new “Willingness to be Joined”. There are tons of things that may affect that willingness, including Rank, hop count, root load, node load, nb of children, MOP, you name it… We can write a JF0 but never account for all possible variations.

Take care,

Pascal

From: Randy Turner [mailto:[email-masked]]
Sent: vendredi 21 juillet 2017 16:25
To: Michael Richardson <[email-masked]>; Mališa Vučinić <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>
Cc: Xavier Vilajosana <[email-masked]>; [email-masked]
Subject: Re: [6tisch] draft-richardson-6tisch-roll-join-priority-00 --- RPL DIO message

Randy
On July 21, 2017 at 7:29 AM "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>> wrote:

Hello Mališa

In my view:

-         also,

Take care,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Mališa Vucinic
Sent: vendredi 21 juillet 2017 13:02
To: Michael Richardson <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Xavier Vilajosana <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6tisch] draft-richardson-6tisch-roll-join-priority-00 --- RPL DIO message