Presentation from Networkshop46. GÉANT, by Mian Usman, GÉANT. Campus network refresh, by David Stockdale, Imperial College London. Multicast QUIC for video content delivery, by Richard Bradbury, BBC Research & Development.

1. Research and
education
Chair: Rob Evans,
Chief network architect, Jisc

2. GÉANT
Mian Usman,
GÉANT

3. www.geant.org3 |
www.geant.org
Mian Usman
Network Architect
JISC Networkshop46
GÉANT Network Overview

4. www.geant.org
Runs a membership association for Europe's National Research & Education Networks (NRENs)
GÉANT Association
Coordinates and participates in EC-funded projects
Under Horizon 2020 the financial instrument for implementing the Innovation Union, a
Europe 2020 flagship initiative aimed at securing Europe's global competitiveness
Operates a pan-European e-infrastructure
GÉANT network
Manages a portfolio of services for research & education
EduX
Organises and runs community events & working groups
TNC, task forces & special interest groups
To support collaboration and development amongst researchers, the dissemination
of information & knowledge, and provide access to a portfolio of services and
infrastructure resources:
4 |

5. www.geant.org
Membership Association
GÉANT Association supports and represents over 40 NRENs across Europe.
Together they support over 10,000 institutions and 50 million academic users.
5 |

6. www.geant.org
Network
The GÉANT network interconnects research, education and innovation communities worldwide,
with secure, high-capacity networks.
We design, plan, build and operate the large-scale, high-performance GÉANT network that connects
European NRENs to each other and the rest of the world for sharing, accessing and processing the high
data volumes generated by research and education communities and for testing innovative technologies
and concepts.
Interconnecting Europe’s NRENs
over a 500Gb highly-resilient
pan-European backbone.
NRENs serve 50 million users
at 10,000 institutions across
Europe.
Network services: IP, Point-to-
Point Services, VPN, Testbeds,
performance monitoring
6 |
Data transfer tests in 2017
between 10G servers in GÉANT
and AARNET achieved 9.73Gbps
over 48h through R&E
networks, whereas over
commercial links this was only
1.77Gbps.

7. www.geant.org
A separate ultra-high-speed internet, only for research & education
Ro​bustness
Over 1,000 terabytes o​​f data are transferred every day via the GÉANT IP backbone. ​
​Total ​​reliability
100% average monthly access availability​.
​​Flexibility
Services and infrastructure can be tailored to individual user requirements.​
​Capacity and rapid upscale
100Gbps (gigabits per second) services​ are now available across the core network, with a network
design that will support up to 8Tbps (terabits per second), ensuring the network remains ahead of user
demand and the data deluge.
​Efficient operations
The dedicated GÉANT Operations Centre ensures 99% of cases are reported within 15 minutes of any
outage being detected, leading to rapid resolution.​
Services
A wide range of services including IP and dedicated circuits, testbeds and virtualised resources,
authentication and roaming, monitoring and troubleshooting, advisory and support services.​
“Today it would not be possible to work without the
network that GÉANT and the NRENs have provided.”
CMS experiment, Large Hadr​on Collider (LHC)
Network
7 |

8. www.geant.org
GÉANT operates an advanced, high-performance network supporting Europe’s
NRENs with cost-effective, highly available, high-capacity services customised for
and dedicated to research and education
Availability Targets
99.999% - 27 seconds downtime/month
99.99% - 4.5 minutes/month
99.4%* - 4 hours/month
GÉANT network services
GÉANT IP – Ultra-high performance uncontended IP
connectivity at up to 100Gbit/s
GÉANT VPN – Layer 3 VPN services for NRENs and institutions
supporting private networking needs
GÉANT Point-to-Point – High performance dedicated
connectivity up to 100Gbit/s for the most demanding
applications
GÉANT Open – Allows NRENs and approved commercial
organisations to exchange connectivity in a highly efficient
and flexible manner
eduroam – Seamless WiFi access around the world
Network Services
8 |

9. www.geant.org
GÉANT network
Two main network
• Infinera based DWDM Network
• Juniper based IP/MPLS network
Overlay networks
• Global R&E IP
• LHCONE
• Internet Access Service
• Cloud VPN
• MDVPN
• P2P VPNs
• Project specific VPNs
GÉANT Network
Equipment
9 |

10. www.geant.org
GÉANT DWDM network
Based on Infinera DTNx
system – Network elements
provide large capacity point to
point circuits across defined
routes
GÉANT Point-to-Point – 10G
and 100G lambda services are
provided on this infrastructure
GÉANT Network
10 |

11. www.geant.org
GÉANT IP network
Based on Juniper MX Platform
– All layer 2 and layer 3 services
are provided on IP layer
GÉANT Point-to-Point – 10G
and 100G lambda services are
provided on this infrastructure
Makes use of GÉANT DWDM
Network for its core links and
uses leased capacity where
dark fibre isn’t available.
GÉANT IP Network
11 |

12. www.geant.org
GÉANT Overlays
Global R&E IP–connects the
NRENs and other regional R&E
networks
LHCONE – 10G connects the
NRENs and other regional
networks for LHC related data
service
Internet Access Service–
connects the NRENs to ISPs and
CDN networks
GÉANT Network Overlays
12 |

13. www.geant.org
Network Traffic
Average volumes during 2017
were 3.13PB per day for the
IP/MPLS network, average daily
rate of 289Gbps
Average volumes including
Lambdas are 4.79PB day or an
average data rate of 444Gbps
Science traffic growth: 43%
Internet traffic growth : 26%
GÉANT Network Traffic
13 |

14. www.geant.org
GÉANT Overlays
Global IP/MPLS – peaks of over 620Gbps with a daily average of over 430Gbps on the busiest days
Science traffic growth: 43%
Internet traffic growth : 26%
GÉANT Network Traffic
14 |

15. www.geant.org
• Single vendor solution
• High backplane capacity
• High space and power requirements
• Address scalability/cost on transmission layer
• Address scalability/cost on IP/MPLS layer
• Increase modularity – address vendor locking
• Allow for cost per bit optimisation by increasing delivery options
GÉANT Network Challenges
15 |
With a growth rate of over 50% projected traffic
in 10 years will be over 50 times that of current
traffic.
To address these challenges we need to optimise the network
architecture and take maximum advantage of the current
disruptive trends

16. www.geant.org
Industry Trends
16 |
Web Scale companies redefining the industry
• Moving towards disaggregation
• From a monolithic block to a modular, flexible and best in class
• Clean separation between hardware and software – each innovate independently of
other
• Transport Layer
• Open Line System
• Data Centre Interconnects (DCI) or External Transponders
• Packet Layer
• Merchant Silicon
• White/Brite Boxes
• Third Party NOS

17. www.geant.org
Industry Trends
17 |
Open Line System and Disaggregation at Transport Layer
• Support for multiple technologies/vendors over a single line system
• Offer alien wave transport as a managed service
• Integrated 3rd party DWDM pluggable available in various terminal technologies and vendors
• Still benefit from a single vendor providing end-to-end optical management
• channel & span equalization, DCN connectivity (OSC), ALS, Alarm reporting.

18. www.geant.org
Industry Trends
18 |
Partly disaggregated line system architecture allows for use of third party transponders on line
system by defining a DEMARC at the MUX. This allows for best in breed selection of
transponder and avoid vendor locking both financially and in terms of innovation curve.
This also enable better infrastructure sharing by lowering the cost of sharing capacity over
fibre.
Open Line System
ILAROADM ROADMILA

19. www.geant.org
Industry Trends
19 |
No Vendor
Lock in
Extreme
Flexibility
Lowest
Capex
Least Support
if breaks
Low Cost
Hardware
Easier to
Deploy
Higher
Software Cost
Potentially
Locked in to
Software Vendor
Least new
skills to learn
“One Throat
to Choke
Vendor Lock
in and Least
Flexible Highest
CAPEX
Increased
Flexibility
High Cost
Proprietary
Hardware
Requires
Specific Talents
Decreased
Vendor Lock
in

20. www.geant.org
Summary
20 |
• Moving from a monolithic blocks to a multivendor
envoirnment
• Lab testing of DCI boxes
• Facebook Voyager - Completed (including field trial)
• Juniper DWDM CFP2 100G ACO - Completed (including field trial)
• Coriant Grove G30 – Completed
• Acacia CFP2 DCO – Completed (including field trial)
• Packet Box and Network Operating Systems
• Corsa and Metaswitch Routing Stack – Completed
• Agema and OcNOS (IPInfusion) – On going
• Dell and Metaswitch/OcNOS – Planned for Q2/3 2018

21. www.geant.org21 |
Thank you
www.geant.org
Any questions?
© GEANT Limited on behalf of the GN4 Phase 2 project (GN4-2).
The researchleadingto these results has receivedfundingfrom
the European Union’sHorizon2020 research andinnovation
programme under Grant Agreement No. 731122(GN4-2).

22. www.geant.org
GÉANT IP
Ultra-high performance uncontended IP connectivity at up to 100Gbit/s
GÉANT IP provides IP transit for NRENs and other approved research and education partners and
providers. Its core function is to provide a private service for IP (internet protocol) traffic that is
separated from general-purpose access to the internet.​ Wor​king at speeds of up to 100Gbps,
GÉANT IP provides core connectivity that supports in​ter-NREN con​​nectivity​​.
Features
Peering
Provides NRENs with a high-performance, highly resilient peering facility, allowing access to a wide
range​​ of commercial network and cloud service providers.
GÉAN​T W​​orld S​​​ervic​​e (GWS)
Access to the wider, commercial internet. Ideal for NRENs that wish to take advantage of
competitive costing, or those that are keen to diversify their existing commodity IP access.
22 |

23. www.geant.org
Advanced networks and services need to be tested in near real-world environments
Using live networks poses risks to other users
The GÉANT Testbeds Service provides user-defined and user-controlled virtual e-infrastructure environments
containing transport circuits, switching/forwarding elements, computational elements and storage
These virtualised networked environments are dynamically created, scheduled, and can span Europe
GÉANT Testbeds Service
Enabling the development of the next generation of networks and services
23 |

24. www.geant.org
Features:
User oriented: User-defined networks under user control
Rich: Well-appointed inventory of useful resources
Simple: Minimal learning curve, intuitive user interface
Flexible: Supports a wide range of research topics and applications
Agile: Rapid prototyping, rapid, experimental iteration cycle
Secure: Supports high-risk experiments, protects the innocent
Scalable: Can support large-scale [global] testbeds
Reliable: 24x7 availability, predictable deterministic behaviour
GÉANT Testbeds Service
Objective: Make it easy for network researchers to quickly and effectively deploy,
evaluate, and refine novel concepts!
24 |

25. www.geant.org
High-Energy
Physics and
Astronomy
Earth
Sciences and
Observations
Future
Internet
Projects
E-Infrastructures
Life
Sciences
Social Sciences,
Arts and
Humanities
Users we work with
25 |

26. www.geant.org
Physics sciences
High-energy physics (LHC, BELLE II, CERN, etc.)
Neutrino observation (KM3NET)
Scientific user groups we liaise with
Future Internet projects (XiFi,
Confine, SmartFire, etc.)
Astronomy and Earth observation
Earth observation (EUMETSAT, COPERNICUS)
Radio-astronomy (eVLBI, SKA, etc.)
Satellite operations (ESOC)
E-Infrastructures (EGI, EUDAT,
PRACE, HelixNebula)
Life sciences
Genomics (Elixir, EBI, EMBL)
BioImaging
26 |

27. www.geant.org
TNC
The GÉANT community's flagship conference.
Regular attendance of over 700 participants from all across the world.
Bringing together decision makers, networking and collaboration specialists, and identity
and access management experts from all major European networking and research
organisations, universities, worldwide sister institutions, as well as industry
representatives.
tnc18.geant.org
27 |

28. Campus network
refresh
David Stockdale,
Imperial College London

29. >17,000 students
>8,000 staff
>Main campus – South Kensington, London
>Under construction – White City, London
>6 other large campuses (hospitals, Silwood Park)
>10+ other sites (hospitals, halls, sports grounds)
>2 datacentres – Slough & South Ken
>Centralised ICT
Facts and figures – Imperial

30. >Over 65,000 unique hosts on wired network
>Over 60,000 unique hosts on wireless network
>Over 20,000 concurrent wireless clients at peak time
>~400 active comms rooms (CWCs)
>~20 dark fibre links
>~15 Ethernet circuits
>40G to Janet via two 2x10G trunks
Facts and figures – Network

31. >Routers – 23x Juniper MX & Cisco 6500/6880/N7K
>Smaller sites – 12x Juniper SRX 2xx/3xx
>Firewalls – 2x Juniper SRX 3xxx
>Switches – 1,900x Juniper & Extreme
>Wireless – 2,900x Cisco lightweight APs
>VoIP – 10,000x Cisco handsets
Facts and figures – Equipment

32. Physical infrastructure
Core location
• Core router, dark fibre and optical equipment
Distribution location
• Site router, distribution switch
Building ODF (BODF)
• Passive fibre patching
CWC
• One or more stacks of edge switches

33. >One or more per building
>Fewer, bigger CWCs
>Stacks of edge switches
>Until now cat 5e
>In future cat 6a
>Diverse fibre to BODF
CWC

34. >One per building
>No active equipment
>Single-mode throughout
>Fibre to dist locations
BODF

35. >Typically 2-3 per site
>Site router
>Distribution switch
>Fibre to core locations
Distribution location

36. >Two in London
>Core router
>Lots of dark fibre
>Lots of optical equipment
>Also:
>Firewalls
>Border routers
>Route reflectors
>etc.
Core location

37. >DWDM and CWDM
>Physical topology != active topology
>Up to 40x 10G* links over single fibre pair
>Passive on shorter distances
>Amplifiers on longer links
>Coloured optics in our equipment
>Transponders for links to other equipment
WDM

38. Network hierarchy
Core routers
• 2 in London at different sites
Site routers
• Pairs, each attached to both core routers
Distribution switches
• Pairs, each attached to both site routers
Edge switches
• Each stack attached to both distribution switches

39. >2x MPLS P routers
>No VRFs
>Lots of 10G ports
>Lots of IPv4/IPv6 P2Ps
>OSPF v2/v3 as IGP – loopbacks & P2Ps
>iBGP with route reflectors – other routes
>PIM
>LDP
>ECMP
>Links to border, site, datacentre and wireless routers
Core routers

40. >VRF lite doesn’t scale well
>No per-VRF P2Ps or routing protocols
>VRFs don’t need to exist on intermediate routers
>VRF routes in iBGP
>L3VPN – IPv4 routes for VRFs
>6VPE – IPv6 routes for VRFs
>EoMPLS / VPLS / EVPN
>MVPN – Multicast for VRFs (Draft-Rosen, not MPLS)
MPLS

41. >2x central devices for everything
>One-armed off border routers
>VRFs map to zones
>eBGP session per zone, landing in VRFs on routers
>BGP for failover, rather than HA
>Networks Group runs network side
>Security Group maintains policy side
Firewalls

42. >Production
>BYOD
>Guest
>BMS
>Device management
>Registration
>Banned
>Many smaller VRFs
VRFs / firewall zones

43. >MPLS PE routers
>In pairs
>Limited, expensive 10G ports
>Dual-stack IPv4/IPv6 for production and BYOD
>VRRP / HSRP
>PIM, IGMP
>2x10G to each core router (40G ECMP)
Site routers

44. >Layer 2 only
>MLAG pairs of stacks
>Plentiful, affordable 1/10G ports
>2x10G per stack to each router (40G total)
Distribution switches

45. >1G PoE everywhere
>Interested in 2.5/5G – works over cat5e
>2x1/10G LACP to distribution
>Standard set of per-VRF VLANs
>All edge ports alike – VLANs assigned by RADIUS
>No UPS
>Edge SLA – higher SLA available in datacentre
Edge switches

46. >~30% of our Internet traffic IPv6
>Dual stack on production & BYOD (including wireless)
>AAAAs on most load-balanced services
>Other services enabled:
>Home directories (>95% IPv6!), more storage soon
>Mail, DNS, Skype for Business, HEP systems
>SLAAC rather than DHCPv6 (historical reasons)
>Feature parity mandated in tenders
IPv6

47. >2008 – First subnets enabled, separate firewalls
>2010 – Upstream native IPv6, dual-stack firewalls
>2010/11 – Most production and BYOD enabled
>2010/11 – Some servers including mail & DNS
>2011 – World IPv6 Day: College websites enabled
>2013 – Wireless enabled
>2015 – AAAAs added to most load-balanced VIPs
>During a migration to new hardware
>Single protocol backends
IPv6 - Milestones

48. >IPv4 exhaustion – wireless is now using /17!
>NAT will be inevitable – IPv6 minimizes it
>HEP community – dependent on IPv6, run out of IPv4
>Overseas students – better IPv6 connectivity at home
>People have it at home in UK! Sky, BT, Virgin (soon?)
>Cost us very little, deploying opportunistically
>Could cost a lot to deploy in a hurry!
>We’ve seen very few problems
IPv6 - Reasons

49. >Separate DMZ router connected to border routers
>Initially for HEP, soon to be standard service
>Bypasses firewall
>Avoids upgrading whole path
>Cheaper equipment but fewer features
>Essential moving towards 100G
>ECMP outbound, multiple subnets inbound = 40G!
Science DMZ

50. >We’re gonna need a bigger pipe… :-/
Science DMZ – Success!

51. >Private network for participating HEP sites
>Tagged VLANs on Janet links
>BGP peerings into L3VPN
>DMZ router has BGP peerings into Internet/LHCONE
>More specific LHCONE prefixes preferred
>It works…
LHCONE

52. >Router configs built and managed by Ansible
>Firewall groups fed from host database
>Switch configs automatically generated
>Network built from standard blocks
>All edge ports alike
>MPLS simplifies configuration
>WDM and dark fibre surprisingly affordable
>Simple is better!
Automation & scalability

53. David Stockdale
ICT Networks Group
Imperial College London
I have been…
Exhibition Road, London, SW7 2AZ
T 020 7594 6968
david@imperial.ac.uk
www.imperial.ac.uk

54. Any questions? /
Thank you

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

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

57. Motivation
Scalable Internet broadcasting using multicast QUIC

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

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

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

61. 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 hugeScalable Internet broadcasting using multicast QUIC
2,300,00
0
9,300,00
0
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,00
0
103,400,
000
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)

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

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

64. The challenge • How to reach 98% of
the UK population
without any terrestrial
spectrum.
To put that into
perspective:
• The last Royal
Wedding (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 forScalable Internet broadcasting using multicast QUIC
10×audience
5×encoded bit rate
=
50×load

65. What about IP
multicast?
Scalable Internet broadcasting using multicast QUIC

66. Objectives for a scalable IP-based TV 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 servicesScalable 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

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

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

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

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

71. 2.1 Resolve service endpoint address
Conventional unicast
media distribution
Scalable Internet broadcasting using multicast QUIC
Local
Encoder
Service
configuratio
n
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

72. Advertising HTTP over multicast QUIC
using HTTP Alternative 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
respons
e:
RFC 7838 key
fields
• ALPN protocol
ID
• Alternative host
• Port number
• Maximum age
parameter

73. 2.1 Resolve service endpoint address
Conventional unicast
media distribution
Scalable Internet broadcasting using multicast QUIC
Local
Encoder
Service
configuratio
n
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

74. 1.1 Discover service
Example
multicast
deploymen
t
architectur
e
Scalable Internet broadcasting using multicast QUIC
Local
Encoder
Service
configuratio
n
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-
Svc
HTTP GET
Response
HTTP GET
Responses
2.2 Initiate unicast
streaming session
Client
Proxy
Content origin
(may be a CDN)
Alt-
Svc

75. 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
configuratio
n
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

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

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

78. 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 howScalable Internet broadcasting using multicast QUIC

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

80. 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
WebSocke
t
HTTP Server Push
Web Browser
Service Worker + Web
Assembly
HTML 5 Media Player
HTTP GET
Responses

81. Thank you /
Any questions?