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, > > > > 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 <mailto:devel@riot-os.org> > > https://lists.riot-os.org/mailman/listinfo/devel > <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 > <mailto:cenk.guendo...@haw-hamburg.de> > Web: https://www.inet.haw-hamburg.de/ > <https://www.inet.haw-hamburg.de/> > > _______________________________________________ > devel mailing list > devel@riot-os.org <mailto:devel@riot-os.org> > https://lists.riot-os.org/mailman/listinfo/devel > <https://lists.riot-os.org/mailman/listinfo/devel> > > > > > _______________________________________________ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
