<kaz> scribenick: cpn
Chris: I've invited my colleague Lucas to present today on some work we've been doing at IETF and API gaps in the Web platform.
Lucas: This talk was presented at the
recent Web5G workshop, and we wanted to follow up in the M&E
IG.
... This is an updated version of the talk I gave there.
<kaz> fyi. Web5G Workshop Report
<kaz> Lucas's slides
Lucas: (Slide 3) The BBC is a
broadcaster, life used to be simple, fixed cost terrestrial
transmission network.
... The internet doesn't work like that. iPlayer usage is
increasing.
... (Slide 4) We publish statistics on usage. 272 on demand
programmes per month, popular content, Blue Planet 2
... Cost increases with popularity.
... (Slide 5) We've had discussions with people in other markets.
Live viewing in the UK is 85%, the rest is time shift or
on-demand.
... You can see the graph shows a small 2-3% increase aligned with
the World Cup, or Wimbledon.
... This shows linear TV is popular, especially for cultural
events. One of the largest events to date was the England vs
Tunisia football game at the World Cup 2018.
... (Slide 6) The consuption over traditional broadcast was 18
million, and 3 million on the iPlayer.
... The peaks for internet streaming are different for live.
... What I'm showing here is the potential for live streaming over
IP
... (Slide 7) The nature of the content is changing, the move to
HD, UHD, HDR.
... Also new content experiences, 360 video, VR, AR. These all
require more bits, hence increasing CDN costs.
... (Slide 8) Frequency spectrum for broadcast TV distribution is
being reduced, for use by 4G or 5G mobile.
... We didn't provide UHD over broadcast, not enough
bandwidth.
... What happens when broadcast goes away?
... (Slide 9) We are chartered to reach 98% of the population, this
includes large events.
... We're looking at an all IP future, how to do without breaking
the bank?
... 50x increase in load, so it's much higher bitrate. the HD bit
rate is 5-8 mbit/sec. We did live UHD at 36 mbit/sec.
Lucas: (Slide 11) How to solve this
challenge? Can we use IP multicast?
... Layer 3 packet replication, use the inherent capability of
network equipment rather than duplicate packets
... IPTV is well deployed today. Works well in managed networks or
vertical deployments.
... For example, BT or Sky can manage their networks.
... But we also need to consider OTT.
... 3GPP has MBMS technology.
... (Slide 12) Streaming over HTTP is increasingly embraced in the
industry.
... Many kinds of networks and client devices.
... Success driven by use of existing network technologies and
CDNs.
... This is all familiar ground in this group, but I cover it as
I'm laying the foundation for the next part.
... (Slide 13) Adaptive streaming, aligning to MPEG-DASH, smooth
streaming, HLS.
... But we're talking about multicast here, want to take HTTP based
media and deliver over multicast
... (Slide 14) Other things out there: 3GPP MBMS, ABR Multicast on
CATV networks
... DVB group working on commercial requirements, then technical
task force. Reference architecture in DVB BlueBook A176.
... It allows distribution of HTTP resources (files), with error
recovery, loss detection and repair.
... Group is now looking at technical solutions
... (Slide 15) Possibly multicast transports, such as NORM, FLUTE,
ROUTE, and BBC is working on multicast HTTP/QUIC.
... This is unidirectional delivery of HTTP resources.
... We want to receive files, reconstruct in a way a standard DASH
client can play them.
... Different strategies to achieve this. Metadata descriptions for
reconstruction.
... Importantly, it's a push mode delivery, having gone first
through a discovery phase.
... Can send different bitrates to different mutlicast groups
... Clients are dependent on another agent external, to do the
multicast reception. It could be on a home router or further
up.
... This is in the DVB Bluebook.
... What would it look like if we had unicast delivery integrated
into the Web platform? So we don't need the upstream box.
Lucas: (Slide 17) We have an HTTP
origin server, with a pull mode DASH streaming session. GET
requests to receive segments.
... Also a multicast sender, we call it Multicast HTTP to push to a
web application.
... Open a Web Socket connection, wait for events to be pushed.
Those events could be DASH segments with their metadata.
... (Slide 18) But we don't think that's the only use case for the
push mode distrubution.
... Scalable media distribution, low latency distribution. These
still reqiuire the client to know what to ask for.
... Server push can reduce latency, it's a possibility, needs more
work to investigate.
... Sending notifications, eg., server sent events for textual
content. What about other kinds of content?
... You can do some of this today. We've tried using Web Sockets to
reduce latency for notification of updates, e.g, score updates on
our Sports pages. It's costly for us to do at large scale.
... (Slide 19) A CDN infrastructure geared more towards push could
be helpful. But an API is needed.
... Existing APIs aren't good for pushing web resources to
JavaScript code. Resources with URLs with standard metadata.
... Same origin and secure context requirements.
... Let the UA do the heavy lifting, parse, decode, etc.
... Making this available in different contexts, use familiar
paradigms.
... (Slide 20) Comparison of push mode APIs: HTTP Server Push,
Server Sent Events, Push API, Web Sockets.
... This is a way for us to compare these technologies.
... When we started talking about this, Chris asked about the Push
API, could it work? Possibly, but it doesn't handle the
encapsulation and mapping that I want to avoid.
... We're not the first to think about HTTP Server Push APIs.
Considered in the Fetch spec. For example, Alex Russell's GitHub
gist
-> https://gist.github.com/slightlyoff/18dc42ae00768c23fbc4c5097400adfb
scribe: How do we move this topic
process forward, who to speak to?
... (Slide 22) Of the candidates, we think Fetch Observer seems the
best candidate.
... It's closely coupled to the HTTP/2 Server Push transport,
although this may not be popular now.
... It has mixed results for web performance, possibly reducing
page load times, but it could waste bandwidth pushing things the
client doesn't need and potentially increase page load time,
actually.
... People are asking if Server Push is really relevant to the
future of HTTP.
... Brad Lassey at Google asked whether destroying push would
anyone notice?
... But we think it is useful, to support unidirectional flows of
HTTP resources.
... It would be a shame to lose this capability, miss out on
exciting new use cases.
Lucas: (Slide 23) We defined a
ResourcePushEvent, it aligns to a pseudo-request with a URL and
metadata, and then a promise for a response.
... We can use it in a Fetch API like manner.
... It could work with other transport modes, e.g., FLUTE to
deliver a resource and generate an event.
... It's more general, not tied to Server Push.
Lucas: We did some experiments, with
HTTP/QUIC to the browser.
... (Slide 25) We have an independent internet draft. It looks at
QUIC and the HTTP over QUIC mapping.
... What would need to change to support unidirectional delivery?
It relies on Server Push.
... (Slide 26) We have a prototype based on Google QUIC, work
underway to move to IETF QUIC.
... A receiver on a Raspberry Pi, with our own library to
reconstitute packets.
... If anyone is at IBC, we'll be demoing this in the Future Zone.
Please come and see us.
... (Slide 27/28) We wanted to make a proof of concept. Can we
cache the receive objects and feed into a player pipeline?
... We made a workaround component, but this still works in a push
mode, sending push promises to the browser
... (Slide 29) A demo application, HTML page with DASH.js and a
Service Worker.
... The Service Worker has the intelligence in it. We do discovery
of the multicast, it subscribes and caches segments just ahead of
the player requesting them.
... What actually happens is the Service Worker receives QUIC
packets in userland. We used Emscripten and WASM in the Service
Worker.
... Feed in packets, it generates a ResourcePushEvent.
... We want to put this into the browser core.
... (Slide 30) Tested working in Firefox and Chrome.
... (Slide 31) There's an Alt-Svc header that advertises the
multicast group.
... (Slide 32) We published this in a BBC White Paper after
discussion with Alex Russell and others.
... -> https://www.bbc.co.uk/rd/publications/whitepaper336
Lucas: (Slide 33) To wrap
up, we think there are compelling use cases for push mode
interactions on the web.
... Server push is well suited, it avoids the need for custom
protocols.
... We want to further the work on the experimental client to see
if we can do true multicast in the browser.
... The browser could do the validation for content authenticity
and integrity.
... Any comments or questions?
<Zakim> kaz, you wanted to ask if it's ok to distribute these (updated) slides to the public list (later)
Kaz: Can we share the slides with the M&E IG
Chris: Yes. Actually, I did already, will circulate in the minutes.
Kaz: Regarding the Fetch-based approach for server push,
when I talked with some of my colleagues about server push, we thought it would have been better
to use Fetch rather than WebSocket from standardization viewpoint,
so I'm interested in this approach
... There's also the Web of Things WG, working on a higher
level scripting API for IoT devices
... An API for servers to expose their capabilities and another API for
clients to consume exposed capabilities
... This mechanism could be used for video streaming as well
... so should be interesting to discuss with the WoT group
... that's why proposing a joint session during TPAC
<kaz> scripting api draft
Giri: In ATSC we implemented
WebSocket between the receiver and the Web App.
... We wanted to avoid reliance on a push API.
... It's not really a theoretical issue for us.
... We took care to avoid unnecessary reinitialization of the
codecs, e.g., passing init segments to the MSE instance.
... How do you minimise reinitialization?
Lucas: I'm not a DASH expert, but we
have a common init segment. The request flow would be: Get MPD,
then get init segment for each representation.
... There's no period where we get more init segments. The init
segment is quite small, doesn't benefit from delivering over
multicast, so we'd leave it as unicast.
... We could follow up offline.
Giri: we have constraints, not all
TVs are internet connected.
... We allowed the WebSocket interface to do sub-segments.
... Want to minimise dead air time, so we deliver bytes to the web
application and the MSE instance.
... Is that considered in your implementation? Do you wait for the
full segment to arrive before giving it to the browser?
Lucas: I think both can be supported.
The library is built to receive the full segment, taking losses and
the need to repair into account.
... The API I showed is returns a Promise for a Response. You could
do an early resolution and then stream the bytes as they're
ready.
... I think DASH.js has experimented with this, pipelining delivery
of bytes end to end.
... I agree with the problem statement. I would encourage
discussion around improvements on this for the Web platform.
... In general latency is bad for live media. Having the
flexibility to optimise is beneficial.
Will: Thanks for a good presentation.
I have a question about the solution space.
... Push vs pull doesn't change the bits going across the
wire.
... From a traffic profile perspective, if you put in a caching
server, you have the same profile as with a pull-based
approach.
... In my mind, the difference is about timing from the client
point of view.
... With smart clients, we can get the timing down. I'm worried
about the effort involved.
Lucas: It's a valid comment. Our IP
glide-path means we want to be fully IP.
... The cost of server infrastructure is high. We see the future as
being a combination of unicast and multicast.
... Some way of managing peaks using HTTP.
... DASH benefits from having an explicit timeline, and knowing
when is the right time to do things, and minimising this.
... Ad-hoc or unpredictable content delivery, we consider this is
as a unidirectional flow.
... A callback function or mechanism for a push is needed, but this
isn't in the Web platform.
... Jake Archibald has a good article on this. The content can be
pushed to the client, but it sits in the push cache. It's only when
the client makes an HTTP request that the content is delivered.
-> https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/
Will: Multicast is typically done on
a managed network. So you'd need to accommodate very rapid
fluctuations in throughput to do this on the public internet.
... The client still needs intelligence, as the server doesn't
know.
... So there's still a complex feedback loop between client and
server.
Lucas: This is true, the DVB work on
ABR requires the separation of qualities all the way to the
client.
... The client detects congestion differently than with TCP.
... General internet-wide OTT multicast isn't a thing yet, but it's
feasible for us to work with partners to enable multicast over
certain network segments so that content is also available on
multicast.
... Users want a seamless experience, and our design aims to
achieve this. We do a race, effectively. The master is always
unicast HTTP, the multicast is an alternative option, advertised
through the Alt-Svc. Which is different to the traditional HTTP
based view.
Chris: We're out of time now. Thank
you Lucas for joining us and presenting today.
... Our hope for this work is to continue the discussion among the
browser vendors.
Chris: The next call is Tuesday 5th
September, topic TBD.
... [adjourned]