Multicast QUIC for video content delivery

Multicast QUIC for
video content
delivery
Richard Bradbury,
Lead R&D engineer, BBC
Research and Development

Presentation to
JISC Networkshop46
Richard Bradbury
28th March 2018
Scalable Internet
broadcasting using
multicast QUIC

Motivation
Scalable Internet broadcasting using multicast QUIC

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!
Source: BBC

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.

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.
Source: BARB
85%
15%

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.
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)

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.

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.
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

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.
10×audience
5×encoded bit rate
=
50×load

What about IP
multicast?

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
IP multicast
Fragmented MP4
(ISO Base Media File Format, CMAF)
MPEG-DASH with multiple multicast
representations
HTTP + QUIC
HTTP Alternative Services

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.

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.

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.

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.
https://datatracker.ietf.org/doc/draft-pardue-quic-http-mcast/

2.1 Resolve service endpoint address
Conventional unicast
media distribution
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

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.
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

1.1 Discover service
Example
multicast
deployment
architecture
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

1.1 Discover service
Example
multicast
deployment
architecture
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

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

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.

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.

Thank you
bbc.co.uk/rd
richard.bradbury@bbc.co.uk
Email:

IETF HackathonBBC R&D
Bonus slide:IETF Hackathon set-up
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

Multicast QUIC for video content delivery

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Multicast QUIC for video content delivery

Similaire à Multicast QUIC for video content delivery (20)

Plus de Jisc

Plus de Jisc (20)

Dernier

Dernier (20)

Multicast QUIC for video content delivery