Re: [homenet] ISIS wifi testing

[Mikael Abrahamsson <[e-mail]>]

On Fri, 16 Oct 2015, Michael Richardson wrote:

> You might want to create a network like:
>
>          +----W1-----+R1+++++R4---W3---R6
> C1 +----+R3            +      +         +
>          +            +      +         +
>          +----W0-----+R2+++++R5---W2---R++C2

I ended up doing this instead (I didn't have enough routers to do what you 
suggested above, and I thought the below test case would better test a 
real-world scenario with multuple APs and devices fading or moving between 
them).

                                  C2
                                  |
          +---------W0-------+R1==R2+--W2-+
C1 =====R3                               |
          |                               |
          |                               +
          =============R4+-----W1--------+R5

So the R1/R2/C2 combination can be rolled around so that the best 
wifi is either R3 or R5. I am running an iperf3 TCP session between C1 and 
C2.

I tried both with a cable between R4 and R5 (shortcut) and only with the 
above wifi. I tested both with and without cable, and both with Babel and 
Quagga ISIS. Below are my findings. I have several hours of video, but the 
last test I am basing my below findings on is a 47 minute video. I'm 
uploading it to Youtube now. https://youtu.be/VXE5_cOcTvw (it's still 
processing if you check it right now). I kept a window open to the right 
where I wrote what I did, as I did it.

I'd say both protocols/implementations are doing a decent job. Babel, not 
knowing anything about the actual radio parameters, tends to stick around 
on a going-bad wifi, until it's really bad and basically stops working, 
then it switches around. Both protocols really prefers single wifi hop 
instead of 2 wifi hops, even if the 2 wifi hops are a lot better than the 
single wifi hop. Babel tends to switch fairly slowly, taking a 
conservative approach to path selection (which is to be expected 
considering the design criteria as I understand them).

With just single wifi hops (cabled connection R4-R5), ISIS is able to 
re-route from one wifi to the next a bit earlier than Babel, as the one 
it's on is going really bad.

In order to actually optimize wifi, I'd say both protocols need to know 
more about the speed the wifi is averaging at, and SNR would also be of 
interest (currently IS-IS only uses SNR). None of them are doing a great 
job, but to do a great job, I'd imagine the solution would be a lot more 
complicated. Description of the metric daemon for IS-IS is here:

https://git.netdef.org/projects/OSR/repos/openwrt-isis-hnet/browse/etxrd

I still do not know what topologies we're expecting to see. Both protocols 
are today behaving decently when it comes to wifi connections coming and 
going, getting worse, getting better, at least trying to avoid the really 
bad wifi connections. Babel tends to be "stickier". Both suffer from 3-10 
seconds outages when some things happen, this might even be related to 
hnetd changing things around, I don't know for sure. It's very frustrating 
that by default there are no loopback addresses for the routers that are 
the addresses used for DNS entries. Also, in current implementation there 
is no stickyness for addresses on interfaces, if it goes down, it'll come 
back up again with new prefix.

I haven't seen anything that indicates prolonged microloops for IS-IS 
during my testing. I've kept ping sessions (one per second) going and 
always just seen the expected TTL on replies.

For now I have only tested IS-IS with "ipv6 and P2MP" setup. I'm going to 
test in broadcast mode now and see if there are some obvious differences, 
I don't believe there will be since my radio environment is not extremely 
crowded and they're mostly used for point-to-point link.

-- 
Mikael Abrahamsson    email: [e-mail]