Subject: [Roll] Roll: multicast use-case

From: Toerless Eckert <[email-masked]>
Date: Wed, 20 Jul 2016 14:08:32 -0700

Interesting drafts about  multicast in Roll. After the WG meeting, Carsten
explained a bit more the use-case:

Eg: existing building, can only effectively install networking via inexpensive
802.15.4 radio network. Need multicast because eg: lighting controller near RPL root
wants to tell eg: 50 lights to change state. 50 unicast across 256 kbps link stats ==
visible delay issue.

So, then comes in the discussion of bitstring based multicast, explicit (BIER)
or "heuristic" (bloom filter). Nice. But IMHO no cigar:

What i didn't realise is that the idea was to still to use normal
"IP multicast (SSM possibly)" and the bitstring methods just underneath it,
adopting how BIER is currently scoped in the BIER-WG.

Now maybe i am overlooking some easier app design options, but here is
how i see it:

  - I have 256 lights
  - I want to switch on/off eg: some 30 of them
  - To do this efficiently i need to first do a lot of signaling to
    tell those 30 lights: Pls. join this multicast group .. so that
    later on i can efficiently send you a command to turn on/off.
  - So ultimately i'd need to upfront assign a multicast group to every
    desired subset of lights, signal to every light the subset groups it is
    a member off, have to maintain on every last-hop forwarder the MLD
    member state for all these groups, and yeah, now i can start sending
    efficient multicast packets to the desired subsets.
  - And i can forget more interesting lighting effects because i'll never be able to have 
    even a reasonable percentage of subset groups of all lights i could address.
  - So then i want these effects, and i start broadcasting packets to
    just every light, and the app-level of those packets will have a bitstring
    of which lights should act upon the packet. And we just created a whole
    useless level of complexity that had to be ignored because of IP
    multicast scale limits and repeated inside in the app layer.

This is just silly.

What IMHO we really need is to throw out IP multicast and just use end-to-end
BIER: Sender sends BIER packet, every bit is a possible receiver. 

Apps don't like BITs ? NP, we come up with a simple control plane to replace eg: MLD
that auto-assigns bits to every receiver and the sender just needs to send
each packet to a list of receiver IP-addresses. Senders BIER library converts
that list into bitstring.

Oh, you still have some IP multicast apps ? Especially if those
are meant for controllers (SSM), you can easily build a shim library on top
of the BIER APIs to map them back to the BIER APIs.

IMHO: In this app environment, putting BIER underneath IP multicast is
like putting an electric battery&motor into a Ford model T.  And then putting a
dynamo at the wheels to generate electricity to charge the drivers iPhone. 

Maye this is more a discussion for 6tsch ? Not sure how these solution cakes get
split up across the various WGs.

Cheers
    Toerless

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 21 Jul 2016 04:37:53 +0000

Thanks Toerless 

In fact we have all the IPR for RPL BIER just missing time to write the draft. Basically assign (the group and) bit offset at the same time as the short address and expose the bit string in DAO as opposed to IPv6 addresses. Parents OR the bit strings from children in their own DAOs recursively.

Bloom adds elasticity but does not change the concept. I have to go to the patents but that's probably in there too since we were very aware of that modem.

As of ROLL: We already have a draft for the dataplane missing the one for Control plane. Matter of finding time. At least we have a charter item : )

Regards,

Pascal

> Le 20 juil. 2016 à 23:08, Toerless Eckert (eckert) <[email-masked]> a écrit :
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 21 Jul 2016 04:40:26 +0000

For clarity in the mail below the group is the index to the bitstring when there are too many device for a single one... Not a mcast group!

Regards,

Pascal

> Le 21 juil. 2016 à 06:38, Pascal Thubert (pthubert) <[email-masked]> a écrit :
> 
> Thanks Toerless 
>

---

From: peter van der Stok <[email-masked]>
Date: Tue, 26 Jul 2016 08:25:45 +0200

Hi Toerless,

>     efficient multicast packets to the desired subsets.

Up till here, I do follow
But below, I am lost. There are lots of techniques and PHY/MACs to 
handle these complexities

> BIER: Sender sends BIER packet, every bit is a possible receiver.

I do agree with your conclusion.
The same is true for MPL.
The source sends to a multicast address; the wanted receiver interfaces 
are enabled for it.
which is end-to-end MPL.

We need to compare the feasibility of these alternatives:
end-to-end delays
reliability
how easy/difficult to set up (commissioning)
network loading

My original interest in the Bier RPL Mcast is the destination encoding 
in the header
I thought it might be applied to reduce the source routing UNICAST 
headers used for the non-storing mode of RPL.

Peter