Joint Media & Entertainment IG / Web & Networks IG call

06 April 2021


Adam_Waldron, Ali_C_Begen, Andreas_Tai, Ashish_S_Sharma, Chris_Needham, Christopher_Lorenzo, Chun_Gao, Dan_Druta, David_Singer, dom, Dominique_Hazael-Massieux, Francois, Harald_Alvestrand, Hu_Hao, Jake_Holland, Jon_Devlin, Kaz_Ashimura, Larry_Zhao, Lin_li, Peipei_Guo, Pierre-Anthony_Lemieux, Rob_Smith, Sam_Hurst, Song_Xu, Sudeep_Divakaran, SYD, Takio_Yamaoka, Tatsuya_Igarashi, Will_Law, Xiahong_Liang, Yajun_Chen, Yi_Lin, Zachary_Cava
Chris, Dan, Igarashi, Pierre, Song, Sudeep

Meeting minutes

Media & Entertainment IG rechartering

cpn: CfC on the draft charter passed. No major comments. We'll take that through W3C Management for approval in the next few weeks.
… Some charter extension will probably be needed in the meantime.

Web & Networks IG rechartering

sudeep_: Group review is done as well.
… Thanks for all feedback received.

Multicast Receiver API proposal

<kaz> Slides

cpn: Jake (Akamai) is proposing this. Welcome Jake!

Jake: I'm Jake Holland.
… 50% of the time on why we think it's useful and why we think we need it
… 50% of the time on how we propose to do it and next steps.
… Multicast is about delivering IP packages to many subscribers at once.
… Identical payloads for everyone, no in-band 2-way communication
… Main problem that can't be solved in any other simple way is congestion of the cable network.
… The deepest you can put a cache is north of the place where congestion actually happens.
… This is the sort of key problem that we don't think we can solve in any other way.
… On a high-traffic day, this is the chart that we observe.
… Congestion halves the goodput on average.
… On a normal day, small bump that lasts 30mn or so.
… [details chart axes]
… left axis is 30mn slices.

pal: So at 10 on this chart, half of the traffic is below 3-5mbps

Jake: That's correct.
… The point being that this is a bad user experience.
… Most ISPs see some variation of this. Not always that clear a signal, but pretty common experience.
… For reference, some access technologies and estimates.
… In most cases, we're looking at up to 3000 subscribers that can be accessed.
… Some other effects include power usage, also triggered by the device doing the forwarding.
… 3.7% of carbon footprint globally, equivalent to air travel.
… The power needs, you can turn them down outside of congestion period but still requires some power to manage.
… If we get multicast out, we're looking at 40% reduction in peak load. We believe that this is a conservative estimate, based on our logs.
… This doesn't assume that we've been doing some scheduling on the client.

Ali: I get the motivation. But for games, what is the likelihood that I'm going to download the same game as my neighbourgh at the same time?

Jake: That's actually pretty common with new content of popular games being shipped to everyone.

Ali: That is true, but I'm thinking about e.g. my XBox that I only switch on once in a while and that I don't leave on otherwise.

Jake: That is true, but in general, this is still valuable.
… If you include "normal" days, we're looking at 8% traffic reduction overall. We think that this is pretty conservative.
… Avoidable traffic: example of live sporting events. Most is video. Blue line is what we have today. Red line is what we believe we can get.
… If we can save the peak for downloads but not for videos, we wouldn't solve much for ISPs as ISPs still need to focus on videos.
… That's the main thing that we're trying to get from browser integration.

Browser API proposal

Jake: We're getting to the API proposal. The proposal has been slightly updated with streams instead of messaging.
… Source IP address of the sender, IP address of the group.
… When the JS issues this join request call, the browser would check to make sure that this is ok and use the metadata from RESTCONF.
… RESTCONF is an HTTP API that exposes modular HTTP driven set of messages.
… That gets pulled in by reference.
… The data that is in there is the AMBI proposal. Hashes of the data that is inside the UDP packets.
… Receiving that over a normal TLS stream so that you're getting it on a side channel that is authenticated. If you do not see the same data, then you're going to reject the traffic that does not match.
… There are also bits to managing the bitrate.
… The way it works is that you're doing the multicast packet distribution and you're getting the hash of the packet through a unicast stream.
… In phase 2, we believe we can get the hashes with a multicast stream as well.
… JS comes from a secure context. We explicitly pass a DORMS hostname. You cannot make a connexion to a place that is not approved by the origin policy according to the DORMS server.
… Secure connexion to the DORMS server to retrieve the AMBI data.
… and info about how to use the hashes.
… The early feedback we got on this (thanks reviewers!), is that this is not going to be OK in a Web API because we need confidentiality.
… There needs to be encryption.
… I was rejecting this as not useful for broadcast. Symmetric keys are needed since packets are identical. Any single user can expose the key and anyone with the key can decode the stream.
… However, that's still better because attackers need to be active, they can no longer be only passive.
… Another issue around privacy: next-hop join exposure is really challenging to get rid of. At each chain of the network, there is going to be knowledge that there are subscribers downstream for a particular stream of content.
… For things such as Pub/Sub, video conferencing, it might be less usable for that.
… There are some pros/cons. Users get collapsed together as you get upstreams. The more broadcasting you're doing, the more privacy you're going to have.
… Chromium is not interesting as doing mixed content experiments, and they consider this as mixed content.
… If we can consider the one-to-many key distribution, they still need wider review before they can consider this.
… Fundamental difference with unicast and TLS because there is no 2-way communication with multicast, no return path.
… First option that I'm trying to add to the spec: add something to AMBI metadata that adds symmetric key algorithm.
… Key can rotate, it can be secured by third-party.
… An identity managed by the browser could be used with that fetch to the symmetric could be used to repel some people from retrieving the key.
… That's not perfect, as users can still leak the key afterwards.
… Most of the API would stay roughly the same in that option, but encrypted traffic.
… The browser would now be able to reject connections without encryption.
… Other option would be to break this up in narrower APIs. No longer full payload of the UDP data passed to the JS.
… Idea would be to put these in multicast capabilities. Add something to WebRTC to support multicast. To media delivery. Background downloader API. etc.
… I'm not sure that I fully understand this feedback because I don't see how to address the challenges it raises.
… Can the key distribution mechanism leverage DRM systems? I don't really know either, I haven't investigated.

Jake: I include a slide on DVB, including link to a presentation I gave to DVB recently.
… Over-the-top multicast is no supported in their multicast effort.
… Either option would work with DVB-MABR.
… Last slide before Q&A. Comparing the two options for the next steps.
… The narrow API, we're going to want at some point no matter what.
… The receiving of UDP payloads in JS allows for a wide range of experimentations.
… You wouldn't have to touch on the sending side. Combining with Web Assembly, you could make a decision as to what protocols need to be promoted to first-class citizens on the Web.

Ali: I don't know whether this is feasible, acceptable, doable. In one of the earlier slides, you mention commonality in the bits that people download. All of this video is carried using adaptive streaming, different codecs, bitrates, etc. Even though we're watching the same thing, there will be 10 versions of the same content we're downloading.
… Maybe some of these problems will go away, but still it's different bits on the wire.

Jake: If you're doing a 1-to-many encryption scheme, then you can have the same bits.

Ali: Not really adopted at the moment. C-ENC is not that "common".

Will: Common encryption is more supported that what you seem to suggest.
… The question of whether bits can be the same is plausible.
… [missed bits on adapted streaming]

Jake: In the end, we don't think that these problems cannot be addressed.

Song: Two question: 1) Multicast is based on UDP. Do you think it makes sense to consider QUIC or WebTransport?

<hta> QUIC cannot be multicasted, since it' defined point-to-point.

Song: 2) Let's say WebRTC is going to handle these streams, is it open to developers?

Jake: Can we put in WebTransport? No, because of TLS. I think it would make sense to include a multicast receive in WebTransport if we can solve some of it. That's worth exploring.
… With regards to QUIC, also sort of. BBC has a spec, pardue-http-over-multicast-quic.
… That is operating at a sort of different layer.

<acbegen> https://datatracker.ietf.org/doc/draft-pardue-quic-http-mcast/

Jake: For experimentation, it would be feasible to put as-is in WebAssembly to handle.
… Yes, I think both of those are feasible and interesting.
… For WebRTC, that is the same as option 2, IIUC.
… We do want to get there one day for performance. I would suggest that this would be better, at least in my opinion, to get this in experimental form to start with.
… That's open for debate!

dsinger: Multicast suffers from glaring problems in the past. Moving to single source multicast is pretty good in that proposal.
… IPv4 addresses and packets appear in your proposal. Why not using DNS, protocols? For instance, we use DAHS, HLD for streams.
… For streaming, we could be using RTP over multicast again.
… Better use of DNS would not tie us to IPv4 and IPv6, and URL forms.
… Why doesn't FLUTE for instance use URLs?

<Zakim> dsinger, you wanted to ask about protocols, layering, names

dsinger: That would then enable you to get you what you want free. With fallback to unicast when multicast is not supported.

<acbegen> This is what Dave is referring to: https://www.ietf.org/archive/id/draft-singer-appsawg-mcast-url-00.txt

Jake: I totally agree. That, I believe, is option 2 path.
… Identify the protocols, and make it function. In my opinion, we're not really there yet.
… FLUTE is great as far as it goes. Nobody that's implementing it is doing it strictly according to the spec.
… I do believe that there is a lot of value to be gained by opening option 1 scenarios.
… I'm open to supporting DNS as well for the IP but I think it complicates things.

<acbegen> RFC 8815 already deprecated any-source multicast for across domains...

dsinger: We should take it offline, I did some explorations there.
… I sent some thoughts to FLUTE and mcast but got little feedback.

dom: Another couple of comparisons with WebRTC. Mixed content, WebRTC has sailed that ship. There may be lessons to be learned there.
… Source of comparison and inspiration perhaps?
… WebRTC is an example of taking a complex network situation and "web-inize" it.
… This could help approach multicast.

Jake: Very useful. Do you have a good starting point for WebRTC to start learning for lessons?

dom: Harald authored an overview document.

<kaz> WebRTC Overview

hta: That's a good starting point.
… It has the concept of finding around an endpoint and initiating a session, which is similar to what you're trying to achieve here.

<Zakim> dom, you wanted to compare mixed-content with WebRTC

Jake: Thank you very much, very good suggestion!

cpn: I wanted to ask you whether you have a place where this is discussed? What's the best way to contribute?

Jake: The IETF specs, there have been some discussion in the net-dev group.
… I haven't found the right venue in W3C yet.
… I would very pleased to get some follow-up either in the same thread as the Chromium net-dev one or elsewhere.
… A W3C forum would be good if we had such a thing.
… The WICG explainer is probably the best place now that I think about it.
… That's the link that's the top link in the slide about the AMBI.
… The thread in WICG's discourse instance.

cpn: OK, it may be that either the Media & Entertainment IG or the Web & Networks IG can facilitate some of the discussions.
… As IG, we're limited in what we can achieve in terms of shaping the solution, but gathering a common understanding of where we should go.

Jake: That would be great, I'm having a hard time gathering feedback, even though the spec has been online for some time now.
… It would be very useful to get further engagement on this.
… Ryan Sleevi gave really good feedback in the net-dev discussion.

<dom> [thanks for an excellent presentation Jake!]

cpn: I'll discuss with other IG chairs.

<kaz> +1

<kaz> [adjourned]

Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).