anyone know if the directional air time (DAT) feature of OLSRv2 is implemented in AREDN?
My observation is that AREDN will put you on a really, really, slow link if that is one hop - versus a really fast two-hop link. After reading some "OLSR for dummies" and associated material, it seems that is one of the liabilities of OLSRv2 that the DAT is intended to mitigate.
You are here
OLSR DAT
Sat, 05/21/2016 - 21:38
#1
KE2N
OLSR DAT
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
OK - I remembered that AREDN was the second version of something in OLSR I guess it was the
option LinkQualityAlgorithm 'etx_ffeth'
which added the feature for direct Ethernet connections
So the questions that come to mind are:
1) are there plans to move to the improved OLSR version 2?
2) would this "break" compatibility with BBHN?
3) could BBHN conceivably follow?
4) is there any way to force the version we have now to do what the user wants? i.e., to prefer one route over another, or not use some really poor link (unless it was the one-and-only way to go)
5) can any of the constants in OLSR be "tuned"?
At heart this is a sort of QoS issue. As pointed out in another posting, two links with an ETX of 5 - where you have 5 hops of cost 1 versus 2 hops of cost 2.5 - are really not the same thing from the user's perspective.
I imagine a lot of the new meshes out there have only 1 route to most locations and, if there are two routes, they may both be strong ones. If you have a strong two-hop route and you get bumped off that onto a weak 1 hop route (and stuck there due to hysteresis) the effect is rather dramatic, if you are doing something interactive. More comments on this topic are likely to start showing up when meshes become more complex and more heavily used.
At its core, I suppose this is a question of using the mesh with highest efficiency, or providing a user with best (or acceptable) performance.
I'm going to take the first 3 questions off the plate first and leave the remaining for latter answering (by another or myself)
1) AREDN->ticket:135 (http://bloodhound.aredn.org/products/AREDN/ticket/135) will end up covering this. Its not the highest priority of changing the daemon right now, but considering other items are dependent upon a routing daemon change (IPv6 for example) the question will come up. What we will go to isn't known yet, OLSRd V2 will get evaluated but its not a guaranteed winner. Theres still a lot of work that can be done before this (the work on XW hardware, the recently completed 802.11n work, etc) but its going to be on the roadmap eventually to do other items, its an inevitability, its a question of 'when' which I don't have the answer to.
2) Changing routing daemons would indeed be a protocol breaking move, it would break with all devices running the current V3 protocol, be it AREDN or BBHN it would be a protocol jump from v3 to v4.
3) Of course BBHN could follow and come in sync with a new V4 protocol spec, however I think this is highly unlikely if it involves a new daemon like OLSRd v2 unless they re-affirm their EOL of LInksys hardware. I say this because the operating system on the BBHN Linksys devices is from 2007 (Kamikaze 7.09.) The kernel this far back may very likely be missing key system calls that a newer routing daemon would want to take advantage of. I was following the OLSRd v2 development and just the other day a scenario like this came up for a MUCH more recent version of the kernel, it was new enough that the code could be worked around, but so much other code inside of the programs may not be easily back ported to the much older kernel used on the BBHN Linksys devices. It would be a SIGNIFICANT effort for them to upgrade to newer kernels, and questions were raised back when I was a member of their dev team about stability of newer releases on Linksys and flash size (there may not be enough resources left on the majority of LInksys devices to handle the upgrade). There is a chance that no specialty calls are utilized that didn't exist back in 2007, I haven't run every single line of code to check and if not that could allow them a method to move forward, but I wouldn't plan on that being the case. Tack on top of that the versions of the compilers (GCC) and libraries that were used back in that version being significantly different as the years progressed and it just stacks the odds against the Linksys hardware. Not insurmountable in most cases, but would require some serious dedicated effort to work thorough and there would be no other source to lean on for help. It is a position I sure wouldn't want to be in programming for. I actually had to do that once already to get OLSRd v1 to run on the Linksys devices as newer kernel code came in to OLSRd v1 (thankfully it was a bit of code the firmware didn't need and I could chuck it out)
[corrected URL bad char]
I'll take a shot at #4 and #5:
#4) I don't see a practical or low effort way to do this in OLSRv1--define preferred links or build in some form of 'DAT'. I think our investment of time would be better spent on a next generation routing protocol that already has many man-years of effort by groups developing them. OLSRv1 is 10+ years old. OLSRv2 is getting closer to the point to be sufficiently stable that we could start using it, but this could still be 1+ years away. There are other options, e.g. BATMAN to consider. My crystal ball says the planets will all start to align in the 2017 timeframe--the options, like OLSRv2, will become sufficiently robust and routing issues become more important compared to other things to work on.
#5) OLSRv1 has several parameters that can be tuned. http://www.olsr.org/docs/olsrd.conf.5.html
I'd summarize the mesh routing issues overall:
1) Authentication method to authorize a mesh node to share routing information and join the network.
2) method to incorporate RF link performance (what 'DAT' does) into the route decision making process (which would include link quality)
3) scalability (keeping network traffic under control to do routing)
Joe AE6XE
Joe: thanks for the info and answering ALL the questions.
Your link has an invisible character at the end that prevents it from working when clicked on
http://www.olsr.org/docs/olsrd.conf.5.html%C2%A0
... now to figure out how some of those options work....
The good news is that through the growth of tunnel servers and some high(er) profile sites here in Bergen and Passaic Counties in New Jersey, we are seeing routing tables and over the air table updates using OLSR v1 become problematic. In some cases, the ability to transit the network changes while traffic is in the air and gets dropped. I have even had to "walk" through the network to get to a management page across a few hops.
We clearly need to work on link and frequency/ channel optimization, but the evolution to a less chatty routing protocol would also be a help. Thoughts?
73 and happy and blessed New Year!
Gordon Beattie, W2TTT
201.314.6964
It is generally better to create a new thread instead of reviving older threads especially when the question is not exactly the same as the original posters question.
it sounds more like you have link issues than a routing fault “walking” from admin page to admin page doesn’t impact the lower packet routing that’s chosen at each packet send by each hop along the route and is independent of what node you click the link from.
For the rest of your question you will want to refer to bloodhound to see if there are any relevant tickets or issues with any updates, if there are not then there is no change in the status and question the tickets there 100% of development related questions are handled through bloodhound.