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

[Rahul Jadhav]

Hi Oleg,

Pls find my comments inline.

Regards,
Rahul

On 19 October 2017 at 17:12, Oleg Hahm  wrote:

> Hey Rahul,
>
> another clarification question:
>
> On Thu, Oct 19, 2017 at 11:16:17AM +0530, Rahul Jadhav wrote:
>
> > > 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.
>
> Is this your personal opinion or some IETF consensus?


[RJ] In IETF98, Pascal had presented the problem stmts related to 6lo
fragmentation and post-session there was a discussion (
https://www.ietf.org/mail-archive/web/6lo/current/msg02355.html).
Also my experience with regards to 6lo frag also points to problems similar
to what were mentioned during that session.

I agree that fragmented
> ICMPv6 messages are somewhat pointless, but to rely on IPv6 fragmentation
> for
> link layers that do not support the minimum MTU for IPv6 and do not offer
> fragmentation (like IEEE 802.15.4) it still seems to be the best choice to
> me.
> Can you elaborate a bit?
>

[RJ] i think i didnt appropriately word my stmts. I never suggested to not
support or disable 6lo fragmentation. In my experiment i have disabled it
just to check if there are any reasons why RIOT should result in 6lo
fragmentation. I found this (DAO) case and thought, may be, this  is not a
good candidate to result in 6lo frag and can be avoided and hence the mail.


> Cheers,
> Oleg
> --
> panic("Oh boy, that early out of memory?");
> linux-2.2.16/arch/mips/mm/init.c
>
> ___
> 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] RPL DAO target concat from fib

[Oleg Hahm]

Hi Rahul!

Just a small remark regarding one of your comments:

On Thu, Oct 19, 2017 at 11:16:17AM +0530, Rahul Jadhav wrote:
> 2. RIOT does not handle L2 retry-count feedback to maintain RPL metric (for
> e.g. ETX).
> Pls correct if i m wrong.

One problem here is that not all radio devices report back the number of L2
retries if this is implemented by the device itself. In some cases it is
possible to deactivate this feature and take care of L2 ACK handling and
retries as part of the device driver, but this is currently not implemented
for all drivers.

Cheers,
Oleg
-- 
HTTP Error 413: That’s what she said!


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

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 
<list-r...@cgundogan.de<mailto:list-r...@cgundogan.de>> 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,
>

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

[Koen Zandberg]

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 implementation
> > behaviour which sort of stops my network from building up.
> >
> > Scenario:
> > If i have a RIOT 6lr node and it has an FIB with, let's say, 10
> active
> > entries, then when the 6lr next sends DAO, it concatenates
> multiple target
> > containers (from multiple FIB entries) in the same DAO message. This
> > results in a packet size crossing link MTU limit (127 in my
> case) and for
> > my case i do not have 6lo fragmentation enabled. Thus the DAO is
> getting
> > dropped.
> >
> > I skimmed through the code but could not find a way to send DAO
> with max x
> > target containers, where x is predefined.
> >
> > To reiterate, if the FIB active entries are more, then RIOT
> aggregates all
> > the entries into the same DAO as target containers and forwards
> 

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

[Rahul Jadhav]

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 implementation
> > behaviour which sort of stops my network from building up.
> >
> > Scenario:
> > If i have a RIOT 6lr node and it has an FIB with, let's say, 10 active
> > entries, then when the 6lr next sends DAO, it concatenates multiple
> target
> > containers (from multiple FIB entries) in the same DAO message. This
> > results in a packet size crossing link MTU limit (127 in my case) and for
> > my case i do not have 6lo fragmentation enabled. Thus the DAO is getting
> > dropped.
> >
> > I skimmed through the code but could not find a way to send DAO with max
> x
> > target containers, where x is predefined.
> >
> > To reiterate, if the FIB active entries are more, then RIOT aggregates
> all
> > the entries into the same DAO as target containers and forwards it. While
> > aggregating if the packet crosses MTU boundary and if the 6lo frag is not
> > on then it (6lo module) will drop the packet. Thus the network wont form.
> > (i do not want 6lo fragmentation to happen for RPL control packets).
> >
> > Just want to understand, is there any way to handle this situation
> without
> > turning on 6lo frag?
> >
> > Thanks,
> > Rahul
> >
> > --[log snippet]---
> >
> > RPL: Send DAO - building internal transit
> >
> > RPL: Send DAO - building target fd00::302:304:506:3/128
> >
> > RPL: Send DAO - building target fd00::302:304:506:8/128
> >
> > RPL: Send DAO - building target fd00::302:304:506:d/128
> >
> > RPL: Send DAO - building target fd00::302:304:506:10/128
> >
> > RPL: Send DAO - building target 

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

[Cenk Gündoğan]

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. 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). 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). But with the addition of a proper
6lowpan fragmentation, we dropped that functionality.

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.

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 implementation
> behaviour which sort of stops my network from building up.
> 
> Scenario:
> If i have a RIOT 6lr node and it has an FIB with, let's say, 10 active
> entries, then when the 6lr next sends DAO, it concatenates multiple target
> containers (from multiple FIB entries) in the same DAO message. This
> results in a packet size crossing link MTU limit (127 in my case) and for
> my case i do not have 6lo fragmentation enabled. Thus the DAO is getting
> dropped.
> 
> I skimmed through the code but could not find a way to send DAO with max x
> target containers, where x is predefined.
> 
> To reiterate, if the FIB active entries are more, then RIOT aggregates all
> the entries into the same DAO as target containers and forwards it. While
> aggregating if the packet crosses MTU boundary and if the 6lo frag is not
> on then it (6lo module) will drop the packet. Thus the network wont form.
> (i do not want 6lo fragmentation to happen for RPL control packets).
> 
> Just want to understand, is there any way to handle this situation without
> turning on 6lo frag?
> 
> Thanks,
> Rahul
> 
> --[log snippet]---
> 
> RPL: Send DAO - building internal transit
> 
> RPL: Send DAO - building target fd00::302:304:506:3/128
> 
> RPL: Send DAO - building target fd00::302:304:506:8/128
> 
> RPL: Send DAO - building target fd00::302:304:506:d/128
> 
> RPL: Send DAO - building target fd00::302:304:506:10/128
> 
> RPL: Send DAO - building target fd00::302:304:506:11/128
> 
> RPL: Send DAO - building target fd00::302:304:506:12/128
> 
> RPL: Send DAO - building target fd00::302:304:506:e/128
> 
> RPL: Send DAO - building target fd00::302:304:506:9/128
> 
> RPL: Send DAO - building target fd00::302:304:506:4/128
> 
> RPL: Send DAO - building target fd00::302:304:506:6/128
> 
> 
> 
> 6lo: iface->max_frag_size = 127 for interface 6
> 
> 6lo: packet too big (254 > 127)
> 
> 6lo: waiting for incoming message.
> 
> 
> 
> ---[end of log]

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


-- 
Cenk Gündoğan

Hamburg University of Applied Sciences
Dept. of Computer Science / Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49 40 42875 - 8426
Mail: cenk.guendo...@haw-hamburg.de
Web: https://www.inet.haw-hamburg.de/


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

[riot-devel] RPL DAO target concat from fib

[Rahul Jadhav]

Hello RIOT team,

While experimenting with RIOT i found the RPL module implementation
behaviour which sort of stops my network from building up.

Scenario:
If i have a RIOT 6lr node and it has an FIB with, let's say, 10 active
entries, then when the 6lr next sends DAO, it concatenates multiple target
containers (from multiple FIB entries) in the same DAO message. This
results in a packet size crossing link MTU limit (127 in my case) and for
my case i do not have 6lo fragmentation enabled. Thus the DAO is getting
dropped.

I skimmed through the code but could not find a way to send DAO with max x
target containers, where x is predefined.

To reiterate, if the FIB active entries are more, then RIOT aggregates all
the entries into the same DAO as target containers and forwards it. While
aggregating if the packet crosses MTU boundary and if the 6lo frag is not
on then it (6lo module) will drop the packet. Thus the network wont form.
(i do not want 6lo fragmentation to happen for RPL control packets).

Just want to understand, is there any way to handle this situation without
turning on 6lo frag?

Thanks,
Rahul

--[log snippet]---

RPL: Send DAO - building internal transit

RPL: Send DAO - building target fd00::302:304:506:3/128

RPL: Send DAO - building target fd00::302:304:506:8/128

RPL: Send DAO - building target fd00::302:304:506:d/128

RPL: Send DAO - building target fd00::302:304:506:10/128

RPL: Send DAO - building target fd00::302:304:506:11/128

RPL: Send DAO - building target fd00::302:304:506:12/128

RPL: Send DAO - building target fd00::302:304:506:e/128

RPL: Send DAO - building target fd00::302:304:506:9/128

RPL: Send DAO - building target fd00::302:304:506:4/128

RPL: Send DAO - building target fd00::302:304:506:6/128



6lo: iface->max_frag_size = 127 for interface 6

6lo: packet too big (254 > 127)

6lo: waiting for incoming message.



---[end of log]
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel