Subject: Multicast problem in IPv6 address management

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 12 Aug 2020 10:49:22 +0000

Hi all,
This dispute is about: Should we assume that Multicast is the basic technology available on any L2? Should we rely fundamental mechanisms on Multicast?

Statista tells us that 9B mobile connections this year.
3GPP have effectively discarded Multicast (RFC 7849), because they have personal GTP tunnel for every subscriber. 3GPP have solved the problem limiting IP topology to P2P only.
Underlay is not IP between Terminal and Base Station – no chicken and egg problem (no need for IP underlay address on smartphone to start PDCP).
As a result: There is no multicast problem in Mobile.

Statista tells us that 18B WiFi connections this year (22B next year).
Multicast snooping is formally supported by majority of WiFi vendors. But Wireless have natural restrictions on multicast:

1.      Loss probability is much high (especially on overloaded) – protocols should guaranty delivery, that is partially supported by SLAAC: NS would be sent many times if NA is not received, but RA would not be retransmitted

2.      It should be transmitted with lowest effectiveness (worst bandwidth and modulation from all registered clients) – some bandwidth is wasted

3.      Handover requirement did push admins to keep broadcast domain big – it is the primary reason why you could still see huge number of announcements per second (for old installations). One AP is not so powerful to connect more than a few dozens of clients anyway, but many APs connected to the same VLAN – it is very different story. You could not just say: “keep broadcast domain small”, because would be immediate question “what is the easy way to preserve IP address on handover between APs?”.
Modern Wireless WiFi Controller could split big broadcast domain on independent AP domains and play stateful proxy – it would limit number of multicast messages per one AP band – it should resolve 2k multicasts per second problem.
Stateful proxy for Stateless protocol (SLAAC) - looks like not good architecture decision, looks like work-around, but not much choice left.
We are close to the situation that WiFi would resolve multicast problems by itself. Especially at times when WiFi is becoming faster and faster (1G->10G).
It is not mandatory to help WiFi – they would survive by themselves, they would find proper set of work-arounds.
The final point could be to move to Overlay completely and put SLAAC in P2P topology (like 3GPP) – proxy everything on AP/Controller. Degenerate case would work perfectly fine, host would not spot any difference.

There is a well-known story about 50B of IoT devices that additionally to WiFi problems would have: (1) low power, (2) sleeping mode, (3) low bandwidth,
Where multicast just not a question that make sense to discuss in principle.

One important question that was not touched here yet: is multicast a something that is needed only for internal network operation or is it important for end user services too?
Unfortunately the answer is negative.
Primary multicast application (any media: video or audio) is moving away from “broadcast mode” to “personalized user stream”, even Carriers have migrated from IPTV STB (multicast) to OTT STB (unicast).
It is not because of technology, users prefer personalized content more and more.
Multicast is becoming something that is demanded primarily by technical geeks for their toys. It is less and less a business requirement.

Eduard
From: ipv6 [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: 12 августа 2020 г. 1:03
To: Ted Lemon <[email-masked]>
Cc: [email-masked]; IPv6 List <[email-masked]>
Subject: Re: [v6ops] draft-ietf-6man-grand : saving lookups

Hello Ted

Some APs and controllers snoop the protocols and turn broadcasts to unicast day or drop them. The problem is that snooping gives us only an imperfect view of who is connected with IPv6.

I know for having written such code and tons of tricks, some of which we published either as drafts or patents.

We found the result to be non-satisfactory largely because of the limitations of snooping. So we brought RFC 8605 yo the IETF with no IPR attached.

I guess others will have to go through the same hassles ad we did and still do before they realize why we ended up with a stateful ND, not for all situations but for many modern use cases that involve a solid state in the network. Including APs. And fabrics.

I’m happy that Fred uses BGP, we do that too in eVPN. But how do you feed BGP? If the host does not speak BGP then we need a host to router interface that has similar properties but is abstract to the routing protocol.

There’s already 2 protocols, RPL and RIFT, that benefit from RFB 8505 advertisements to inject (redistribute) host addresses.
Take care,

Pascal

Le 11 août 2020 à 22:58, Ted Lemon <[email-masked]<mailto:[email-masked]>> a écrit :
 On Aug 11, 2020, at 4:47 PM, Fred Baker <[email-masked]<mailto:[email-masked]>> wrote:
On the air interface, they are either transmitting or not. In the receiving NIC, the question is whether or not they store the message; if they are not configured to receive a certain multicast group, regardless of transmission type, they receive and store the message and then forget that they have done so, re-using the buffer for the next message. If they forward the message on, it uses the bandwidth on the other side, whatever it is, with the same destination address.

The place where one might distinguish “broadcast” from “multicast” is on a data center switch, where “multicast” might mean keeping a list of relevant ports and only sending to them. They want to send a message once. If they are sending the same message several times, “to whom” is an important question.

Hm. What I do know about WiFi is that actual multicast messages are not acknowledged (because they can’t be) and are therefore sent at lower data rates, so that multicasts occupy much larger time slices per packet. A multicast is notionally only intended for a subset of all connected nodes. If the WiFi base station knows which nodes are interested in a particular multicast address, and that number is small, then it would nearly always be faster to transmit the message to each node as a unicast.

The question is, for a particular WiFi AP, can it know which of its connected WiFi nodes are interested in a particular NS, or do we have to multicast it to every node?

If this is known in the data center, then it must be known on the AP, right?

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 12 Aug 2020 13:57:36 +0000

Hi, aeronautical radios are another example of an L2 that supports a native broadcast capability,
but may not be so impacted by scale on the order of what you mentioned for WiFi and cellular.
Intelligent Transportation Systems are also looking at short-range multi-party wireless for
terrestrial vehicles, pedestrians and urban air mobility. Here, the scale may well be on the
order of 1B or more.

Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of Vasilenko Eduard
Sent: Wednesday, August 12, 2020 3:49 AM
To: Pascal Thubert (pthubert) <pthubert=[email-masked]>; Ted Lemon <[email-masked]>
Cc: [email-masked]; IPv6 List <[email-masked]>
Subject: [EXTERNAL] Multicast problem in IPv6 address management

Hi all,

Eduard
From: ipv6 [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: 12 августа 2020 г. 1:03
To: Ted Lemon <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] draft-ietf-6man-grand : saving lookups

Hello Ted

Pascal

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Aug 2020 09:22:37 -0700

See rfc3619 Sections 5 and 6.

Joe

> On Aug 12, 2020, at 3:51 AM, Vasilenko Eduard <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 12 Aug 2020 16:56:33 +0000

Hi Joe,
I am not aware about any “Intellectual Property Rights” in respect of discussed.
And I have not understood how “Ethernet Automatic Protection Switching (Version 1)” could help for Wireless.
I strongly suspect that you mistyped RFC number.
Eduard
From: Joe Touch [mailto:[email-masked]]
Sent: 12 августа 2020 г. 19:23
To: Vasilenko Eduard <[email-masked]>
Cc: Pascal Thubert (pthubert) <pthubert=[email-masked]>; Ted Lemon <[email-masked]>; [email-masked]; IPv6 List <[email-masked]>
Subject: Re: [v6ops] Multicast problem in IPv6 address management

Joe

On Aug 12, 2020, at 3:51 AM, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,
This dispute is about: Should we assume that Multicast is the basic technology available on any L2? Should we rely fundamental mechanisms on Multicast?

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Aug 2020 09:58:05 -0700

Rfc3819

Sorry for the typo

> On Aug 12, 2020, at 9:56 AM, Vasilenko Eduard <[email-masked]> wrote:
> 
> 
> Hi Joe,

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 12 Aug 2020 17:15:40 +0000

So many people said “MUST”, “SHALL”:

“Subnetworks using shared channels (e.g., radio LANs, Ethernets) are
   especially suitable for native multicasting, and their designers
   should make every effort to support it.”

What if “beam forming” gives +6dB and +30% of performance.
But multicast packet (without beam forming) could not penetrate the wall in principle (common case for 5Ghz). 100% loss guarantied.

Eduard
Sent: 12 августа 2020 г. 19:58

Rfc3819

Sorry for the typo

On Aug 12, 2020, at 9:56 AM, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:

Hi Joe,
I am not aware about any “Intellectual Property Rights” in respect of discussed.
And I have not understood how “Ethernet Automatic Protection Switching (Version 1)” could help for Wireless.
I strongly suspect that you mistyped RFC number.
Eduard
From: Joe Touch [mailto:[email-masked]]
Sent: 12 августа 2020 г. 19:23
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Cc: Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:pthubert=[email-masked]>>; Ted Lemon <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] Multicast problem in IPv6 address management

Joe

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Aug 2020 13:20:50 -0400

> But multicast packet (without beam forming) could not penetrate the wall in principle (common case for 5Ghz). 100% loss guarantied.

This is a case for turning multicast into successive unicast.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 12 Aug 2020 18:23:38 +0100

Vasilenko Eduard wrote on 12/08/2020 18:15:
> But multicast packet (without beam forming) could not penetrate the wall 
> in principle (common case for 5Ghz). 100% loss guarantied.

wifi is an IEEE protocol, so maybe they'd be better people to talk to 
about this?

Nick

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Aug 2020 10:26:09 -0700

That’s discussed in 3819. 

> On Aug 12, 2020, at 10:21 AM, Ted Lemon <[email-masked]> wrote:
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 12 Aug 2020 19:45:42 +0000

Joe,

Thank you for bringing the PILC perspective to this discussion; it is a good
reminder of the body of knowledge on links that has already been established.

Fred