4. Life for broadcasters used to be simple… • Broadcasting from a
terrestrial transmitter
has a fixed cost.
• The cost doesn’t depend
on how many people
tune in.
The Internet doesn’t work
like this!
Scalable Internet broadcasting using multicast QUIC
Source: BBC
5. The iPlayer service keeps getting more popular • Usage of the BBC iPlayer
service is climbing
steadily.
• 272M on-demand
programmes requested
per month in 2017.
• First episode of Blue
Planet II was requested
4.8M times.
• CDNs charge per byte
delivered by the edge
cache.
The cost of providing the
service rises in proportion
to its popularity.
Scalable Internet broadcasting using multicast QUIC
6. On-demand viewing is gaining ground…
…but linear viewing still dominates
• For the main TV channels
in the UK, on-demand
viewing represents only
85% of consumption.
• The remaining 15% is
DVR time-shifting,
downloading and on-
demand streaming.
• Time-shifting works best
for genres like drama,
comedy, entertainment
and documentary.
But linear viewing still plays
a major role for news, sport
and big events.
Scalable Internet broadcasting using multicast QUIC
Source: BARB
85%
15%
7. Linear television is still popular for big events • The BBC’s biggest
streaming event to date
was England vs.Wales in
the Euro 2016
competition.
• 2.3M simultaneous users.
• About 20% of total peak.
• Super Bowl 52 was
watched by nearly fifty
times as many viewers.
• Streaming represented
only 3% of total audience.
The potential audience for
linear streaming is huge and
scary.
Scalable Internet broadcasting using multicast QUIC
2,300,000
9,300,000
0
2,000,000
4,000,000
6,000,000
8,000,000
10,000,000
iPlayer
(Live peak)
BBC One
(Live peak)
Euro 2016 England vs.Wales
(2016-06-16)
Source: Radio Times
Source: AdWeek; USA Today
3,100,000
103,400,0
00
0
20,000,000
40,000,000
60,000,000
80,000,000
100,000,000
120,000,000
Internet streaming
(peak)
Live broadcast
(average)
Super Bowl 52 (2018-02-04)
8. There are more and more bits to shift! • Higher spatial resolution
(SD, HD, UHD).
• Improved colour fidelity
(High Dynamic Range).
• Better motion depiction
(Higher Frame Rate).
Not to mention:
• New content
experiences (3D, 360°
Video,AR,VR).
• Next Generation Audio.
All this keeps driving up our
CDN distribution costs.
Scalable Internet broadcasting using multicast QUIC
9. Cellular is biting at our heels • MNOs are hungry and
have deep pockets.
• 800 MHz band auctioned
in 2013 for 4G.
• 700 MHz band due to be
auctioned soon for 5G.
• 3GPP has developed a
technology stack called
MBMS for media
streaming over cellular
radio networks.
Our ability to innovate in
the broadcast space is now
hampered by lack of
available spectrum.
Scalable Internet broadcasting using multicast QUIC
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
470 MHz
854 MHz
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
790 MHz
694 MHz
X X X X X X X X X X X X X X X X X X X X
X X X X X X X X2013
2020
UHF Band V UHF Band VI
700 MHz Band auction 800 MHz Band auction
10. The challenge • How to reach 98% of the
UK population without
any terrestrial spectrum.
To put that into perspective:
• The last RoyalWedding
(April 2011) attracted a
total UK live audience of
more than 25M across
all distribution modes.
Even if CDNs could deliver
to that size of audience, we
probably couldn’t afford to
pay for it.
Scalable Internet broadcasting using multicast QUIC
10×audience
5×encoded bit rate
=
50×load
12. Objectives for a scalable IP-basedTV distribution system
1. Address mass audience reliably via managed and
unmanaged networks.
2. Reduce operational costs by using common media
packaging across unicast and multicast delivery modes.
3. React to variable network conditions using dynamic
adaptation techniques.
4. Reduce client complexity by adopting common network
protocols across unicast and multicast delivery modes.
• HTTP offers a common Layer 7 semantic for multicast delivery
and unicast repair.
• QUIC offers the possibility of a common Layer 4 across both
modes (once some specification gaps are filled).
5. Web-oriented mechanism for discovering the availability of
multicast services
Scalable Internet broadcasting using multicast QUIC
IP multicast
Fragmented MP4
(ISO Base Media File Format, CMAF)
MPEG-DASH with multiple multicast
representations
HTTP + QUIC
HTTP Alternative Services
13. IP multicast
• Layer 3 packet replication is efficient.
• Minimises stream duplication on network links.
• Implemented in the router, so no need for extra servers.
• We are looking at source-specific multicast.
• Avoid putting to much additional load on network routers.
• Our solution works with IPv6 as well as IPv4.
• Potential for easier deployment with IPv6.
• Fewer address space constraints.
• We will put a reasonable bound on the total number of multicast
groups.
• Keep the state held in routers down to a minimum.
Scalable Internet broadcasting using multicast QUIC
14. What is QUIC?
• New transport protocol that addresses some long-standing shortcomings of TCP.
• Originally developed by Google, but currently being standardised through IETF QUIC Working Group,
targeting publication as a set of RFCs late 2018.
• Like TCP, it is connection-oriented and reliable. Unlike TCP, it is secure by design.
• But these features are layered on top of unreliable, insecure and connectionless UDP datagrams
• Can be implemented easily on existing operating systems, outside the kernel in user space libraries.
• Promotes rapid prototyping of new features and early adoption.
• Fast connection establishment (0-RTT, 1-RTT) achieved by caching and subsequently reusing
security context from previous connections between the same client and server pair.
• Multiplexing of logical application-level data flows (“streams”) over a single transport connection in
such a way that data loss on one stream does not block progress on others.
• Independent flow control window for each multiplexed stream, plus a separate window for the overall
connection.
• Reduces the impacts of congestion and data loss on unreliable networks.
Scalable Internet broadcasting using multicast QUIC
15. Protocol stack:Common layer 7 and layer 4
Multicast
Optimisation path
(where available)
Unicast
Primary path
IP
UDP
MPEG-DASH application
TCP
QUIC
HTTP
Request/
Response
interface
HTTP/QUIC mapping
HTTP/2HTTP/1.1
TLS
• HTTP provides a well-
understood request/
response abstraction.
• Conventional (unicast)
QUIC supports this
abstraction by means of an
HTTP/QUIC mapping layer.
• We have adapted this to
multicast usage, so we end
up with a common Layer 7
semantic and the same URL.
• At Layer 4, the datagrams
can share a common packet
syntax if unicast QUIC is
also used.
Scalable Internet broadcasting using multicast QUIC
16. HTTP over multicast QUIC
• An independent Internet Draft that fills
some gaps between IP unicast and
multicast.
• Describes a means of service discovery
using HTTP Alternative Services
[RFC 7838].
• Bulk file delivery that intentionally
supports a broad range of Use Cases.
Scalable Internet broadcasting using multicast QUIC
https://datatracker.ietf.org/doc/draft-pardue-quic-http-mcast/
17. 2.1 Resolve service endpoint address
Conventional unicast
media distribution
Scalable Internet broadcasting using multicast QUIC
Local
Encoder
Service
configuration
Key
Local
Unicast HTTP
Management
1. Discover service
Service
discovery
Request
broker
Action
Packager
2.2 Initiate unicast streaming sessionMedia
player
Content origin
(may be a CDN)
HTTP GET
Response
HTTP GET
Responses
18. Advertising HTTP over multicast QUIC
using HTTPAlternative Services (Alt-Svc)
• Alt-Svc [RFC 7838] provides a means to advertise alternative protocols and/or endpoints that a client may
wish to switch to.
• We use it to decorate unicast HTTP responses with the details of our multicast QUIC streams.
• As part of this advertisement we need to be able to signal QUIC session parameters that would normally be
negotiated between a QUIC client and a QUIC server at connection establishment.
Scalable Internet broadcasting using multicast QUIC
GET /representation1/segment12345.m4s HTTP/1.1
Host: media.example.org
HTTP/1.1 200 OK
Content-Type: text/html
Alt-Svc: hqm="[ff3e::1234]:2000"; ma=7200;
source-address="2001:db8::1"; quic=1; session-id=10;
session-idle-timeout=60; max-concurrent-resources=10; peak-
flow-rate=10000; cipher-suite=1301; key=4adf1eab9c2a37fd
Unicast
request:
Unicast
response:
RFC 7838 key fields
• ALPN protocol ID
• Alternative host
• Port number
• Maximum age
parameter
19. 2.1 Resolve service endpoint address
Conventional unicast
media distribution
Scalable Internet broadcasting using multicast QUIC
Local
Encoder
Service
configuration
Key
Local
Unicast HTTP
Management
1. Discover service
Service
discovery
Request
broker
Action
Packager
2.2 Initiate unicast streaming sessionMedia
player
Content origin
(may be a CDN)
HTTP GET
Response
HTTP GET
Responses
20. 1.1 Discover service
Example
multicast
deployment
architecture
Scalable Internet broadcasting using multicast QUIC
Local
Encoder
Service
configuration
1. Discover
service
2. Initiate
playback
2.1 Resolve service
endpoint address
Service
discovery
Request
broker
Media
player
Key
Local
Unicast HTTP
Management
Action
HTTP GET
Response
Packager
Alt-SvcHTTP GET
Response
HTTP GET
Responses
2.2 Initiate unicast
streaming session
Client
Proxy
Content origin
(may be a CDN)
Alt-Svc
21. 1.1 Discover service
Example
multicast
deployment
architecture
Scalable Internet broadcasting using multicast QUIC
Multicast
distribution
network
Local
HTTP GET
Responses
HTTP GET
Responses
Encoder
Service
configuration
1. Discover
service
2. Initiate
playback
2.1 Resolve service
endpoint address
2.2 Initiate unicast
streaming session
2.3 Subscribe to
multicast
HTTP GET
Response
HTTP
Server Push
Service
discovery
Request
broker
Media
player
2.4 Repair
Key
Local
Unicast HTTP
Multicast HTTP
Management
Action
HTTP GET
Response
Packager
Multicast
sender
Alt-Svc
Client
Proxy
Content origin
(may be a CDN)
Alt-Svc
22. Prototype progress
• We have taken our Internet Draft and specialised it for the linear
media streaming Use Case.
• We envisage that this particular profile of HTTP over multicast QUIC
could be standardised.
• We have an end-to-end working prototype of a multicast
sender and a Client Proxy receiver.
• Based on an earlier Google specification of the QUIC protocol syntax
while we wait for the IETF to publish its variant as RFCs.
• The Client Proxy runs on embedded devices such as the Raspberry
Pi 2 and OpenWRT/LEDE routers.
• We are currently trying to demonstrate how the Client Proxy
functionality can work in a web browser.
• Plugging IP multicast into a browser environment is challenging!
• Ultimately, we want to encourage native browser support for HTTP
over multicast QUIC.
Y
X
M
Repair
U
Hosting
Oin
U′
U′′
Pin
Pin′
Playback
L
Control
Control
CMS
CMR
CCP
In scope?
Preparation
M′
Metrics
capture
RS
Report
capture
To be considered further
(maybe out of scope)
B
A
App
Playback
control
Scalable Internet broadcasting using multicast QUIC
23. Getting involved
• We would like to understand how our technology works
on real ISP networks.
• Understanding how our dynamic adaptation algorithms
respond to network congestion and multicast packet
loss.
• We have deployed head-end systems on the Internet that
are originating DASH streams over multicast QUIC.
• We would like to install receivers in end user locations to
collect network statistics.
Scalable Internet broadcasting using multicast QUIC
24. Conclusion
• We think that the future of linear television distribution over IP
networks will be a mixture of unicast CDNs and IP multicast.
• The two modes need to work hand-in-hand with each other to give
a seamless user experience.
• HTTP provides a common Layer 7 to achieve this seamlessness.
• QUIC provides a common Layer 4 packet syntax.
• Alt-Svc supports discovery of multicast from unicast.
• We have prototyped a system to demonstrate these principles.
• It works well in our (relatively benign) lab’ environment.
• We’d like to try it out on some real networks to see how these
ideas work in practice.
Scalable Internet broadcasting using multicast QUIC
26. IETF HackathonBBC R&D
Bonus slide:IETF Hackathon set-up
Scalable Internet broadcasting using multicast QUIC
Media Content
Hosting
Alt-Svc
Multicast
sender HTTP Server Push
GRE tunnel
Key
Unicast HTTP
Multicast HTTP
Raspberry Pi
Multicast Gateway
Embedded Media Player
Multicast
QUIC over
WebSocket
HTTP Server Push
Web Browser
Service Worker + Web Assembly
HTML 5 Media Player
HTTP GET
Responses