Add Source-Specific Multicast (SSM) Support

[kkroo]

First, thank you for adding multicast support to Direct Sockets! Having UDP + multicast on the browser roadmap after all these years is exciting and opens up the possibility to bring the Mbone back! This post explains TreeDN, a new multicast architecture for scaling live media delivery using a combination of UDP tunneling in routers + native multicast where possible to incrementally roll out services.

Direct Sockets currently supports UDP and Any-Source Multicast (ASM) via joinGroup(address) which is amazing. I hacked together and demo at IETF 124 an IWA of tunneled multicast video from menu.treedn.net over AMT unicast UDP which is pretty cool. However, native multicast playback would not possible from these sources in the API.

Source specific multicast (SSM) has become the recommended standard for modern multicast deployments since 2006, whether across ISPs or broadcasts, so it's super important to make that part of this project.

Proposed: Add optional source parameter to joinGroup() and leaveGroup().

Problem

Current System Call Implementation

Current (ASM only):

// chrome/extensions/browser/api/sockets_udp/sockets_udp_api.cc
setsockopt(sockfd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));

Needed (SSM support):

struct ip_mreq_source mreq;
mreq.imr_multiaddr.s_addr = inet_addr("232.1.2.3");    // Group
mreq.imr_sourceaddr.s_addr = inet_addr("192.0.2.1");   // Source
mreq.imr_interface.s_addr = INADDR_ANY;
setsockopt(sockfd, IPPROTO_IP, IP_ADD_SOURCE_MEMBERSHIP, &mreq, sizeof(mreq));

// IPv6: MCAST_JOIN_SOURCE_GROUP (RFC 3678)

Platform Support: Available on Linux (since 2.5.68), macOS (since 10.7), Windows (since Vista).

Background

RFC 4607 (2006) standardized SSM as the recommended approach. IANA reserved 232.0.0.0/8 exclusively for SSM.

Current deployment landscape:

• IPTV providers predominantly use SSM
• Financial data feeds use SSM
• Enterprise video conferencing uses SSM

ASM is primarily used for:

• Local discovery protocols (mDNS, SSDP) where there's no SSM alternative
• Legacy pre-2006 deployments
• Private/research networks

Benefits to SSM

1. Easy of configuration with IGMPv3 + PIM-SSM sparse mode
2. Bandwidth capacity planning + no need for randevous points (RP)
3. SLA enforcement and peering requirements

Proposed Solution

API Design

interface UDPSocket {
  // Existing ASM support (backward compatible)
  joinGroup(address: string): void;
  leaveGroup(address: string): void;
  
  // New SSM support
  joinGroup(address: string, source: string): void;
  leaveGroup(address: string, source: string): void;
}

Usage Examples

const socket = new UDPSocket({ localAddress: '0.0.0.0' });
await socket.opened;

// ASM: Backwards compatible any-source multicast
socket.joinGroup('232.1.2.3');
socket.leaveGroup('232.1.2.3');

// SSM: New source-specific multicast
socket.joinGroup('232.1.2.3', '192.0.2.1');
socket.leaveGroup('232.1.2.3', '192.0.2.1');

Alternative Considered

We could consider exposing IGMP_MSFILTER for multi-source filtering:

socket.setMulticastSourceFilter({
  group: '232.1.2.3',
  mode: 'INCLUDE',
  sources: ['192.0.2.1', '192.0.2.2']
});

Why joinGroup(group, source) is better:

• Simpler API for common single-source case (99% of use cases)
• Consistent with existing joinGroup() pattern
• Multi-source filtering can be added later if needed
• Matches socket API conventions in other languages

Proposed Implementation

We'd love to see the following enhancements and contribute where possible:

1. Add optional source parameter to joinGroup() and leaveGroup()
2. Implement IP_ADD_SOURCE_MEMBERSHIP / MCAST_JOIN_SOURCE_GROUP system calls

Questions

1. What do you think of the proposed API design?
2. Are there any concerns we should address?

---

Again, thank you for bringing multicast to the Web platform. We're excited about the possibilities this opens up!

[reillyeon]

This seems like a very reasonable feature request to me. My only feedback is that when adding optional parameters to methods it it best to put them in a dictionary. This lets us add other optional parameters in the future:

dictionary MulticastGroupOptions {
  DOMString sourceAddress;
};

[
  Exposed=(Window, DedicatedWorker),
  SecureContext,
  IsolatedContext
]
interface MulticastController {
  Promise<undefined> joinGroup(DOMString ipAddress, optional MulticastGroupOptions = {});
  Promise<undefined> leaveGroup(DOMString ipAddress, optional MulticastGroupOptions = {});
  readonly attribute FrozenArray<DOMString> joinedGroups;
};

What should the semantics be when joinGroup() is called with the same ipAddress but different sourceAddress values? Should we include the source address information in joinedGroups in some way?

[alvestrand]

Basically Any-Source Multicast with a scope larger than your local network is a high-powered DDOS vector, not something that it's safe to build services on, so I heartily recommend adding support for Single-Source Multicast.