Subject: [homenet] Info about IS-IS demo from Bits N Bites Prague

From: Christian Franke <[email-masked]>
Date: Thu, 17 Sep 2015 06:17:57 +0200

Hello all,

since there have been some inquiries about different aspects of the demo
that NetDEF showed at the bits N bites in Prague, I decided to provide a
more detailed description here on the list.

We showed a home network running HNCP and two different implementations
of IS-IS interoperating with each other, at the high level the demo showed:

- IS-IS for Homenet (IPv6 & IPv4)
- Transport: both L2 & IPv6 (Link-Local)
- Point-to-Multi-Point or Broadcast over L2 or IPv6
- Dynamic IS-IS Route Metric updating based on WiFi QualityInfo about
IS-IS demo from Bits N Bites Prague
- HNCP IPv6 Prefix Delegation
- SRC / DEST Routing
- IS-IS Auto-Configuration

Both code bases implemented the following extensions on top of standard
IS-IS:

- draft-franke-isis-over-ipv6
- draft-baker-ipv6-isis-dst-src-routing
- draft-lamparter-isis-p2mp
- draft-franke-isis-over-ipv6
- dynamic metric support (see below)

For more information for the first four bullet points, please refer to
the drafts.

There is currently no draft on the dynamic metric support, since this
feature does not change the IS-IS protocol. Therefore, a short
description is following.

For the dynamic metrics support, we implemented a small daemon called
etxrd which provides metric information from the 802.11 layer. The
information is gathered using OpenWRT's libiwinfo, on our platform using
nl80211. We have a patch for libiwinfo that allows us to query the
estimated tx rate from the wifi stack, this value is suitable as a
metric for routing purposes. However that patch has not been in a
release yet, so to support running our code on the current standard
OpenWRT system, we rely on SNR as a metric for now. This provides some
information, but is suboptimal.

The daemon currently only provides metrics for the wifi side. We use a
fixed (better) metric for wired connections.

Just to clarify, that daemon is not specific to IS-IS, and it does not
need IS-IS to run. It just provides metric information about known
802.11 neighbors that can be consumed by any interested party, e.g.
other routing protocols, without requiring any modification on the
daemon side.

In our use case, IS-IS subscribes to the provided information and uses
it to adjust metrics for the neighbors. These are standard IS-IS wide
metrics, although it makes use of the per neighbor metrics available
with draft-lamparter-isis-p2mp.

Since 802.11 clients/stations only communicate with other stations via
the access point, they do only have metric information about the access
point, while the access point has information about all clients. To
address this, links without metric information (i.e. direct links
between clients) will not be considered for SPF. Since 802.11 frames
from clients to clients are relayed by the AP, this actually can reflect
the metrics better.

---

The code that was use for the demo is available at the NetDEF git. There
is a package feed for OpenWRT that allows to build images containing our
IS-IS version available here:

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

Instructions for using that feed can be found in the README file.

-Christian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 17 Sep 2015 21:57:12 +0200 (CEST)

Hi,

I just want to change the subject of this so that people who are 
interested in this topic doesn't miss it.

On Thu, 17 Sep 2015, Christian Franke wrote:

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 18 Sep 2015 19:18:50 +0200

> - Dynamic IS-IS Route Metric updating based on WiFi QualityInfo

This is interesting.  Could you please share your experimental data?

Getting dynamic metrics right in link-state is tricky, and using them in
a reliably flooded link-state routing protocol has never been done before
to my knowledge.  I have no doubt that you and David are highly competent
engineers, but since this is something that has never been done before,
I think it is essential that you share your experimental data.

I refer you to [1] that compares an early version of babeld with an early
version of OLSR-ETX.  Henning is a highly competent engineer, at it took
him years of hard work to get ETX right in OLSR.

[1] David Murray, Michael Dixon and Terry Koziniec.  An Experimental
    Comparison of Routing Protocols in Multi Hop Ad Hoc Networks.
    In Proc. ATNAC 2010.  2010.
    http://researchrepository.murdoch.edu.au/3982/1/Comparison_of_Routing_Protocols.pdf

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 18 Sep 2015 19:23:24 +0200

> - Transport: both L2 & IPv6 (Link-Local)

Which is suggested for Homenet?  The two don't interoperate, right?

> - Point-to-Multi-Point or Broadcast over L2 or IPv6

Which is suggested for Homenet?  Or do the two interoperate?

> These are standard IS-IS wide metrics, although it makes use of the per
> neighbor metrics available with draft-lamparter-isis-p2mp.

Does this interoperate with standard IS-IS?

> To address this, links without metric information (i.e. direct links

Are you assuming that there are no dumb layer 2 APs in the network?

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Sun, 20 Sep 2015 14:57:34 +0200

> him years of hard work to get ETX right in OLSR.

I would also be interested in this...

a few years ago I wrote a variant of OLSR (v1) with a semi-reliable
transport (some linklocal retransmission scheme) but stopped working
on the thing because ETX routing metric I had contained too much
change/noise anyways.

Reliability is not that useful if the metric has changed in a relevant
way between two iterations of the update.

Henning Rogge

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 24 Sep 2015 08:10:26 +0200 (CEST)

> Which is suggested for Homenet?  The two don't interoperate, right?

Well, there is nothing that stops a device to form P2P neighbors over both 
ways, but since the feedback historically has been that L2 is hard in some 
devices (the protocol stack implementation is pretty much geared towards 
IPv4/IPv6), I'd suggest IPv6 LL for homenet.

> Which is suggested for Homenet?  Or do the two interoperate?

Historically you configure an interface as either LAN (default for 
ethernet) or P2P (default for point to point interfaces). My suggestion 
would be to use P2MP everywhere for simplicity, but I would really prefer 
to use LAN for wired ports, but since LAN ports can be bridged over all 
kinds of physical media, I guess P2MP is the safest way to go for 
everything to make sure we're not using multicast apart for discovery.

> Does this interoperate with standard IS-IS?

No, the draft explicitly states that P2MP is a new hello type and that 
P2MP routers must discard LAN and P2P Hello PDUs.

> Are you assuming that there are no dumb layer 2 APs in the network?

Yes, that is a tradeoff. If there are L2 APs then insight into the wifi 
layer is lost.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 29 Sep 2015 19:36:30 +0200

> Yes, that is a tradeoff.

Could the chairs please clarify whether restricting ourselves to
a particular class of topologies is acceptable for Homenet?

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 29 Sep 2015 19:38:05 +0200

> I would also be interested in this...

I haven't seen a reply to that.  Are you doing experimental testing, or
are you implementing random features so you can tick a box in your marketing
litterature?

-- Juliusz

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 30 Sep 2015 10:26:23 +0200 (CEST)

> a particular class of topologies is acceptable for Homenet?

Well, it would be informative if we actually finally had the discussion on 
what kind of Homenet we're actually aiming for. We still have no concensus 
on that as far as I can tell.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 30 Sep 2015 10:28:10 +0200 (CEST)

> are you implementing random features so you can tick a box in your marketing

Could you please link to experimental testing you have done so we can 
understand what kind of testing you're expecting to happen, and what data 
to come out of it?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 30 Sep 2015 11:17:35 +0200

>> I haven't seen a reply to that.  Are you doing experimental testing

> Could you please link to experimental testing you have done

I already have, repeatedly.

Please check the Babel web page, which links to a number of papers and
draft papers that contain both experimental and simulation data.

Please check the results of previous Battlemeshes.

Please check Babelweb, which gives a real-time map of the small permanent
testbed against which we test every single change we make to the Babel
implementation.

I estimate that we spend about three times more time testing than
implementing new features.

-- Juliusz

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 30 Sep 2015 12:20:19 +0200 (CEST)

> draft papers that contain both experimental and simulation data.

Are you referring to 
http://www.pps.univ-paris-diderot.fr/~jch/software/babel/ ? I find 4 
papers, two have broken links, one is for ad hoc networks, and another one 
is multi-hop mesh protocols.

It's not obvious to me that homenet is an ad-hoc mesh network, at least 
according to the wikipedia page. I don't expect all nodes that participate 
to relay messages.

> Please check the results of previous Battlemeshes.

I found http://battlemesh.org/BattleMeshV7/Tests but I can't find any 
results, only test cases, and all of the test cases are mesh networking 
cases.

> testbed against which we test every single change we make to the Babel

The babelweb page I can find doesn't include any english text. 
(http://www.babel-web.eu/)

> implementing new features.

That's all nice and fine, but I still haven't been able to find the 
results you said would be there. So please LINK (not drop google search 
terms) to the data that you think is relevant for homenet.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 30 Sep 2015 12:27:36 +0200

On Wed, Sep 30, 2015 at 12:20 PM, Mikael Abrahamsson <[email-masked]> wrote:
> http://www.pps.univ-paris-diderot.fr/~jch/software/babel/ ? I find 4 papers,
> two have broken links, one is for ad hoc networks, and another one is
> multi-hop mesh protocols.
>

I would say that everything that works on an ad-hoc mesh network will
also work as good on a wired network... maybe a bit better because of
the "missing frame loss".

> results, only test cases, and all of the test cases are mesh networking

These are the tests and results from the battlemesh v8:
http://docs.battlemesh.org/v8/

Henning Rogge

---

From: Gabriel Kerneis <[email-masked]>
Date: Wed, 30 Sep 2015 12:37:30 +0200

On Wed, Sep 30, 2015 at 12:20 PM, Mikael Abrahamsson <[email-masked]>
wrote:

> The babelweb page I can find doesn't include any english text. (
> http://www.babel-web.eu/)

Now, you are not trying very hard: from
http://www.pps.univ-paris-diderot.fr/~jch/software/babel/ that you
mentioned above in your message, you have a direct link to Babelweb,
including the live demo.

http://babelweb.wifi.pps.univ-paris-diderot.fr:8080/

Gabriel

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 30 Sep 2015 12:38:30 +0200

> Are you referring to
n> http://www.pps.univ-paris-diderot.fr/~jch/software/babel/ ? I find
> 4 papers, two have broken links, one is for ad hoc networks, and another
> one is multi-hop mesh protocols.

Yes, all of them are in mesh networks.  Since IS-IS doesn't do meshes,
you'll need to design a different set of tests.

I'll fix the broken links when I have some time, thanks for the notice.
I see that I also need to add links to Roger Baig Viñas's work.

> It's not obvious to me that homenet is an ad-hoc mesh network,

We've been through that already, haven't we?  Homenet uses the classical
prefix model, which is easier on the routing protocol (it's more
restrictive).  We've been doing all of our testing in the more hostile
mesh environment, so you'll need to design a different set of tests for
IS-IS.

> results, only test cases, and all of the test cases are mesh networking

http://docs.battlemesh.org/v8/1-the-mesh-of-death-adversity.html#results

> So please LINK (not drop google search terms)

Mikael -- term has started, I'm teaching every single day except Wednesdays
and week-ends.  You'll certainly forgive me if I tell you that I have
neither the time nor the energy to do everything.

-- Juliusz (busy writing first year practicals about for loops, which is
            much more fun than having just conditionals)

---

From: Gabriel Kerneis <[email-masked]>
Date: Wed, 30 Sep 2015 12:42:59 +0200

> is multi-hop mesh protocols.

And here are some correct links, courtesy of Google Scholar:

   -
   http://www.researchgate.net/profile/Juan_Ruiz27/publication/220626977_Towards_benchmarking_routing_protocols_in_wireless_mesh_networks/links/0deec534523f546c3e000000.pdf
   - http://www.computer.org/csdl/proceedings/dsn/2012/1624/00/006.pdf

Gabriel

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 30 Sep 2015 13:05:23 +0200 (CEST)

> mesh environment, so you'll need to design a different set of tests for 

Since the homenet I envision would have AP(s) and then perhaps some other 
routers who would be in client mode towards this AP, a valid test of the 
metric setting features would be to have two wifi networks, one 2.4GHz, 
one 5Ghz, two different L2s, different IP networks, and then walk around 
with two clients connected together with a network cable, and check if the 
routing would change from the 5GHz network to the 2.4GHz network as 
distance from the AP increases and the 5GHz network stops working.

So since we have different opinions on what a homenet looks like, does 
anyone believe that this test is worthless, or does it at least give some 
valuable data?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 30 Sep 2015 13:13:37 +0200

> a valid test of the metric setting features would be to have two wifi
> networks, one 2.4GHz, one 5Ghz, two different L2s, different IP
> networks, and then walk around with two clients connected together with
> a network cable, and check if the routing would change from the 5GHz
> network to the 2.4GHz network as distance from the AP increases and the
> 5GHz network stops working.

That would be an interesting test if you can show that Christian's code
works better in this case than plain IS-IS and not much worse than
a recent babeld.  Both in an unloaded network and under load (10Mbit/s
constant-rate UDP is what I like to test against, but some people think
that TCP is more realistic).

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Wed, 30 Sep 2015 13:18:02 +0200

> that TCP is more realistic).

The Wifi stress testing script Dave Taht brought to the Battlemesh V8
might also be interesting for this... 10 Mbit/s UDP traffic will be
really tame on a modern wifi. Even multihop 100 Mbit/s could not dent
or test mesh on the Battlemesh V8.

http://docs.battlemesh.org/v8/3-blowing-up-the-network.html#test

Henning Rogge

---

From: Gabriel Kerneis <[email-masked]>
Date: Wed, 30 Sep 2015 13:20:52 +0200

On Wed, Sep 30, 2015 at 1:13 PM, Juliusz Chroboczek <
[email-masked]> wrote:

> a recent babeld.

That would be an interesting test regardless of the outcome. Please, do
share negative results too:
https://www.elsevier.com/authors-update/story/innovation-in-publishing/why-science-needs-to-publish-negative-results

Gabriel

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 30 Sep 2015 13:26:04 +0200

> https://www.elsevier.com/authors-update/story/innovation-in-publishing/why-science-needs-to-publish-negative-results

Yes, I expressed myself badly.  What I meant is that the test is certainly
interesting, assuming that you do compare against both classical IS-IS and
a well-established protocol with variable metrics, such as Babel or
Henning's variant of OLSRv2.

-- Juliusz