Meeting minutes
Introduction
Jake: Welcome everyone! Looking forward to working with you all
… Let's introduce ourselves
… I'm Jake Holland, been working on multicast at IETF for a while. It's where I spend most of my time. I'm an architect at Akamai
Chris: I'm at the BBC, co-chair of Media & Entertainment Interest Group and Media WG
Brett: I work on the Librecast project, which aims to get multicast working more widely on the internet. I do multicast advocacy, lurking on the MBONED IETF list
Casey: I'm a network engineer for a research and education network in Kansas. We've had various flavours - ASM and SSM deployed natively on our backbone. We're interested in continuing that, it's a good technology for the internet
Kyle: I'm work at Akamai with Jake. I lurk in MBONED at IETF, I'm helping Jake with the security aspects of multicast. I'm also co-chair of the MOPS WG at IETF
Mike: I'm a long-time multicast guy at IETF, working with Jake. I've worked with Cisco and Ericsson, Huawei. I'm interested in the application side
Sudeep: I work at Intel, I'm co-chair of the Web & Networks Interest Group, together with Dan Druta at AT&T and Song Xu at China Mobile
… We work on bridging gap between Web and 5G, 3GPP, new and upcoming use cases on edge computing. Multicast is an interesting topic, so want to follow what's happening here and see how we can work together
Charter Review
Jake: I want to check we have consensus on the charter.
… Has everyone read the charter?
<bacs> aye - read it
<squarooticus> have read; no objections
Jake: Any objections to the charter, or comments?
+1 from me
Brett: By being here, we're in agreement
Jake: Let's call it ratified. I'll update the charter with the start date
Jake: If you'd like to be a co-chair, or if someone else wants to chair, please let me know. But I'm willing to run it. Please provide constructive feedback.
Meetings
Jake: How often to meet? I think a monthly 1 hour update would make sense. This timeslot could work, open to alternatives.
<krose> Let's do a doodle to work out the right timeslot. I know I usually have a team meeting from 11:30-12:30, that for just this week happens to be 12-1. (ET)
Jake: There's enough detailed work to do to set up working sessions to go through details on specific topics. We can get together in separate sessions, and then report back each month
<bacs> sounds good
Jake: Any other suggestions?
Kyle: We could do a Doodle poll for a regular monthly meeting slot
<Mike> Any day works fine just not earlier than this time.
Chris: Avoiding Tuesday would be good. Another idea is to have alternating timeslots, morning and afternoon
Jake: I'll ask for votes
Proof of concept implementations
Jake: I'd like to help people get up and running with some implementations, so i'd like to set up a meeting to do that
Deliverables
Jake: The charter lists some deliverables. Testing implementations, would be good to get people involved in both implementations and testing
… There's a lot of work to do. The prototype stuff out there is hacky, needs fleshing out to make it useful in production quality services
… The more people we can get looking at this the better. Many hands make light work
… There's a few different things that would be useful to do
… I'm grateful for any constructive contributions people can make
… Specs need writing, how things should work
… Also reviews of specs need doing
… The API needs developing, writing tests. We're at an early stage of the project. This is where the biggest piece of work is.
… This would be the focus of the first working meeting, to get up and running
… Supporting the use cases people have in mind is important. I encourage people to start using the API and building things, to help debug
Mike: This is my first time joining a W3C meeting. Is it similar to IETF, how does document publishing work?
<jholland> chris: this is a community group, but in order to be standards track this needs to be adopted into a working group
<jholland> ...there's a lot of working groups, we'll need browser vendors on board for a browser API proposal, for instance
<jholland> ...it's also possible to propose to an existing group an extenstion
<jholland> ...there's stages of development, including horizontal review with security, privacy, internationalization, etc. all as part of the standards track process
<jholland> ...but at this stage we can focus on the proposed API development and get some engagement from the browser vendors
Jake: On that point, we did take this to Chromium as a first try. They said no, their feedback was this is a new kind of mixed content - in that it doesn't follow the same security model for web apps, e.g., when receiving TLS
… I got similar feedback from the WebTransport group. So I then went back to plan A, which is to satisfy security concerns, and propose to WebTransport
Jake: Kyle started writing a document
Jake: There's a list of specs in the charter that we should be interested in. This document is our first take on a security analysis for multicast transport to the browser
… There are some differences with that and unicast transport. In terms of app use cases, we assume it's possible to satisfy the security concerns
… It's possible that some in the web community will push back, saying it can't be made secure enough
… The worst of the threat models, RCE through buffer overflow in video rendering, for example. These are solved through authentication and integrity protection
… Confidentiality concerns were also brought up. So we're trying to understand the threat model, and understand the issues exposed for browsers
… We think it's addressable, but it'll be a consensus question, both at IETF and W3C
… Review and in-depth coverage of that topic is one of the big things to document
… Any other questions about W3C?
Mike: No, Chris's comments helped
Brett: WebRTC was exciting, I thought we could use it for multicast. The encryption built in is - like TLS, a 1:1 key exchange, and that doesn't really work over multicast
… There are other things we could do to set up a key exchange, to get a group key. I'm looking at that in my project
… It needs some form of handshake communication. It's not a problem specific to multicast. But we need to hang on to scalability
Jake: There may be some things unicast can do that would be hard to match. What's the impact on the user, and what mitigations would service providers and browsers need to take to make this work at an acceptable level?
… What's the privacy risk of watching a large scale video event? Challenging to pin down, it's not been well documented as a threat model, as far as I know
Jake: I'd like to help people get up and running next week, if people want to contribute at that level. Then we can see what people can build on from there
… Any other suggestion for what to do first?
… An outcome from that could be tutorials.
… Where we'd like to get is into implementation and testing, and into specifications. It'll be important to refine our security argument, perhaps that's where to start?
Brett: I have funding in my project to work on certain milestones related to IPv6 multicast specifically. Working on a WebRTC video conferencing streaming server
… I'll check for overlap with what this group is trying to do, so can use that to see what I can contribute
Jake: We have WebRTC as a phase 2 item. It could supplement a WebRTC conferencing session, so it can scale more than currently. Could be a good way to do low latency
… Low latency access for a few participants, plus large scale broadcast
… There are a few channels running, sending TS encoded traffic. I haven't tried that using Media Source Extensions. I'd be curious to try that
… I'm interested in that use case. I thought WebRTC used the same kind of codec paths. It could be a proof of concept
… The other use case is the previous BBC work - Lucas's work on HTTP over multicast QUIC. Using WASM to receive that traffic would be interesting.
… They showed it playing video in a browser, but I think the last step to the browser was WebSockets? The prototype now could feed it straight into a web app
… That would be an interesting thing to try
Chris: Lucas has moved on to other things, but I hope the BBC people involved will be able to contribute. I'll try to ping them
Jake: Who'd like to get together next week and get started with a browser receiving multicast?
<ghenry> Sounds good.
Jake: I've posted Linux Chromium binaries. I'd like to get it into other browsers though. There are sources linked in the Charter, I can share the link
<jholland> https://
Jake: It takes about 6 or 8 hours to build
<ghenry> What type of machine is that on?
Jake: I have a nightly build that uses the latest Chromium dev version and applies the multicast patch
… So the idea would be to go through the steps to get it set up. There's some publicly available traffic we can use, video streams accessible through relays that Juniper have set up.
… There are resources such as a Python script that sends traffic on your own LAN and receive in the browser
… As we get the authentication set up, we'd get that integrated into the demo
… There's an implementation in AMBI, needs enabling via a flag
… It's a starting point for exploration, so the next meeting would be a walkthrough of getting that running
<krose> If my schedule works out, I'll be there
<krose> I don't think you should schedule around me, however
Jake: I'll go ahead and schedule that
Brett: Between now and then, I'll look at the charter to see what I can contribute
Jake: Some other people have joined the group but aren't here now
<jholland> https://
Jake: Here's the mailing list link: https://
Jake: Thanks everyone for joining. Let's use the mailing list to continue discussion. See you next time!
[adjourned]