[Battlemesh] Mesh Routing Protocol Comparison

[Dave Taht]

On Sat, May 2, 2020 at 12:28 PM Moritz Warning <moritzwarning at web.de> wrote:
>
> Thank you for the information.
> Currently I have load problems when there is not latency. Thus it prevents me from testing scalability. Imo, more routes do not necessarily equate to the same as more nodes. But that discussion may be for the next Battlemesh. :)

it certainly doesn't equate to the same, but it is something few have
tested enough.

>
> On 5/2/20 4:31 AM, Dave Taht wrote:
> > Please see the documentation for the rtod tool.
> > https://github.com/dtaht/rtod#uses-with-other-routers-in-the-loop
> >
> > A typical test I would run is to get each node announcing a few dozen
> > to a few hundred routes. This exercises the route
> > metric code, can induce packet loss, and also gives you a rough size
> > of packet updates required as your route table
> > get larger and larger.  It is also an emulation of larger mesh
> > networks like the one at wlan slovenia, except that that one,
> > also, has actual traffic. Certainly pounding actual traffic through a
> > mesh network, really helps in understanding metric
> > evolution in the real world, for which I tend to use the flent toolset.
> >
> > If it helps any, there's a talk I gave in 2014, and there were some
> > results on various protocols also presented then. We've done quite a
> > lot of work to improve wifi since, and babel, also, has been made more
> > robust.  Other protocols.... I'd kind of love to know - batman in
> > particular, gained a flow dissector finally in 4.16... , but it starts
> > with carrying a bunch of routes and to observe if anything changes.
> >
> > On Fri, May 1, 2020 at 6:26 PM Moritz Warning <moritzwarning at web.de> wrote:
> >>
> >> Can you elaborate on what you mean?
> >>
> >> On 5/2/20 3:00 AM, Dave Taht wrote:
> >>> The core of a simple test with your setup, is merely to try carrying
> >>> 1000+ routes. You don't need
> >>> more nodes.
> >>>
> >>> On Fri, May 1, 2020 at 5:50 PM Moritz Warning <moritzwarning at web.de> wrote:
> >>>>
> >>>> Hi Dave,
> >>>>
> >>>> thanks for the input.
> >>>> I really hope that I can test 1000-2000 nodes at some point. I find scaling properties of networks to be the most interesting aspect.
> >>>> But testing is hard, of course.
> >>>>
> >>>> Testing under load can be tried when I limit link quality. So far they are unlimited.
> >>>>
> >>>> On 5/1/20 6:27 PM, Dave Taht wrote:
> >>>>> I keep hoping y'all will actually test networks like this under load,
> >>>>> rather than idle.
> >>>>>
> >>>>> The flent rrul test is always a good start, and the rtt_fair tests in
> >>>>> particular, let you exercise multiple nodes on the network. Monitoring
> >>>>> convergence time under that kind of repeatable load, is quite
> >>>>> fascinating.
> >>>>>
> >>>>> also you should update to babel 1.9.2 and fiddle with the unicast mode.
> >>>>>
> >>>>> You can have even more fun with my infamous "rtod" tool (
> >>>>> https://github.com/dtaht/rtod ). If you are at all like me, it's
> >>>>> really exciting to see what happens when you put more than 1000+
> >>>>> routes on the network (mostly ipv6). I don't know what actually
> >>>>> happens with all these other routing protocols, but then again, I was
> >>>>> always the kind of kid that tossed lithium in water or aimed bottle
> >>>>> rockets at my friends...
> >>>>>
> >>>>> On Fri, May 1, 2020 at 4:17 AM Moritz Warning <moritzwarning at web.de> wrote:
> >>>>>>
> >>>>>> Hi folks,
> >>>>>>
> >>>>>> I wrote a virtual test setup that supports multiple mesh routing protocols and produces nice graphs.
> >>>>>> The whole setup is based on Linux network namespaces:
> >>>>>>
> >>>>>> https://github.com/mwarning/meshnet-lab
> >>>>>>
> >>>>>> So far, there are some preliminary results with a focus on convergence, mobility and scalability.
> >>>>>>
> >>>>>> https://github.com/mwarning/meshnet-lab/blob/master/results/README.md
> >>>>>>
> >>>>>> Keep in mind that these results are not "final" yet, as hardware limitations and pathological behavior play a dominat factor in some of the results.
> >>>>>> I hope to be able to present the refined results at the next Battlemesh and have a lively discussion!
> >>>>>>
> >>>>>> Best,
> >>>>>> mwarning
> >>>>>>
> >>>>>> Btw.: if you happen to have beefy server with good CPU/IO speed - let me know.
> >>>>>> _______________________________________________
> >>>>>> Battlemesh mailing list
> >>>>>> Battlemesh at ml.ninux.org
> >>>>>> https://ml.ninux.org/mailman/listinfo/battlemesh
> >>>>>
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> Battlemesh mailing list
> >>>> Battlemesh at ml.ninux.org
> >>>> https://ml.ninux.org/mailman/listinfo/battlemesh
> >>>
> >>>
> >>>
> >> _______________________________________________
> >> Battlemesh mailing list
> >> Battlemesh at ml.ninux.org
> >> https://ml.ninux.org/mailman/listinfo/battlemesh
> >
> >
> >
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> https://ml.ninux.org/mailman/listinfo/battlemesh



-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729