Re: [homenet] ISIS wifi testing

Mikael Abrahamsson <swmike@swm.pp.se> Fri, 23 October 2015 12:38 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5541B35B5 for <homenet@ietfa.amsl.com>; Fri, 23 Oct 2015 05:38:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.961
X-Spam-Level:
X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2x1EVWvmbBYs for <homenet@ietfa.amsl.com>; Fri, 23 Oct 2015 05:38:43 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD3811B303B for <homenet@ietf.org>; Fri, 23 Oct 2015 05:38:42 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 70C50A2; Fri, 23 Oct 2015 14:38:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1445603920; bh=WmZJGFgwCf7SuxijEMkaiBpdeiHNa2rZs+sN8lWXWGE=; h=Date:From:To:Subject:In-Reply-To:References:From; b=lb6QQGZhhrkSOR+7xtcdJ06BRC7vweW+Jda1f5Gzm/o1zyfrhPg7n71eLjFE3QjQ7 CQaug2AMH4+OIzqYUNQzuCUXew8QyEgQudmfyPNm853ouJe/W06KH5Y7/XB+TbdzjT xQny4FCiJwPIb+G3IicXiywrcxxO6zjV76lyFzn8=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 60E23A1 for <homenet@ietf.org>; Fri, 23 Oct 2015 14:38:40 +0200 (CEST)
Date: Fri, 23 Oct 2015 14:38:40 +0200 (CEST)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: homenet@ietf.org
In-Reply-To: <27777.1445024142@sandelman.ca>
Message-ID: <alpine.DEB.2.02.1510231149150.16053@uplift.swm.pp.se>
References: <alpine.DEB.2.02.1510161434010.16053@uplift.swm.pp.se> <27777.1445024142@sandelman.ca>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/WaUvCyzl5h3cG05LIx_gLN3zaCc>
Subject: Re: [homenet] ISIS wifi testing
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Oct 2015 12:38:45 -0000

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: swmike@swm.pp.se