Re: [Babel-users] some thoughts towards babel-1.9

[Juliusz Chroboczek]

> Well, the rabel repo exists for the crazy ideas... and unfortunately
> testing them at scale tends towards being a PITA.

Exactly my point.  Ideas are cheap.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] some thoughts towards babel-1.9

[Juliusz Chroboczek]

> If that is the only error in two highly speculative documents then I'm
> winning. :)

You'll be helpful (I prefer this to "winning") when you implement some of
your ideas and provide us with hard data to show that they are useful.

(For the record, CS6 and unicast IHU have both been implemented, and
I still haven't seen any hard data that shows that they improve the
behaviour of the network.)

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] some thoughts towards babel-1.9

[Dave Taht]

On Mon, Jan 2, 2017 at 3:35 PM, Juliusz Chroboczek  wrote:
>> For the wired link case, I am surprised babel considers it "interfering"!
>
> It doesn't.
>
>   https://github.com/jech/babeld/blob/master/interface.c#L210

If that is the only error in two highly speculative documents then I'm
winning. :)

It is probable that I wrote that down while dealing with something in
bridge mode,
and before I'd realized that we had to set the channel manually.

> ___
> Babel-users mailing list
> Babel-users@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] some thoughts towards babel-1.9

[Dave Taht]

On Mon, Jan 2, 2017 at 6:28 AM, Benjamin Henrion  wrote:
> On Mon, Dec 12, 2016 at 6:25 PM, Dave Taht  wrote:
>> I've long been testing a few out of tree patches for babel and long
>> have had the intent to try a few more once the first phase of the
>> make-wifi-fast work was completed - which it mostly is, so far as lede
>> is concerned ( https://lwn.net/Articles/705884/ ) - and babel-1.8
>> stablized.
>>
>> I wrote up some of my thinking then in:
>>
>> https://github.com/dtaht/rabeld/blob/master/rabel.md
>
> You are right about the 2 remarks on diversity, the code needs to be
> adapted to handle 802.11AC, and how it minimize channel interference,
> especially nowadays with using multiple channels at once.

Merely handling channel detection at all again would be good. Code for
this, using the correct API, exists in olsrv2, but my brain crashes
when looking at netlink. Then there's merely HT20 vs HT40... and THEN
ac really wonks up the ideas.

> For the wired link case, I am surprised babel considers it "interfering"!

I can't remember how I drew this conclusion, whether it was from
packet captures or from the code, but it appeared to be the case at
the time.

> On this topic, I wanted to BAN hoping on the same channel, as this is
> a really bad feature of wifi mesh.

Not sure if I understand. There are plenty of cases where using the
same channel again makes sense, for example where a directional 5ghz
radio has a ton more bandwidth than a weaker 2.4ghz omni to a given
point.

One test case we did not explore yet with the make-wifi-fast code was
where there is a 5 ghz channel in AP mode with an adhoc backchannel on
the same radio. My hope is we vastly improved the behavior in that
scenario... but to deploy it we needed

> At some point, I should find some time to install a proper outdoor
> testbed somewhere to try that kind of configuration.

The yurtlab (and 110 acre campus) is uninhabitably cold in the winter
(at least to a californian - no snow, though). I'd hoped to do a new
deployment (30+ radios) by this past september, but we weren't done
make-wifi-fast yet. With the time available before spring (say, may),
it seems possible to work on other bothersome problems (ipv6 address
assignment, source specific routing, name services, monitoring, and
security, and other rabel-ish issues)

(If anyone out here wants to bundle up and climb a few roofs with me,
getting a partial deployment along the 2 main backbones would be nice,
long before then)

> I have tried to simulate that with hwmod kernel module, but did not go very 
> far.
>
> --
> Benjamin Henrion 
> FFII Brussels - +32-484-566109 - +32-2-3500762
> "In July 2005, after several failed attempts to legalise software
> patents in Europe, the patent establishment changed its strategy.
> Instead of explicitly seeking to sanction the patentability of
> software, they are now seeking to create a central European patent
> court, which would establish and enforce patentability rules in their
> favor, without any possibility of correction by competing courts or
> democratically elected legislators."



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] some thoughts towards babel-1.9

[Benjamin Henrion]

On Mon, Dec 12, 2016 at 6:25 PM, Dave Taht  wrote:
> I've long been testing a few out of tree patches for babel and long
> have had the intent to try a few more once the first phase of the
> make-wifi-fast work was completed - which it mostly is, so far as lede
> is concerned ( https://lwn.net/Articles/705884/ ) - and babel-1.8
> stablized.
>
> I wrote up some of my thinking then in:
>
> https://github.com/dtaht/rabeld/blob/master/rabel.md

You are right about the 2 remarks on diversity, the code needs to be
adapted to handle 802.11AC, and how it minimize channel interference,
especially nowadays with using multiple channels at once.

For the wired link case, I am surprised babel considers it "interfering"!

On this topic, I wanted to BAN hoping on the same channel, as this is
a really bad feature of wifi mesh.

At some point, I should find some time to install a proper outdoor
testbed somewhere to try that kind of configuration.

I have tried to simulate that with hwmod kernel module, but did not go very far.

--
Benjamin Henrion 
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] some thoughts towards babel-1.9

[David Schinazi]

Dave,

Thanks for writing this up, it's an interesting read.
I agree with you on the topic of multicast. My implementation sends
everything unicast, with the exception of Hellos. I'm interested in
working on a way to allow unicast Hellos. I read your thoughts here:
https://github.com/dtaht/rabeld/blob/master/babel_unicast_hello.md 


and was thinking that we might be able to make this even simpler,
by adding a new "I support unicast Hellos" bit in the IHU Reserved field.
That way when a node appears on a link, they send a multicast Hello,
and get IHUs in response. If all the IHUs have this bit, then the router
can go into unicast Hello mode. Similarly, when a node sees a new
neighbor, it sends it an IHU with this bit and if it receives a unicast
Hello from that node it knows they are supported, otherwise falls back
to multicast. You could then have different intervals for multicast and
unicast Hellos, with the multicast one being potentially much higher.

This proposal stays in the spirit of current Hellos as a measure for
packet loss rate. If as you describe this isn't a great metric, we
could take this thought process even further and simply get rid of
Hellos for link quality estimation. You would still have multicast Hellos
to detect new peers, but you can estimate by-directional reachability
simply by noticing of you receive any Babel packet from a host, and
IHU for the reverse direction. This makes particular sense if you were
able to query your link-layer for information on how many
retransmissions are required on average to reach that host, and what
rate the Wi-Fi chip is operating at.

Thoughts?
David


> On Dec 12, 2016, at 09:25, Dave Taht  wrote:
> 
> I've long been testing a few out of tree patches for babel and long
> have had the intent to try a few more once the first phase of the
> make-wifi-fast work was completed - which it mostly is, so far as lede
> is concerned ( https://lwn.net/Articles/705884/ ) - and babel-1.8
> stablized.
> 
> I wrote up some of my thinking then in:
> 
> https://github.com/dtaht/rabeld/blob/master/rabel.md
> 
> back when we were having powersave issues affecting multicast (which I
> hope is now fixed), but I've partially deployed the "mo' unicast"
> patch around my testbed with no ill results.
> 
> Another thing that has come up a lot lately is the default gateway
> failing for some reason or another, tighter integration with
> babel-pinger might help.
> 
> And lastly, I had a chance to look at some packet captures from the
> wlan-slovenia network, which is essentially flat, and is sending 14
> packets worth of route information on a regular basis. Finding ways to
> attenuate and create covering routes, and make DV more DV would be
> nice.
> 
> I'd also written up some partially crazy thoughts towards a unicast
> hello extension in the same repo.
> 
> -- 
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org
> 
> ___
> Babel-users mailing list
> Babel-users@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users