Subject: [homenet] rtg-comparison multicast section

From: David Lamparter <[email-masked]>
Date: Mon, 23 Mar 2015 01:56:01 +0100

Hi Margaret, Chris & Juliusz,
Hi homenet list,

while I haven't completely caught up with discussion on the homenet list
--the routing protocol thread is truly (th|d)readful-- I seem unable to
find significant feedback on the multicast part (sec. 11) of the
comparison draft.  (I apologise & appreciate pointers if I missed it.)

The draft currently assumes IS-IS or Babel would/could be the multicast
routing protocol.  That assumption, IMHO, is wrong.  Long story short,
MOSPF was the archetype for trying to bolt multicast routing onto a
unicast routing protocol, and the best description I've heard of it is
"trainwreck."  The most established protocol for multicast routing would
be some variant of PIM, or for the hipsters you can try BIER.

However, this doesn't mean that multicast is irrelevant in the routing
protocol comparison.  The draft just needs to ask a different question:
does the unicast routing protocol provide the neccessary information for
the multicast routing protocol to perform its job?

What I have in the back of my mind here is a separate MRIB.  For the
non-multicast-savvy on this list, the MRIB is a separate routing table
containing routes to unicast prefixes, used to perform RPF lookups to
locate paths towards multicast sources/senders.

At a large fully multicast-enabled ISP, the MRIB would be an identical
copy of the unicast table/URIB.  But the point is that it's calculated
separately, so that different metrics can be used or links can be
excluded.  I strongly believe this is useful in the homenet, namely to
deprioritise wifi links - or other future media that sucks at multicast.

The concept at work here is that metric/cost for a link isn't the same
for unicast or multicast.  802.11ac with a wide channel and enough
antennas provides great unicast performance - better than a 100MBit
Ethernet link.  Yet, I would never use that wifi link for any kind of
multicast distribution.  This means I want a low unicast metric on the
wifi link, but a (very) high multicast metric.

Hence, with IS-IS, I would put into use a separate multicast routing
topology (topology ID #4 is reserved for this.)  Routers would use the
knowledge of their interfaces and link status to come up with a pair of
unicast and multicast metrics, instead of just one metric.

Babel does not - correct me if I'm wrong - have the capability to work
with more than one topology.

(Also note that a MRIB will never contain source-destination routes.
SADR is simply not supported for multicast RPF lookups;  there is only
the sender address and the multicast group address.)

(I'm blissfully ignorant about BIER for now, yet google tells me there
is some IS-IS integration for it.)

Cheers,

-David

P.S.: I've seen 802.11 multicast rate being mentioned as 1-2MBit/s in some
e-mails.  There is some misconception involved there.  1-2 MBit/s is what
you get on current Linux 802.11 AP/IBSS implementations (= home
routers).  Nothing precludes the AP from using higher rates, but this
requires code that Linux doesn't currently have.

Getting to full-rate multicast requires snooping for group memberships,
determining the lowest rate used by any of the receivers, and optionally
calculating whether it might be better to send unicast.  "Enterprise"
wifi implementations have these features to varying extent in the
controller.  (2 big vendors have quite extensive features there, 1 big
vendor has almost nothing at all - guess it depends on whether some big
customer asked for it at some point.)

P.P.S.: That also means that a better AP implementation would have less
of a difference between the unicast metric and the multicast metric for
wifi links.  I'd say they should still be different.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 23 Mar 2015 03:17:54 +0100

Hi David,

> routing protocol.

This is what I wrote in Section 11.3:

   Some experts believe that it may be better to run a dedicated
   multicast routing protocol rather than extensions to a unicast
   routing protocol.

Sorry for the tone of the above, but since the IS-IS supporters are so
keen on pointing out IS-IS's support for multicast, I didn't want to make
it any more explicit.

> Long story short, MOSPF was the archetype for trying to bolt multicast
> routing onto a unicast routing protocol, and the best description I've
> heard of it is "trainwreck."

I'm really glad to hear that.

> the multicast routing protocol to perform its job?

Good point.

There are people working on using Babel with PIM, which is why the current
babeld trunk has an option "reflect-kernel-metric" which is used for
feeding the Babel metric back to the PIM daemon.  I haven't been tracking
this work closely, and I have no idea how well it is going.

> But the point is that it's calculated separately, so that different
> metrics can be used or links can be excluded.  I strongly believe this
> is useful in the homenet, namely to deprioritise wifi links - or other
> future media that sucks at multicast.

I don't know.  Babel automatically assigns high metrics to wireless links,
and in reasonable topologies it will already do the right thing for
multicast.  (Granted, you can work out a topology where that is not the
case -- but you need three wired hops that run parallel to a single,
lossless wireless hop, which I don't think is realistic.)

> with more than one topology.

Babel does have the ability to work with multiple metrics.  All Babel
announcements carry the default Babel metric, which is a 16-bit integer,
and which is used by routers that don't understand the non-default
metrics.  A Babel router may optionally include a non-default metric in
a sub-TLV.  The radio diversity extension uses this ability to carry
detailed information used for predicting interference.

[1] https://tools.ietf.org/html/draft-chroboczek-babel-diversity-routing-00

No matter which metric they use for route selection, all routers use the
default metric for loop-avoidance.  This means that Babel remains
loop-free even in a heterogeneous network containing routers using the
default and non-default metrics.

This is not full multi-topology support, and the limitation is that the
non-default topology, taken as an unlabelled graph, must be a subset of
the default topology: in other words, you cannot assign a finite
non-default metric to a link that has an infinite default metric.  Of
course, the default metric can be arbitrarily large -- just not infinite.

To be fair, no multicast metric sub-TLV is currently defined for Babel,
and I will not do any work on defining one unless somebody shows me hard
experimental data that proves that there exist realistic topologies where
such an extension would be worth the hassle.  Since the currently
available implementations of IS-IS have extremely primitive metric
support, even in the unicast case (Section 7 of the comparison document),
I don't think an honest person could possibly claim this is a disadvantage
of Babel.

-- Juliusz

---

From: David Lamparter <[email-masked]>
Date: Mon, 23 Mar 2015 03:54:35 +0100

> keen on pointing out IS-IS's support for multicast, I didn't want to make

I fully agree as far as anything that looks even remotely like MOSPF is
concerned.  Caveat:  I have no opinion on anything related to BIER or
other recent approaches to handling multicast.  They're different
beasts.

[quote shortened]
> I don't think an honest person could possibly claim this is a disadvantage

I stand corrected - that does indeed sound like there is rough parity
between Babel and IS-IS on the ability to transport separate metrics, in
case the WG comes to the opinion that this is useful.

For the comparison document, this thread is what I would expect to see
for section 11, looking at "backing" for multicast routing instead of
multicast routing itself.
*If* there really is an argument for IS-IS as multicast routing
protocol, it really needs to be more informative (and reference an
actual implementation, I guess) than 11.1 in the -02 comparison draft.

Cheers,

-David

---

From: "Christian Hopps" <[email-masked]>
Date: Wed, 25 Mar 2015 07:15:01 -0500

> multicast routing itself.

I agree with this. The document should be talking about IS-IS supporting 
a multicast topology, and not using IS-IS as a multicast routing 
protocol.

Thanks,
Chris.