IRC log of me on 2021-04-06

Timestamps are in UTC.

14:03:01 [RRSAgent]
RRSAgent has joined #me
14:03:01 [RRSAgent]
logging to
14:03:03 [Zakim]
Zakim has joined #me
14:03:08 [tidoust]
RRSAgent, make logs public
14:03:41 [igarashi]
igarashi has joined #me
14:03:45 [RobSmith]
RobSmith has joined #me
14:04:02 [dsinger]
dsinger has joined #me
14:04:04 [sudeep_]
sudeep_ has joined #me
14:04:04 [Song]
Song has joined #me
14:04:10 [tidoust]
Meeting: Joint Media & Entertainment IG / Web & Networks IG call
14:04:25 [kaz]
present+ Kaz_Ashimura, Chris_Needham, Adam_Waldron, Ali_C_Begen
14:04:39 [hta]
hta has joined #me
14:04:49 [myles]
myles has joined #me
14:04:57 [dom]
14:05:02 [tidoust]
Chair: Chris
14:05:06 [tidoust]
Present+ Francois
14:05:20 [tidoust]
14:05:25 [acbegen]
acbegen has joined #me
14:05:33 [kaz]
present+ Andreas_Tai, Ashish_S_Sharma, Dan_Druta, David_Singer, Dominique_Hazael-Massieux
14:06:03 [Yajun]
Yajun has joined #me
14:06:04 [hta]
Present+ Harald_Alvestrand
14:06:08 [kaz]
present+ Francois_Daoust, Harald_Alvetrand, Jake_Holland, Jon_Devlin, Lin_Li
14:06:42 [kaz]
present+ Christopher_Lorenzo, Pierre-Anthony_Lemieux, Rob_Smith, Sam_Hurst
14:06:55 [tidoust]
Topic: Media & Entertainment IG rechartering
14:06:57 [tidoust]
scribe: tidoust
14:07:10 [kaz]
present+ Song_Xu, Sudeep, Takio_Yamaoka, Tatsuya_Igarashi, Yajun_Chen
14:07:25 [tidoust]
cpn: CfC on the draft charter passed. No major comments. We'll take that through W3C Management for approval in the next few weeks.
14:07:39 [tidoust]
... Some charter extension will probably be needed in the meantime.
14:07:50 [tidoust]
Topic: Web & Networks IG rechartering
14:08:13 [tidoust]
sudeep_: Group review is done as well.
14:08:19 [tidoust]
... Thanks for all feedback received.
14:08:33 [tidoust]
Topic: Multicast Receiver API proposal
14:08:54 [tidoust]
cpn: Jake (Akamai) is proposing this. Welcome Jake!
14:09:00 [kaz]
present+ Sudeep_Divakaran
14:09:05 [kaz]
present- Sudeep
14:09:16 [kaz]
zakim, who is on the call?
14:09:16 [Zakim]
Present: Kaz_Ashimura, Chris_Needham, Adam_Waldron, Ali_C_Begen, dom, Francois, Andreas_Tai, Ashish_S_Sharma, Dan_Druta, David_Singer, Dominique_Hazael-Massieux, Harald_Alvestrand,
14:09:19 [Zakim]
... Francois_Daoust, Harald_Alvetrand, Jake_Holland, Jon_Devlin, Lin_Li, Christopher_Lorenzo, Pierre-Anthony_Lemieux, Rob_Smith, Sam_Hurst, Song_Xu, Takio_Yamaoka,
14:09:19 [Zakim]
... Tatsuya_Igarashi, Yajun_Chen, Sudeep_Divakaran
14:09:27 [tidoust]
Jake: I'm Jake Holland.
14:10:02 [tidoust]
... 50% of the time on why we think it's useful and why we think we need it
14:10:11 [tidoust]
... 50% of the time on how we propose to do it and next steps.
14:10:44 [tidoust]
... Multicast is about delivering IP packages to many subscribers at once.
14:10:48 [kaz]
rrsagent, make log public
14:10:53 [kaz]
rrsagent, draft minutes
14:10:53 [RRSAgent]
I have made the request to generate kaz
14:11:00 [tidoust]
... Identical payloads for everyone, no in-band 2-way communication
14:11:33 [tidoust]
... Main problem that can't be solved in any other simple way is congestion of the cable network.
14:11:53 [tidoust]
... The deepest you can put a cache is north of the place where congestion actually happens.
14:12:10 [tidoust]
... This is the sort of key problem that we don't think we can solve in any other way.
14:12:25 [tidoust]
... On a high-traffic day, this is the chart that we observe.
14:12:50 [tidoust]
... Congestion halves the goodput on average.
14:13:02 [tidoust]
... On a normal day, small bump that lasts 30mn or so.
14:13:57 [tidoust]
... [details chart axes]
14:14:25 [tidoust]
... left axis is 30mn slices.
14:14:56 [tidoust]
pal: So at 10 on this chart, half of the traffic is below 3-5mbps
14:15:00 [tidoust]
Jake: That's correct.
14:15:13 [tidoust]
... The point being that this is a bad user experience.
14:15:32 [tidoust]
... Most ISPs see some variation of this. Not always that clear a signal, but pretty common experience.
14:15:55 [tidoust]
... For reference, some access technologies and estimates.
14:16:39 [tidoust]
... In most cases, we're looking at up to 3000 subscribers that can be accessed.
14:17:39 [tidoust]
... Some other effects include power usage, also triggered by the device doing the forwarding.
14:18:03 [tidoust]
... 3.7% of carbon footprint globally, equivalent to air travel.
14:18:39 [tidoust]
... The power needs, you can turn them down outside of congestion period but still requires some power to manage.
14:19:10 [tidoust]
... 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.
14:19:35 [tidoust]
... This doesn't assume that we've been doing some scheduling on the client.
14:19:59 [kaz]
14:20:11 [kaz]
q+ Ali
14:20:13 [kaz]
ack a
14:20:41 [tidoust]
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?
14:21:09 [tidoust]
Jake: That's actually pretty common with new content of popular games being shipped to everyone.
14:21:44 [tidoust]
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.
14:22:16 [tidoust]
Jake: That is true, but in general, this is still valuable.
14:22:48 [tidoust]
... If you include "normal" days, we're looking at 8% traffic reduction overall. We think that this is pretty conservative.
14:23:37 [tidoust]
... 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.
14:24:02 [tidoust]
... 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.
14:24:21 [tidoust]
... That's the main thing that we're trying to get from browser integration.
14:24:40 [tidoust]
Subtopic: Browser API proposal
14:25:14 [tidoust]
Jake: We're getting to the API proposal. The proposal has been slightly updated with streams instead of messaging.
14:25:50 [tidoust]
... Source IP address of the sender, IP address of the group.
14:26:33 [tidoust]
... 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.
14:26:48 [tidoust]
... RESTCONF is an HTTP API that exposes modular HTTP driven set of messages.
14:27:10 [tidoust]
... That gets pulled in by reference.
14:27:37 [tidoust]
... The data that is in there is the AMBI proposal. Hashes of the data that is inside the UDP packets.
14:28:21 [tidoust]
... 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.
14:28:37 [tidoust]
... There are also bits to managing the bitrate.
14:29:03 [tidoust]
... 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.
14:29:19 [tidoust]
... In phase 2, we believe we can get the hashes with a multicast stream as well.
14:29:36 [kaz]
present+ Chun_Gao, Jon_Devlin, Larry_Zha, Lin_li, Christopher_Lorenzo, Pierre-Anthony_Lemieux, Rob_Smith, Sam_Hurst, Song_Xu, Sudeep_Divakaran, SYD, Takio_Yamaoka, Tatsuya_Igarashi, Yajun_Chen, Zachary_Cava
14:30:04 [tidoust]
... 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.
14:30:21 [Larry_Zhao]
Larry_Zhao has joined #me
14:30:49 [tidoust]
... Secure connexion to the DORMS server to retrieve the AMBI data.
14:31:03 [tidoust]
... and info about how to use the hashes.
14:31:35 [tidoust]
... 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.
14:31:40 [tidoust]
... There needs to be encryption.
14:32:42 [tidoust]
... 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.
14:33:05 [tidoust]
... However, that's still better because attackers need to be active, they can no longer be only passive.
14:33:21 [kaz]
rrsagent, draft minutes
14:33:21 [RRSAgent]
I have made the request to generate kaz
14:33:52 [tidoust]
... 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.
14:34:19 [tidoust]
... For things such as Pub/Sub, video conferencing, it might be less usable for that.
14:34:40 [kaz]
present+ Will_Law
14:35:24 [tidoust]
... 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.
14:35:45 [tidoust]
... Chromium is not interesting as doing mixed content experiments, and they consider this as mixed content.
14:36:11 [tidoust]
... If we can consider the one-to-many key distribution, they still need wider review before they can consider this.
14:36:37 [kaz]
present+ Yi_Lin
14:36:42 [tidoust]
... Fundamental difference with unicast and TLS because there is no 2-way communication with multicast, no return path.
14:37:15 [tidoust]
... First option that I'm trying to add to the spec: add something to AMBI metadata that adds symmetric key algorithm.
14:37:34 [tidoust]
... Key can rotate, it can be secured by third-party.
14:38:10 [tidoust]
... 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.
14:38:30 [kaz]
present+ Jake_Holland
14:38:30 [tidoust]
... That's not perfect, as users can still leak the key afterwards.
14:38:33 [kaz]
rrsagent, draft minutes
14:38:33 [RRSAgent]
I have made the request to generate kaz
14:38:58 [tidoust]
... Most of the API would stay roughly the same in that option, but encrypted traffic.
14:39:12 [tidoust]
... The browser would now be able to reject connections without encryption.
14:40:00 [tidoust]
... Other option would be to break this up in narrower APIs. No longer full payload of the UDP data passed to the JS.
14:40:44 [tidoust]
... Idea would be to put these in multicast capabilities. Add something to WebRTC to support multicast. To media delivery. Background downloader API. etc.
14:41:12 [tidoust]
... I'm not sure that I fully understand this feedback because I don't see how to address the challenges it raises.
14:41:35 [kaz]
present+ Larry_Zhao
14:41:39 [kaz]
present- Larry_Zha
14:41:39 [tidoust]
... Can the key distribution mechanism leverage DRM systems? I don't really know either, I haven't investigated.
14:42:14 [tidoust]
Jake: I include a slide on DVB, including link to a presentation I gave to DVB recently.
14:42:35 [tidoust]
... Over-the-top multicast is no supported in their multicast effort.
14:43:08 [tidoust]
... Either option would work with DVB-MABR.
14:43:26 [Larry_Zhao_]
Larry_Zhao_ has joined #me
14:43:40 [tidoust]
... Last slide before Q&A. Comparing the two options for the next steps.
14:44:00 [tidoust]
... The narrow API, we're going to want at some point no matter what.
14:44:19 [tidoust]
... The receiving of UDP payloads in JS allows for a wide range of experimentations.
14:45:35 [kaz]
present+ Peipei_Guo
14:45:41 [tidoust]
... 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.
14:45:50 [cpn]
14:45:54 [kaz]
present+ Hu_Hao
14:45:55 [dsinger]
q+ to ask about protocols, layering, names
14:46:03 [dom]
q+ to compare mixed-content with WebRTC
14:47:21 [kaz]
present+ Song_Xu
14:47:26 [tidoust]
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.
14:48:03 [tidoust]
... Maybe some of these problems will go away, but still it's different bits on the wire.
14:48:25 [tidoust]
Jake: If you're doing a 1-to-many encryption scheme, then you can have the same bits.
14:48:41 [tidoust]
Ali: Not really adopted at the moment. C-ENC is not that "common".
14:49:02 [tidoust]
Will: Common encryption is more supported that what you seem to suggest.
14:49:08 [kaz]
present+ Xiahong_Liang
14:49:30 [tidoust]
... The question of whether bits can be the same is plausible.
14:50:03 [tidoust]
... [missed bits on adapted streaming]
14:50:06 [cpn]
14:50:21 [tidoust]
Jake: In the end, we don't think that these problems cannot be addressed.
14:50:51 [tidoust]
Song: Two question: 1) Multicast is based on UDP. Do you think it makes sense to consider QUIC or WebTransport?
14:50:56 [hta]
QUIC cannot be multicasted, since it' defined point-to-point.
14:51:24 [tidoust]
... 2) Let's say WebRTC is going to handle these streams, is it open to developers?
14:52:10 [tidoust]
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.
14:52:30 [tidoust]
... With regards to QUIC, also sort of. BBC has a spec, pardue-http-over-multicast-quic.
14:52:48 [tidoust]
... That is operating at a sort of different layer.
14:53:04 [acbegen]
14:53:19 [tidoust]
... For experimentation, it would be feasible to put as-is in WebAssembly to handle.
14:53:44 [tidoust]
... Yes, I think both of those are feasible and interesting.
14:53:59 [tidoust]
... For WebRTC, that is the same as option 2, IIUC.
14:54:23 [tidoust]
... 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.
14:54:36 [tidoust]
... That's open for debate!
14:55:05 [tidoust]
dsinger: Multicast suffers from glaring problems in the past. Moving to single source multicast is pretty good in that proposal.
14:55:25 [kaz]
rrsagent, draft minutes
14:55:25 [RRSAgent]
I have made the request to generate kaz
14:55:50 [tidoust]
... IPv4 addresses and packets appear in your proposal. Why not using DNS, protocols? For instance, we use DAHS, HLD for streams.
14:56:02 [tidoust]
... For streaming, we could be using RTP over multicast again.
14:56:20 [tidoust]
... Better use of DNS would not tie us to IPv4 and IPv6, and URL forms.
14:56:42 [tidoust]
... Why doesn't FLUTE for instance use URLs?
14:56:47 [cpn]
14:56:50 [cpn]
ack dsinger
14:56:50 [Zakim]
dsinger, you wanted to ask about protocols, layering, names
14:57:20 [tidoust]
... That would then enable you to get you what you want free. With fallback to unicast when multicast is not supported.
14:57:31 [acbegen]
This is what Dave is referring to:
14:57:39 [tidoust]
Jake: I totally agree. That, I believe, is option 2 path.
14:57:54 [tidoust]
... Identify the protocols, and make it function. In my opinion, we're not really there yet.
14:58:21 [tidoust]
... FLUTE is great as far as it goes. Nobody that's implementing it is doing it strictly according to the spec.
14:58:43 [tidoust]
... I do believe that there is a lot of value to be gained by opening option 1 scenarios.
14:59:03 [tidoust]
... I'm open to supporting DNS as well for the IP but I think it complicates things.
14:59:05 [acbegen]
RFC 8815 already deprecated any-source multicast for across domains...
14:59:24 [tidoust]
dsinger: We should take it offline, I did some explorations there.
14:59:41 [tidoust]
... I sent some thoughts to FLUTE and mcast but got little feedback.
15:00:21 [tidoust]
dom: Another couple of comparisons with WebRTC. Mixed content, WebRTC has sailed that ship. There may be lessons to be learned there.
15:00:28 [tidoust]
... Source of comparison and inspiration perhaps?