Re: [riot-devel] RPL DAO target concat from fib

[Landsmann, Martin]

Hey Rahul, Cenk, Koen,


> 6lo frag is not a good option to use and should be avoided as far as possible.
right, but as we all know it cannot be achieved all the time.

> Supporting target aggregation in DAO without depending on 6lo frag
I think that would be the right direction for mitigating the symptom of sending 
elidable redundant information in DAOs options, which exceed the MTU.

I don't remember exactly if the rfc6550 et al. restrict the behaviour of 
constructing and distributing DAO transit/target options to parents in solely a 
single packet.
If splitting the downward information does not violate the RFCs, then taking 
the MTU into account up to a cetrain degree, would be just an implementation 
specific detail and probably the way to go (again).

But I would always prefer letting the underlying layer to provide fragmentation 
over an customized approach.


Best regards,

Martin

Von: devel [devel-boun...@riot-os.org]" im Auftrag von "Koen Zandberg 
[k...@bergzand.net]
Gesendet: Donnerstag, 19. Oktober 2017 08:19
An: devel@riot-os.org
Betreff: Re: [riot-devel] RPL DAO target concat from fib


Hey Rahul,

Unfortunately I don't have time right now to read and comment on your email in 
depth :(
About the ETX metrics for RPL, please have a look at #6873 and #7450.

I want to take a better look at your ideas and proposal in the weekend.

Regards,
Koen Zandberg

#6873: https://github.com/RIOT-OS/RIOT/pull/6873
#7450: https://github.com/RIOT-OS/RIOT/pull/7450

On 10/19/2017 07:46 AM, Rahul Jadhav wrote:
Thanks Cenk for giving a clear picture. Some comments inline...
In general, I feel this is important to be handled, since even in small network 
this would result in DAO fragmentation and will impact its performance.

Also there are some other points i wanted to understand/clarify:
1. Currently RIOT does not handle L2 ACK for determining whether L2 send was 
successful or not.  This feedback is not used at RPL/6lo layer. Scenario: A 
node receives a DIO from parent and sends a DAO. But lets say this DAO could 
not reach the parent. In this case L2 ACK would have failed and the child node 
could have handled it to switch parent. Even if K bit is set in the DAO, and if 
DAO-ACK is not received, the child node wont come to know since there is no 
state/timer maintained to handle this. Essentially this will lead to child node 
believing that it is connected to the network but the downstream path is never 
actually established.
2. RIOT does not handle L2 retry-count feedback to maintain RPL metric (for 
e.g. ETX).
Pls correct if i m wrong.

Thanks,
Rahul

On 19 October 2017 at 01:00, Cenk Gündoğan 
> wrote:
Hey Rahul,

you are correct. The current RPL DAO building routine does not take
into account the MTU size, which is IMO the appropriate approach,
because on that level (ICMPv6) there is usually no knowledge about the
link-layer in use.

[RJ] True.

If I understand you correctly, then you basically
want to move the fragmentation from the 6lowpan layer up to the
ICMPv6/RPL layer (and only for DAOs).

[RJ] Thats exactly what I had in mind.

I think in one of the older
iterations of our RPL implementation we once had a functionality to
limit the number of Target Options in the DAO to a specific number
(configurable on compile-time).

[RJ] This would have been a real nice feature. Supporting target aggregation in 
DAO without depending on 6lo frag. In the future, proposing/implementing prefix 
eliding (the way 6loRH does for SRH or by simply using 6lo CID) between target 
containers and standardising it would make sense ! Considering that DAO 
consumes the most amount of RPL control traffic, i feel this can be fairly 
important.

But with the addition of a proper
6lowpan fragmentation, we dropped that functionality.

[RJ] 6lo frag is not a good option to use and should be avoided as far as 
possible.


I may take a look at it during the weekend. If I remember correctly,
then we used to have a further parameter to the "send_DAO" function that
tracked the number of already sent Target Options. Further calls to
"send_DAO" would then add the next Target Options. If such functionality
is needed (@bergzand, @BytesGalore, @smlng any comments on this?) then
we should aim to come up with an unintrusive approach to activate /
deactivate such a behaviour with compile flags.

[RJ] Wouldn't a simple compile-time flag such as DAO_TARGET_CONCAT_NUM=X be 
sufficient, where X could be 0 (no concat, send only 1 target container which 
will be node self IP addr), -1(for full concat, current implementation), and 
anything else which means non-self target container count. The other way to 
define such a flag would be DAO_TARGET_CONCAT_SZ=Ybytes ... which defines 
number of bytes instead of target count.


Cheers,
Cenk Gündoğan

On 17-10-19 00:00:34, Rahul Jadhav wrote:
> Hello RIOT team,
>
> While experimenting with RIOT i found the RPL module 

Re: [riot-devel] IoT technology survey

[Landsmann, Martin]

Hi Michael, hi Emmanuel,

IMHO its not a really surprising outcome.
We (especially me) just have a very restricted, not saying stubborn, impression 
that IoT is only == "some kind of sensor/actuator network driven by small 
microcontrollers".
But the buzzword IoT is commonly considered everything not being a classic 
computer and connected with the internet, preferably but not necessarily over 
some wireless connection.
So a smartphone, tablet, a fritzbox with a webserver, heating system 
steerable/configurable with an App over wifi, fringe that spams me with tweets 
to buy milk ... fits this buzzword. And in the named cases the devices often 
use some sort of linux providing a web-service for login/configure stuff.

Best regards,
Martin

Von: devel [devel-boun...@riot-os.org]" im Auftrag von "Emmanuel Baccelli 
[emmanuel.bacce...@inria.fr]
Gesendet: Freitag, 15. April 2016 13:49
An: RIOT OS kernel developers
Betreff: Re: [riot-devel] IoT technology survey

Hi Michael,
Yes, the results are somewhat puzzling.
Maybe the people who answered the survey were probably of the "rasberryPi=IoT" 
type, which might explain some results.
With this in mind, there is probably something to get out of the results.
Best,
Emmanuel

On Fri, Apr 15, 2016 at 2:43 PM, Michael Frey 
> wrote:
Hi,

Am Di, 15.03.2016, 11:15, schrieb Emmanuel Baccelli:

> https://www.surveymonkey.com/r/AGILEIoT

so, here are (if I see this correctly) are the results

https://ianskerrett.wordpress.com/2016/04/14/profile-of-an-iot-developer-results-of-the-iot-developer-survey/

I'm a bit puzzled about the 11.2 % considering php an IoT programming
language (and apparently using it) - on the other hand there are 73 % who
consider Linux an IoT operating system. Anyway, maybe it's worthwhile for
somebody to read it during hers/his lunch break.

Best,
 Michael
--
Dipl.-Inf. (FH), M. Sc. Michael Frey
Humboldt-Universität zu Berlin
Department of Computer Science
Rudower Chaussee 25
12489 Berlin, Germany

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Populating neighbor cache without ND

[Landsmann, Martin]

Hi all,

> @Emmanuel: Maybe we should consider creating a STALE entry in the neighbor 
> cache for neighbors heard of, but without bidirectional check at ND level yet?
I think this will not help in a situation where a neighbor node does not use ND.
The entry will be pruned after some timeout when no update has been done, and 
the update-interval is then highly dependent on the routing-protocol(-settings).
But generally I think its a good idea to have a STALE state for neighbor-cache 
entries in lossy networks.

I propose that the FIB updates the neighbor-cache with LL-addresses of added 
FIB-entries.
They are supposed to be used in forwarding and considered as a reachable 
next-hop by a routing-protocol.
I think there's no need to extend RPL to fill the neighbor-cache.

Best regards,
Martin

Von: devel [devel-boun...@riot-os.org]" im Auftrag von "Joakim Nohlgård 
[joakim.nohlg...@eistec.se]
Gesendet: Donnerstag, 10. März 2016 16:30
An: RIOT OS kernel developers
Betreff: [riot-devel] Populating neighbor cache without ND

(Continuing from a thread on Github: 
https://github.com/RIOT-OS/RIOT/issues/5025)

tldr; It should be possible to use RPL standalone without 6lowpan-ND.

Currently the only way to add neighbor cache entries is through neighbor 
solicitations+neighbor advertisements (ND) or through the shell. My initial 
opinion was that RPL should add neighbor cache entries for all DAOs it receives
​.

​@cgundogan
 argued that the lowpan network may be asymmetrical in what packets get through 
between nodes, so a DAO reception may not guarantee
​ reliable​
bidirectional communication between two link-local addresses
​:​

​RPL states in the RFC that it requires bidirectional links to function 
properly. (6Lo-)ND is one way to get those bidirectional links, so that the 
ncache itself only contains entries that are bidirectional. Receiving a DAO is 
not a strong indication whether the link is bidirectional or not. DIO traffic 
is (mostly) multicast (and sparse) in the downwards direction, while DAO 
traffic is (mostly) unicast in the upwards direction. Due to the known problems 
of wireless technology (interference, etc.) and "enhancements" of link layers 
(e.g. to apply QoS for certain traffic patterns, multicast, unicast, etc.) the 
link can be highly asymmetric. Receiving a DAO does not mean that my DIO, which 
I send out e.g. 1 minute ago, has reached that same child.​

So, a summary of the scenario, written by Cenk:

To summarize again so that I understand you correctly:
You have 2 nodes (A and B)
A is the RPL root and has a neighbor cache (+ (6Lo-)ND is running)
B is a normal rpl router who joins the DODAG of A and has no neighbor cache and 
no ND running.
A will always expect an entry in its neighbor cache before it can send out 
traffic to B,
but since B is not participating in the RS/RA-NS/NA exchange with A, A will 
never get an entry for B in its ncache.

​Emmanuel further suggested:

Maybe we should consider creating a STALE entry in the neighbor cache for 
neighbors heard of, but without bidirectional check at ND level yet?

It was suggested that we would continue the discussion on the devel mailing 
list.

Does anyone have more ideas or suggestions on how to populate the neighbor 
cache without ND?

This is especially interesting for interoperability with ​other systems which 
may not even have a 6lowpan ND implementation, and can only do RPL.

Best regards,
Joakim
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Association time in mobile RPL/6lowpan networks

[Landsmann, Martin]

Hi Adam, hi Cenk,

 Has anyone tested the amount of time it takes for a node (full or reduced 
 function) to join an RPL routed 6lowpan network?
Not a particular range, but I can confirm that the time varies until a RPL 
topology converges in whole, and that it varies for a single node to join.

Regarding the further discussion, I'm not convinced if we should send periodic 
DIS messages.
Even if they get lost, DIOs are disseminated repeatedly by all nodes in a DODAG 
when trickle fires [1].
Concerning LLNs I don't like to send additional packets periodically at all.
In my opinion it just drains the energy of a node with small to no benefit.
Even if a node is not answered with a DIO directly when sending a DIS, 
eventually a DIO will arrive from a neighbor node (assuming one is present).

Resetting the trickle timer from applications sounds like a good opportunity 
for debugging and testing things.
Just as Adam I also think such feature should be only available for debugging 
and testing.
Resetting the trickle timer in normal operation from an application sounds 
for me like interfering with the routing protocol,
or even attacking the topology ;)

 ...anything like this should be runtime configurable as long as such 
 configurability doesn't adversely effect battery life, code 
 complexity/readability, etcetera in a massive way
I think the most impacting problem with such approach is that every convenience 
function/structure we provide will produce more bytes used on the ROM and RAM.
RPL is used on nodes with few kB RAM and ROM and it must share this room with a 
network stack and further productive applications.
Concerning this, I obviously vote for compile time configuration :)

These are just some thoughts and my personal opinion.

Best regards,
Martin

[1] https://tools.ietf.org/html/rfc6550#section-8.3

Von: devel [devel-boun...@riot-os.org] im Auftrag von Adam Hunt 
[voxa...@gmail.com]
Gesendet: Freitag, 22. Mai 2015 07:09
An: RIOT OS kernel developers
Betreff: Re: [riot-devel] Association time in mobile RPL/6lowpan networks


I like the idea of sending periodic DIS messages but I absolutely believe that 
it should not only be optional but  that it be configurable at runtime.

Honestly, I am a firm believe in the idea that virtually anything like this 
should be runtime configurable as long as such configurability doesn't 
adversely effect battery life, code complexity/readability, etcetera in a 
massive way. This is something that Linus has absolutely right with Linux; 
policy don't shouldn't be written in kernel space stone; everyone had different 
requirements and altering the way an OS behaves from the (sensible) defaults 
shouldn't require altering mainline code and maintaining a private branch if at 
all possible. Ideally everything should be runtime configurable, if that's not 
possible it should be configurable at boot, if that for some reason isn't 
possible it should be compile time configurable.

On Wed, May 20, 2015, 11:53 PM Joakim Gebart 
joakim.geb...@eistec.semailto:joakim.geb...@eistec.se wrote:

On May 21, 2015 8:37 AM, Cenk Gündogan 
cenk.guendo...@fu-berlin.demailto:cenk.guendo...@fu-berlin.de wrote:

 Hey Adam,

 I am currently adopting RPL to our new network stack and while doing so,
 I also added sane functionalities which were plainly missing in the old 
 implementation.
 This also includes sending a DIS when initializing RPL for the first time.
 However,  I am just now realizing that such a DIS can get lost in our typical 
 LLN case - it may make sense to send a DIS periodically until a DIO is 
 received?
 Does anyone has an opinion on this?

Good idea, as long as the periodic interval is large enough to not waste power 
or cause interruptions in normal traffic if there is no other rpl node on the 
network.


 Forcing a DIS from userspace sounds like a good feature. It may help in 
 testing/debuging the dodag tree interactively.
 I also thought about reseting the trickle timer from userspace to enforce 
 DIOs.

+1 for this. It would be nice to have some shell commands to call these 
functions too.

Best regards,
/Joakim


 Cheers,
 Cenk


 On 21.05.2015 04:36, Adam Hunt wrote:

 That's great. Is there any way to force a node to send a DIS message from 
 userspace?


 On Wed, May 20, 2015, 5:34 PM Oleg Hahm 
 oliver.h...@inria.frmailto:oliver.h...@inria.fr wrote:

 Hi Adam!

  Has anyone tested the amount of time it takes for a node (full or reduced
  function) to join an RPL routed 6lowpan network? I realize that it's very
  likely to vary quite a bit depending on the network, I'm just curious if
  anyone has an approximate range.

 As you said: it depends quite a bit on the network and the parameters. Since
 nodes on the current RPL implementation won't send proactively DIS messages
 and the interval of sending DIOs increases, it will usually take just a 
 couple
 of seconds if you try to join the network right after bootup, but can take