[Battlemesh] Wireless. Mesh. Battle. The. What?

[Albert Rafetseder]

Hi Paul and folks,

Am 23/04/17 um 23:30 schrieb Paul Fuxjaeger:
> hello people,
>
> temperature is rising in Vienna, and time to warm up the testbed
> discussion once again :P

OK, I'll bite!

> The Background:
(...)

I can't comment on that background really --- V10 will be my first time
to attend Battlemesh. Please take my remarks below with a grain of
newbie salt accordingly.

> 1) ... double down NOW on finding the one measurement setup which many
> participants are interested in? If there is broad consensus well ahead
> of the event we can do anything we want - and local team will try its
> best to support the preparations.

I for one did not see "broad consensus" coming in the discussion that
Gui initiated back in December 2016 (thanks again!), nor is time "well
ahead of the event" now.

(However, if this is how a majority thinks the testbed should be
organized, I'm happy to support it regardless.)

> 2) ... skip coordinating a large measurement campaign and simply let
> happen whatever spontaneously happens beside
> Hacking/Talks/Workshops/Socialevents?

I like the idea, and it's a trivial fall-back if other approaches fail
to materialize. When investigating issues that are relevant for more
than one protocol, it would be good to synchronize to advance community
wisdom. I'm thinking about the weather radar emulator that you proposed,
for instance.

> 3) ... aim for a set of coordinated "new feature tests" instead. E.g. we
> assist each other making yet untested implementations of protocol Y in
> firmware X work stable in a larger network? One after the other.

I'm neither a protocol nor firmware maintainer, so I have no opinion on
this. But again, if I can help, I will.

> 4) ... something else entirely that has good chances of success in a
> typical battlemesh context? :D
>
> What's YOUR take?

TL;DR: Decentralize testbed responsibilities, then re-mesh as seems
attractive to you.

I'm thinking about slicing the testbed question along a few lines. I'd
like to start from a personal itch that the Battlemesh testbed perhaps
can scratch, and extrapolate from there.

I have a rough idea for a FunkFeuer-specific setup that I would like to
run on whatever hardware people are willing to lend. As selfish as this
sounds, it would help the local community debug the next-gen,
OLSRv2+IPv6 enabled firmware. Also, I hope the setup will be useful for
the OLSR people too.

I *do not* have too concrete an idea about what to test other than basic
installability and functioning of the network. I hear `flent` is a
useful tool for the latter, and nicely automates the usual
TCP/UDP/ICMP/IP based stuff that you could run manually as well. (Oh
wait, I sure want to test against the weather radar emulator just for
the heck of it!)

But really, I would appreciate your help figuring out what to actually
test/compare, dear battlemeshers!


Summing up and abstracting slightly,
* I have a test SUBJECT that probably bores most attendees because they
will not use a FunkFeuer firmware in their meshes.
* My OBJECTIVE is very basic: The network should "work", i.e. route
packets at bitrates within maybe an order of magnitude of what the PHY
layer gives, and at VoIP compatible latencies (or better, of course).
* I mentioned one TOOL I think could be used to check this.

Let's do this exercise for the radar emulator, which is a TOOL in itself
already:
* Any fw/proto could be the SUBJECT to test this against!
* The OBJECTIVE is to quantify/qualify the influence of the emulator,
probably using network benchmarks similar to the above.

Going over the previous discussions on the mailing list briefly, people
mentioned various subjects, objectives, tools already:
* 802.11s versus IBSS
* airtime usage
* every possible firmware
* Google WiFi, Eero
* more modern hardware
* routing tables of death / Joker
* packet power control
* L3+roaming
* radio diversity
(and a few more.)

So here is the "decentralization" step: If *you* care about a specific
thing, then *you* should go and motivate others to use / look at / try
it, invite people to work with you, etc. --- Devise an interesting
scenario that every protocol wants to test. Create a tool that is useful
for everybody. Bring the ultimate repeatably-testable firmware.
Whatever. Own your idea! Help implement it on site!

And this is how I hope thing would mesh, then: Different routing
protocols / firmwares test for the same objectives using the same tools.
Different tools are tested for the same objective. Different objectives
are deemed relevant for different protocols and firmwares. And so on.
Anyone gets to choose what to implement, as they see fit.


Finally, back to my personal itch again, I'll end with a few calls for help:

Kind proposers of test objectives, can you please help me find tools for
my test firmware so I can look into what you proposed? Also, is there
anything else you think I should test for?

Kind proposers of tools, can you please support me running tests? Do you
have beta software you want me to run so you can finish it?

Kind maintainers of other firmwares and routing protocols, care to take
a look at the tests I'll run, and perhaps repeat them on your setup? Or
do you have tests in mind that you think are a good fit for me too?

Best,
  Albert.

> I will copy comments in this thread to our etherpad for persistence:
> https://etherpad.funkfeuer.at/p/testbed
>
> Let's nail this down in the next two weeks.
>
> cheers
> -paul
> #WBM10 local team
>
>
>
>
> References:
> previous threads on the list for context:
> http://ml.ninux.org/pipermail/battlemesh/2016-December/005263.html
> http://ml.ninux.org/pipermail/battlemesh/2017-March/005380.html
> http://ml.ninux.org/pipermail/battlemesh/2017-March/005407.html