[v6ops] Multicast problem in IPv6 address management

[Vasilenko Eduard <[e-mail]>]

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:[e-mail]] On Behalf Of Pascal Thubert (pthubert)
Sent: 12 августа 2020 г. 1:03
To: Ted Lemon <[e-mail]>
Cc: [e-mail]; IPv6 List <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> a écrit :
 On Aug 11, 2020, at 4:47 PM, Fred Baker <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------