Multicast to browser

1. Multicast to the Browser
Jake Holland, Akamai
draft-jholland-mboned-dorms
draft-jholland-mboned-ambi
draft-jholland-mboned-cbacc
WICG: https://discourse.wicg.io/t/proposal-multicastreceiver-api/3939

2. Goals
• Receive multicast in Javascript (W3C API)
• Port receivers to WebAssembly
• Including proprietary players & downloaders
• So web pages can play video, download files, etc. with multicast
• Safely
• Resist on-path packet injection/modification
• Malicious pages/scripts can’t blow out the network

3. Specs
WICG (W3C):
• MulticastReceiver API
IETF:
• DORMS: Discover and fetch extensible (S,G)-specific metadata
• AMBI: Authenticate packets with out-of-band manifests
• CBACC: Circuit-break streams if oversubscribed

4. Browser as Gatekeeper
var mr = new MulticastReceiver(
source=‘198.51.100.10’,
group=‘232.1.1.1’, port=5001,
dorms=‘dorms.example.com’);
mr.onmessage = function(evt) {
processPayloads(evt.data); }
mr.join()
Javascript
Browser
Fetch Metadata
(DORMS)
Safe Bitrate?
(CBACC)
dorms.example.com
(RESTCONF)
no
(error)
Subscribe
Internet
Authentication +
Loss Detection
(AMBI)
yes
Join(S,G)
data
integrity
stream
Authenticated payloads, loss stats
join()

5. Network as Gatekeeper
Javascript
Browser
DNS-SD query: SRV of
dorms._tcp.(reverse-src-ip)
=>dorms.example.com
On-path router
Fetch Metadata
(DORMS)
Safe Bitrate?
(CBACC)
no
(block)
RPF Propagate
(Optional for routers)
Authentication +
Loss Detection
(AMBI)
yes
Join(S,G)
data
Forward packets (optionally authenticated)
join()
Next Hop Router
Maybe
Downstream
Routers

6. DORMS -- Discovery Of RESTCONF Metadata for SSM
• RESTCONF: YANG-based HTTPS Restful API
• Authentication Hostname
• DNS Reverse IP -> DNS-SD provides hostname (for network)
• Known hostname provided by client (for browser API, pending wider DNSSEC/DoH)
• Bootstrap from hostname via standard RESTCONF (RFC 8040):
• /.well-known/host-meta
• /restconf/data/ietf-yang-library
• CORS
• Browser inserts origin header, server refuses unauthorized requests
• Network uses reverse IP as origin, optional client auth from server
• dorms.yang => Indexed fetch of (S,G)-specific metadata

7. DORMS
GET /top/restconf/data/
ietf-dorms:metadata/
sender=203.0.113.15/
group=232.1.1.1
Host: dorms-restconf.example.com
Accept: application/yang-data+json
HTTP/1.1 200 OK
Content-Type: application/yang-data+json
{
"ietf-dorms:group": [
{
"group-address":"232.1.1.1",
"udp-stream":[
{
"port":"5001”
}
]
}
]
}

8. DORMS + AMBI
GET /top/restconf/data/
ietf-dorms:metadata/
sender=203.0.113.15/
group=232.1.1.1
Host: dorms-restconf.example.com
Accept: application/yang-data+json
HTTP/1.1 200 OK
Content-Type: application/yang-data+json
{
"ietf-dorms:group": [
{
"group-address":"232.1.1.1",
"udp-stream":[
{
"port":"5001”,
"ietf-ambi:manifest-stream": [
"manifest-transport":[
"https://example.com/manifest1"
],
"hash-algorithm":"shake-128"
]
}
]
}
]
}

9. AMBI – Asymmetric Manifest-Based Integrity
• YANG augmentation of DORMS
• Adds yang data to the (S,G) nodes
• Out-of-band Stream of Manifests
• HTTPS Chunked Encoding (prototype at Hackathon)
• QUIC (H3 version of same)
• DTLS+FECFRAME (future work—reduce HOL blocking?)
• ALTA+FECFRAME (after DTLS–fate-sharing, better timing window, scalable)
• Manifests:
• List of sent packet digests (hash of contents)

10. AMBI (Asymmetric Manifest-Based Integrity)
Sender
Multicast Data
UDP Probably
Fanout & Forwarding
(Tunneling, PIM/BIER, IGMP/MLD)
Packet1
Packet2
Packet3
CDN/Elastic Cloud
Receivers
Packet without hash:
=> spoofed/corrupt
Hash without Packet:
=> loss
Packet1
Packet2
Packet3
Hash(Packet1)
Hash(Packet2)
Hash(Packet3)
1-3% of data:
Unicast-Authenticated Manifests
Manifests (Authenticated)
HTTPS/QUIC/DTLS
Hash(Packet1)
Hash(Packet2)
Hash(Packet3)

11. Also AMBI (phase 2, with ALTA)
Sender
Multicast Data
UDP Probably
Fanout & Forwarding
(Tunneling, PIM/BIER, IGMP/MLD)
Manifests (Signed)
UDP (another port
Signature
Hash(Packet1)
Hash(Packet2)
Hash(Packet3)
Packet1
Packet2
Packet3
CDN/Elastic Cloud
Receivers
Packet without hash:
=> spoofed/corrupt
Hash without Packet:
=> loss
Packet1
Packet2
Packet3
0% of data:
Unicast Authenticated
Public Keys (verify signatures)
Signature
Hash(Packet1)
Hash(Packet2)
Hash(Packet3)
Occasional Keys

12. CBACC – Circuit-Breaker Assisted Congestion Control
• YANG augmentation of DORMS
• Adds yang data to the (S,G) nodes
• Provides max-bitrate and priority metadata for (S,G)
• Defines circuit-breaker behavior
• Prune when oversubscribed
• Oversubscription threshold
• Static — typical for routers
• (default: X% interface capacity)
• Dynamic — typical for browser:
• Loss (shrink when there’s loss, grow when there’s not)
• History
• BW detection techniques (chirping/packet dispersion)

13. Circuit Breaker Assisted Congestion Control
Bit-rate metadata from senders
(via DORMS)
+ optional PIM population count for fair pruning decisions
(RFC 6807, experimental)
Notice oversubscribed
links, prune or block
flows.
draft-jholland-mboned-cbacc:

14. Implementation status
• Receive API (just basic join so far; to be extended)
• https://github.com/GrumpyOldTroll/libmcrx
• Hackathon AMBI implementation (POC; just the transport)
• https://github.com/GrumpyOldTroll/ambi
• Chromium with libmcrx & API (POC; do not use for browsing, not up to date)
• https://github.com/GrumpyOldTroll/chromium/tree/multicast
TBD:
- DORMS (with both CBACC and AMBI)
- CBACC
- AMBI ported to libmcrx
- Tunneling (AMT)

15. Next Steps
• Adoptions/dispatch?
• DORMS?
• CBACC?
• AMBI?
• WICG proposal
• Also needs support, please read and comment J
https://discourse.wicg.io/t/proposal-multicastreceiver-api/3939