Attended:
- Jake Holland
- Casey Russell
- Chris Lenart
- Chris Needham
Recording:
Jake: Thank you for joining. I’ll give an update on what I’ve been doing, then go through some of the important things to move this work forward. I want to enable anyone who wants to contribute. I have a list (see email), and we can look at how we organize
At the last meeting, Sam and Kyle were here. We talked about the BBC QUIC implementation that has multicast transport. I didn’t have time to get that running. Need to know what the achievable offload looks like. I hope to get that done, then return to the standards work next week. Not much progress outside that. We posted the security considerations document to IETF secdispatch, but nobody has responded yet. We got a pre-review offline, saying that we have to get people interested, but the doc looks in good shape for review.
Casey: Current state of internet2 (sp?), I can’t say the final decision, but those who want to participate in multicast transmission to backbone will use an L3 VPN layer, opt-in not automatic. So you’d build some VLANs at layer 3, as opposed to it being native on the existing peering session.
Jake: That makes sense to me. Happy to keep involvement.
Casey: Sounds like Cisco is working on whatever prevents them doing this on their peering sessions, but no timeline for that yet.
Jake (?) are setting up a similar relay system, putting it into i2. They haven’t started on ingest yet.
From the email:
- Standards Efforts
- Soliciting some engagement on security considerations doc: https://datatracker.ietf.org/doc/html/draft-krose-multicast-security
- Can we find people to respond to the secdispatch thread expressing interest? https://mailarchive.ietf.org/arch/msg/secdispatch/LRMHRKiHfk3vgV43KRbG31x-y4I/
- confirming that consensus on this-or-similar along with robust implementation would address feedback from chromium net-dev (recently raised offline as a point of uncertainty): https://groups.google.com/a/chromium.org/g/net-dev/c/TjbMyPKuRHs/m/79PVEJl-GwAJ
- Making progress with quic: https://github.com/bbc/nghq (status: got hung up on my side this month, but progress from others would be welcome also)
- Also an integrated AMBI
- TPAC?
- Ask for half an hour each with Networking Interest group and WebTransport? Anyone else? (Media interest group?)
- Shift November meeting a week early and get on the CG list? https://www.w3.org/wiki/TPAC/2021/GroupMeetings
- Implementation & Deliverables Efforts
- Tests, interesting use cases/demos, API change proposals?
- we previously discussed trying to see if webcodecs can do anything with the vlc traffic from some of the internet2 streams
- I saw a very cool talk from Brett about a chat server--maybe an integration?
- Review/confirmation on the first primer? https://github.com/w3c/multicast-cg/blob/main/primers/01-getting-started.md
- Other primers needed?
- Deployability Efforts
- known stream monitoring & up/down reporting
- tests, refinements, review on connectivity specs (ingest platform & mnat prototype cleanup, more & better IPv6 testing & examples)
Jake: The most urgent of these is probably TPAC. Sudeep sent something in the Web & Networks Interest Group. They’re collecting short video demos to make available as part of TPAC. So putting together a demo could be a good idea.
Demo video message last night:
Chris Needham: W3C will create a showcase of demos, open invitation to all W3C groups if they want to show something
Jake: I could put something together. Does anyone want to be involved in that? It could be a screen recording of a video playing in the Chromium fork, with a pitch to get involved in the group. The video is probably the best demo I have. The video is creative commons, so should show the credits.
Chris Lenart: It would be good if there’s a video of the Chromium fork with something in the background showing the AMT gateway server log, to show something’s happening. I haven’t set up the demo yet. Showing it working would be a huge step.
Jake: It’s a good idea. I usually use iftop, which keeps track of which traffic goes to which addresses. It should fit in two minutes.
Chris Needham: Also show the API part?
Jake: I could point to the API proposal location. There’s a demo page that lets you type in. The video demo is web assembly with hooks for the multicast API. It’s come from our TV delivery system. It could be harder to follow and the code may be confidential.
Jake: The QUIC part is the most important development work, I think. It’s on the critical path to addressing the feedback we got on encryption. I hope to get that moving, but it probably comes behind building engagement.
Jake: The other thing is getting interest expressed on the security considerations document. We brought something to secdispatch a few years ago, on an earlier direction with an authentication stream, where you can refer to other packets in the stream with crypto hashes. draftModadugu2001 Probably still useful for AMBI delivery, but that’s phase 2. At the time, when we took it to secdispatch, a few people expressed interest but not enough. It’s the same this time, we need people to express to IETF to move this forward. It’s a blocker for W3C adoption. The feedback from Chromium net-dev was that we need a consensus position on the security model, as it’s different from TLS. Anything that’s not TLS is tricky from a security point of view.
Jake: It’s not impossible, WebRTC did it. So we based our document on the WebRTC security considerations document. That’s the second most important thing to me. The target timeline is before the November IETF meeting. If we can get some serious thought at IETF 112, getting people to highlight the importance, ISPs, maybe BBC would want to comment here too. Getting the people who stand to gain by having the multicast ability in browsers to comment, demonstrate interest.
Jake: Is anyone interested in doing some hacking? There’s a few things: getting the Chromium build running, trying some of the QUIC work (Sam has offered to answer questions, and is supportive of the idea), doing projects or demos that use the API in the browser. Integrating into the API to tighten up the implementation, which is currently prototype-level. It needs tests and coverage reporting, fuzzing, adding something that can support the API to Web Platform Tests. It’s another hurdle to get over, in addition to the security questions. Also other browsers, if we think Firefox is a good fit too, I’d support having two implementations.
Casey: I’d be willing to spend time, but I’m not a programmer.
Jake: You might be interested in setting up the ingest platform. This would make it so that you can pull traffic from off i2 and forward it from there. It’s wrapped multicast packets in a UDP tunnel. I have a downloader where it puts out an Ubuntu desktop image. You can run a downloader that downloads this large file. Also the web pages that do streaming.
Casey: So I’ll look at the GitHub link and follow up with questions.
Jake: Thank you. There’s one thing with the way i2 runs, but we can work that out. It’s a bit aside from the web API part, but it’s important. It’s a prototype, so long as you’re OK with that.
Jake: Would anyone be willing to express interest on IETF secdispatch, or are there any blockers to doing that?
Chris Needham: I can mention to Sam and Richard.
Jake: It’d be good to get an opinion from them. Chris, how about you? If I can get more interest from networks, it would help convince the security experts.
Chris Lenart: I’m not a security expert, so if it’s more a case of voicing support, it’s something I could do.
Jake: When someone has a security related proposal for IETF work, secdispatch is the entry point for finding a venue.
Chris Lenart: So the gap was authentication and encryption?
Jake: Yes, the document we want to get traction on is about describing how the traffic is different, and how to make it safe for users and operators
Chris Lenart: Related to QUIC over HTTP. QUIC also has mechanisms like this
Jake: The nghq implementation is not sufficient for authentication because it’s a symmetric key. So we’ve separated the two, only talked about authentication so far, so you can verify traffic comes from a specific source. Feedback said to add encryption as well, but this could be weaker than unicast. We need expert review on it, to get to IETF consensus, on the considerations for doing multicast on the web.
Jake: So it’s more a case of expressing interest and saying that security work is needed on it.
Chris Lenart: I’ll follow up with you offline on that.
Jake: I’d like to coordinate several people to do that. Even people without lots of traffic can express support. I can share any resources you need. Anyone else in other organisations? We could plan to make a push during next month.
Chris Lenart: Makes sense. Had a call with Bell Canada.
Jake: Even if you can’t guarantee you’d be deploying it, there’s value in saying you want it to progress, to evaluate. I appreciate your help.
Jake: I’ll share an update next month, if I get anywhere with QUIC. I’ll do the video demo, but the deadline is coming soon. If anyone wants to be involved, let me know.
Chris Needham: Also have a group meeting at TPAC?
Jake: We could ask for a 10 minute slot at Web & Networks and Web Transport.
Chris Needham: It’s an opportunity to bring to a wider W3C audience. A WebTransport meeting could be focused on the integration points.
Jake: Could have our regular meeting a week early, as part of the breakout week. Then the demo could generate interest.
Chris Needham: Let’s follow up.
Jake: Let me know if there’s anything you want to redact from the recording. I’ll share on the private list. See you next month.