2 of 16

Health rules reminder

Take a covid test each day before attending any in-person event
Do not come to the meeting if your test is positive
Masks:

must be worn at all times in all common spaces and meeting rooms
must cover the nose and mouth
can be removed only as necessary to consume food and beverages (Food forbidden in meeting rooms and only allowed in the dedicated space)
must be absolutely worn while speaking

Find all the rules at: https://www.w3.org/2022/09/TPAC/health

3 of 16

W3C Expectations

This group operates under W3C Code of Ethics and Professional Conduc t

We're all passionate about improving the Web, but let's all keep the conversations cordial and professional.�

The group operates under the Community and Business Group Process

W3C seeks organizational licensing commitments under the W3C Community Contributor License Agreement (CLA). When people request to participate without representing their organization's legal interests, W3C will in general approve those requests for this group with the following understanding: W3C will seek and expect an organizational commitment under the CLA starting with the individual's first request to make a contribution to a group Deliverable.

4 of 16

TPAC meeting tips

To enter the speaker queue, either

‘Raise your hand’ using the control in the Zoom interface
Or ask for queue using your Zoom mic.
Or ask for queue using the deck mics on site.
Or q+ on https://irc.w3.org/?channels=%23multicast

Please mute if you are not actively speaking.
Please use headphones when speaking to minimize echo.
The first time you speak, please state your full name and affiliation.

5 of 16

Agenda

Intro (5m)

Welcome, Agenda-bash

Multicast Community Group (25m)

Mission, Goals, Motivation: 15m
Recent work: 10m

Discussion (30m)

Questions, Comments, Feedback

6 of 16

Multicast CG

Mission:

Enable multicast IP transport for web traffic to efficiently solve scalability problems in networking and web operations.

https://w3c.github.io/multicast-cg/multicast-cg-charter.html

Goal: get browsers to receive multicast, maintaining web security requirements.

7 of 16

Motivation: Impact of Peaks

Normal traffic day

vs.

Peak traffic day

�Goodput of 100KB+ objects

(Histograms each half-hour)

8 of 16

Motivation: Peak Traffic Days

Peaks come from popular content
Popular content = same bits to many people

Live sports
Popular VOD (Squid Game, Game of Thrones, etc.)
Popular Downloads (IOS, Patch Tuesday, Fortnite, Call of Duty)

Higher actual traffic demand (not just shifting between services)
Networks strained ~10-30x/year

9 of 16

Motivation: Peak Traffic Days

Peaks come from popular content
Popular content = same bits to many people

Live sports
Popular VOD (Squid Game, Game of Thrones, etc.)
Popular Downloads (IOS, Patch Tuesday, Fortnite, Call of Duty)

More actual traffic demand (not just shifting between services)
Networks strained ~10-30x/year

= mostly web traffic & smart tvs

10 of 16

Climate Impact

Internet=3.7%* of global carbon footprint (2019 estimate)

1% of total global footprint is internet video (300m tonnes)

~15-25% addressable with multicast
(does not include broadcast in transition to IP)

24m tonnes from video games (chiefly downloads)
Wide multicast ~4x better than stopping crypto proof-of-work

Cost of delivery & services

Network capital costs driven by peak load
Power needs/provider costs scale with traffic volume
Lower costs + competition => lower price for users

Motivation: Global Network Efficiency

* “Why your internet habits are not as clean as you think”, 2020-03-05, BBC

11 of 16

(Extra Background Resources w/ Motivation)

12 of 16

Recent Proposal: Multicast Extensions for QUIC

Protocol Specification�d raft-jholland-quic-multicast
Security Model�d raft-krose-multicast-security
Demo implementation in very early days:�aioquic fork

13 of 16

QUIC Multicast: Basic Operation

Source-Specific IP Multicast for some server --> client data
Anchored on the unicast connection

Frames from multicast channels could equally have been sent unicast
No special restrictions on unicast connection

Server-driven (with client consent)

Server MAY ask client to join channels (via extension frames in the draft)
Client MAY join as requested

Client provides limits (for congestion control as in RFC 8085)

Aggregate Max Rate
Max Channel Count

Client ACKs over unicast

per-channel packet number space
similar to multipath (w/multiple packet number spaces)

14 of 16

QUIC Multicast: Protocol Extensions

Transport Parameters

declare multicast support + client initial limits

New Extension Frames

Server -> Client

Channel lifetime & static properties: MC_ANNOUNCE, MC_RETIRE
Key rotation for encryption: MC_KEY
Requests of client’s channel state: MC_JOIN, MC_LEAVE
Integrity guarantees: MC_INTEGRITY

Client -> Server

Report channel join status: MC_STATE
Report packets received: MC_ACK
Congestion control limits: MC_LIMITS

15 of 16

H3 Capabilities

Response linked to request, so origin policy applies
Server Push

unicast push-promises referring to streams sent on multicast channels

Webtransport Server-initiated streams

unicast requesting stream id

Has unicast overhead, could be mitigated in future extensions�(e.g. a stream id in response header instead of client’s req stream id)

16 of 16

QUIC Multicast: Security Characteristics

Symmetric Keys shared across many clients for multicast traffic

Content presumed discoverable for broadcast events
Decoupled from a destination IP

IGMP/MLD (network join) = new information in local network

Key question: under what conditions is this safe?

Mitigation: disable in enhanced privacy mode

Threat model gap?

Literature on confidentiality focuses on private/personal info

Integrity protection anchored in secure unicast connection