[B.A.T.M.A.N.] Fwd: Re: [Freifunk.luebeck-devel] [Freifunk-Bonn] On compat version 15 in the Freifunk-KBU network

[B.A.T.M.A.N.] Fwd: Re: [Freifunk.luebeck-devel] [Freifunk-Bonn] On compat version 15 in the Freifunk-KBU network

[Jan Luehr]

[-- Attachment #1: Type: text/plain, Size: 7229 bytes --]

Hello,

sorry for forwarding - mail got filtered...

Betreff: 	Re: [Freifunk.luebeck-devel] [Freifunk-Bonn] [B.A.T.M.A.N.] On 
compat version 15 in the Freifunk-KBU network
Datum: 	Sun, 19 May 2013 14:49:45 +0200
Von: 	Jan Lühr <ff@jluehr.de>
An: 	"Allgemeine Mailingliste zum Freifunk Köln, Bonn und Umgebung" 
<freifunk-bonn@lists.bonn.freifunk.net>
CC: 	The list for a Better Approach To Mobile Ad-hoc Networking 
<b.a.t.m.a.n@lists.open-mesh.org>, 
freifunk.luebeck-devel@asta.uni-luebeck.de



Hello,

Am 19.05.2013 um 12:40 schrieb Simon Wunderlich:

>  Hello yanosz,
>
>  On Sun, May 19, 2013 at 10:52:01AM +0200, Jan Lühr wrote:
>>  Hello folks,
>>
>>  I'd like to give some thought's for the upcoming batman-adv release, especially on compat version 15. This somewhat summarizes my discussion with T_X on the wireless community weekend (WCW -- 2013-05-10 - 2013-05-12).
(...)
>>  It's not my intention to bash on batman-adv in general or to start flame-wars (like: batman-adv vs. olsr or something else) - I'd like to provide some statement on the impact of the upcoming protocol changes.
>
>  Thanks for your feedback. Yes, we are preparing a compat bump (actually for a long time now) and it's good to discuss it. :)

Thanks for your detailed answer - I'll cut some parts for better readability.

>
>>
>>  1. The upcoming protocol change appears to be painful - we have no suitable migration strategy.
(...)
>>  13 nodes in the next months - by that, we'll probably have some compat 13 ones for at least 1/2 year. There is no way of telling newer nodes to use compat version 13. Since some "supernodes" (dedicated servers) are part of the batman-adv cloud, we need twice the servers as well.
>>  Upgrading to compat version 15 will require a huge amount of work: New infrastructure (servers) must be deployed and nodes meshing with each other must be upgraded in parallel.
>
>
>  Btw, it's interesting that you use compat version 13  - only one release had that included, and we are
>  on compat 14 for quite some time ...
>  [1] http://www.open-mesh.org/projects/batman-adv/wiki/Compatversion

(...) - yes, I know. Theses nodes are quite old. I guess this somewhat illustrates the upcoming situation.

>>
>>  2. Backwards-compatilibilty doesn't seem to be a design target.
>
>  Actually, that is one of the main design targets. We are aware that with our current packet type design,
>  we cannot change even parts of the protocol without breaking compatibility. This has bothered us for quite
>  some time and we have worked on solutions to prevent compat bumps as good as possible. We have introduced
>  different means [2,3] to be able to add new features, change features, let sub-features update their
>  protocols (by using TVLVs) without breaking the rest and ensure compatibility on their own [3], route even
>  yet unknown packets on their own [2], ... Actually the TVLV thing is pretty similar to other protocols
>  (e.g. IEEE 802.11) which use that to ensure backwards compatiblity for years. The goal is to keep the
>  compat bump stable for at least a decade now, if not longer. No guarantees of course, but this compat
>  bump is made to CREATE backwards compatiblity. :)
>
>  Note that the compat bump is not released yet but still only in our development branch.
>
>  [2] http://www.open-mesh.org/projects/batman-adv/wiki/Packet-types
>  [3] http://www.open-mesh.org/projects/batman-adv/wiki/TVLV

Thanks for the details. I understand your reasons for changing the protocol - and I'm perfectly fine with that. I know that manets are an area of active research.
Bit this won't be a problem at all, if upcoming batman-adv versions are capable if "speaking" older compat versions. If done so, we (as in Freifunk-KBU) would be able to simple "choose" the compat version for our network - and pick a newer one if needed.

>>  Since batman-adv depends on the kernel (old batman-adv versions won't build with recent kernels) using 14 will not be an option in a few months: If some router hardware requires recent Kernel / OpenWRT releases version 14 might no longer be used.
>
>  I think it would be possible to maintain older releases of batman-adv and add compatibility code for
>  newer kernels. We are doing the same now to provide compatibility for older kernels [4]. We would
>  be happy if someone (you?) would take over that job, I guess it would mostly mean to test new kernels
>  and add a little bit of compat code like we do for the old kernels. You are welcome to contribute
>  such "stable" versions. :)
>
>  [4] http://git.open-mesh.org/batman-adv.git/blob/refs/heads/master:/compat.h

Hmm... well, I'm not into kernel development, but I could maintain some CI services for testing. I'll ask some our folks on our next community meeting.
>
>>  ->  We're aware, that we cannot use version 14 in some months
>>  ->  At the point, when 14 becomes unusable (introduced into OpenWRT Kernels / release we need -- or Debian), we will almost certainly discontinue batman-adv and go one with sth. else. (Due to kernel deps it's easier to run batman-adv / olsr in parallel than two different version of batman-adv)
>
>  I don't see that by releasing batman-adv with the new compat version, suddenly your network breaks
>  - in Debian you usually keep the same kernel for YEARS, and in OpenWRT you can just keep the batman-adv
>  package at the desired version number. The only problem you might run into is that newer kernels might
>  not work, as stated above.

Actually, it has consequences: About 5-8 months ago (don't remember the details). 2011.2 didn't build on Attitude Adjustment (12.09) (OpenWRT issue? Kernel Issue? I don't remember ...), while newer TP Link 1043nd models needed 12.09 (brick, otherwise). At that time we're eager of deploying compat 14 releases - succeeding about 3,5 months ago.
But in the aftermath of it, we noticed that we did not succeed in upgrading the whole network - since upgrading some nodes is still impossible because of organizational issues. Some people complained about the effort needed - for valid reasons, imho (although we provided free vodka at our release party ;-) )

To be honest: I don't like to be stuck at this, again. With compat 15 on the horizon, we're in the need of finding adequate strategies.
Do you have something in your mind?

>>  ->  Maybe, some future version of batman-adv addresses backwards-compatibility. Maybe, in 2018 we will have a look at batman-adv again - noticing, that batman-adv remained stable (or migratable) over the last years and start using it again. Maybe, batman-adv will fit our needs, then.
>
>  You are free to use whatever you want. I think I've made a clear point that this compat bump is designed
>  to address the compat issues we had. What you roll out then is up to you (personally I'd be interested
>  what you'll use instead) - but I guess you'll miss a lot of very nice features of batman-adv. ;)

Yeah - I guess I'll miss some features - and there is no decision yet (not even candidates).
However - in retrospect - kernel-dependencies will be taken into account this time.

Greetz,
yanosz





[-- Attachment #2: Nachrichtenteil als Anhang --]
[-- Type: text/plain, Size: 201 bytes --]

_______________________________________________
Freifunk.luebeck-devel mailing list
Freifunk.luebeck-devel@asta.uni-luebeck.de
http://lists.asta.uni-luebeck.de/mailman/listinfo/freifunk.luebeck-devel