├── .gitignore ├── meetings ├── slides-2021-06-23.1-jholland.pdf ├── README.md └── minutes │ ├── minutes-2021-08-04.md │ ├── tpac-2021-agenda.md │ ├── minutes-2021-10-27-tpac-2021-notes.md │ ├── minutes-2021-09-01.md │ ├── minutes-2021-10-06.md │ └── minutes-2021-10-27-tpac.md ├── w3c.json ├── LICENSE.md ├── consensus-transport-protocols.md ├── CONTRIBUTING.md ├── consensus-dependency-specs.md ├── README.md ├── WORK.md ├── primers └── 01-getting-started.md └── multicast-cg-charter.html /.gitignore: -------------------------------------------------------------------------------- 1 | .*.sw? 2 | *~ 3 | -------------------------------------------------------------------------------- /meetings/slides-2021-06-23.1-jholland.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/multicast-cg/HEAD/meetings/slides-2021-06-23.1-jholland.pdf -------------------------------------------------------------------------------- /w3c.json: -------------------------------------------------------------------------------- 1 | { 2 | "group": ["cg/multicast"] 3 | , "contacts": ["dontcallmedom"] 4 | , "repo-type": "cg-report" 5 | } 6 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | All Reports in this Repository are licensed by Contributors 2 | under the 3 | [W3C Software and Document License](https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document). 4 | 5 | Contributions to Specifications are made under the 6 | [W3C CLA](https://www.w3.org/community/about/agreements/cla/). 7 | 8 | Contributions to Test Suites are made under the 9 | [W3C 3-clause BSD License](https://www.w3.org/Consortium/Legal/2008/03-bsd-license.html) 10 | 11 | -------------------------------------------------------------------------------- /consensus-transport-protocols.md: -------------------------------------------------------------------------------- 1 | # Overview 2 | 3 | This is the list of transport protocols recommended for consideration by the Multicast Web Community Group as use cases that might be worth supporting in later-phase work for transport features (as described in the [charter](TBD:URI)). This list should be updated as needed according to group consensus while the Multicast work incubates. 4 | 5 | # Protocols 6 | 7 | - [FLUTE (RFC 6726)](https://datatracker.ietf.org/doc/html/rfc6726) 8 | - [FCAST (RFC 6968)](https://datatracker.ietf.org/doc/html/rfc6968) 9 | - [NORM (RFC 5740)](https://datatracker.ietf.org/doc/html/rfc5740) 10 | - [RTP (RFC 3550)](https://datatracker.ietf.org/doc/html/rfc3550) (with a focus on multicast-based profiles) 11 | 12 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Multicast Community Group 2 | 3 | This repository is being used for work in the W3C [Multicast Community Group](https://www.w3.org/community/multicast/), governed by the [W3C Community License Agreement (CLA)](https://www.w3.org/community/about/agreements/cla/). To make substantive contributions, you must join the CG. 4 | 5 | If you are not the sole contributor to a contribution (pull request), please identify all 6 | contributors in the pull request comment. 7 | 8 | To add a contributor (other than yourself, that's automatic), mark them one per line as follows: 9 | 10 | ``` 11 | +@github_username 12 | ``` 13 | 14 | If you added a contributor by mistake, you can remove them in a comment with: 15 | 16 | ``` 17 | -@github_username 18 | ``` 19 | 20 | If you are making a pull request on behalf of someone else but you had no part in designing the 21 | feature, you can remove yourself with the above syntax. 22 | -------------------------------------------------------------------------------- /consensus-dependency-specs.md: -------------------------------------------------------------------------------- 1 | # Overview 2 | 3 | This is a list of IETF specifications that are considered likely-necessary underpinnings for success on the deliverables of the Multicast Web Community Group, and members of the group are therefore encouraged to review and track their progress. This list should be updated as needed according to group consensus while the Multicast work incubates. 4 | 5 | # Specifications 6 | 7 | - [DORMS](https://datatracker.ietf.org/doc/html/draft-ietf-mboned-dorms) 8 | - [AMBI](https://datatracker.ietf.org/doc/html/draft-ietf-mboned-ambi) 9 | - Possibly [CBACC](https://datatracker.ietf.org/doc/html/draft-ietf-mboned-cbacc) 10 | - Possibly [MNAT](https://datatracker.ietf.org/doc/html/draft-ietf-mboned-mnat) 11 | - At least one multicast-specific web security considerations document ([a likely starting point](https://github.com/squarooticus/draft-krose-multicast-security) is begun, loosely modeled on the [WebRTC Security Considerations (RFC 8826)](https://www.rfc-editor.org/rfc/rfc8826.html)) 12 | 13 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Multicast Community Group 2 | 3 | Repository for the Multicast Community Group 4 | 5 | See also the following resources: 6 | 7 | * [Home Page](https://www.w3.org/community/multicast/) 8 | * [Multicast Community Group Charter](https://w3c.github.io/multicast-cg/multicast-cg-charter.html) 9 | * [Public Mailing List archive](https://lists.w3.org/Archives/Public/public-multicast/) 10 | 11 | With a (free) W3C account login, you can join the community group at [https://www.w3.org/groups/cg/multicast](https://www.w3.org/groups/cg/multicast). 12 | 13 | We have a [recurring meeting](https://lists.w3.org/Archives/Public/public-multicast/2021Jul/0004.html) scheduled for the first Wednesday of the month at 10:30am Eastern time (2:30pm UTC during [US daylight savings](https://www.timeanddate.com/time/change/usa), or 3:30pm UTC during standard time). If you would like to attend except that this time is unfriendly for your time zone, please [open an issue](https://github.com/w3c/multicast-cg/issues) and we will look for a good way to accommodate the request. 14 | 15 | ## Code of Conduct 16 | 17 | The Multicast CG operates under the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/). 18 | -------------------------------------------------------------------------------- /meetings/README.md: -------------------------------------------------------------------------------- 1 | # Meeting Log 2 | 3 | * 2022-09-07: [minutes](https://docs.google.com/document/d/1DoQc49twZk9OZeTJEryI1ZBRAkXIy4Nud6lxgaRMb4E), [video](https://youtu.be/d939HLoIhYs) 4 | * 2022-08-02: [minutes](https://docs.google.com/document/d/1vop1sEctzAGANR6zG37_6QxnUuP-z3R6-LdWXIQ-yfk), [video](https://youtu.be/ShVX7_jacyY) 5 | * 2022-07-06: [minutes](https://docs.google.com/document/d/1aGyLFiaIuwlcvRGueVKsPmpF1EYVAKSJHf8usxfQvoE), [video](https://youtu.be/3EgWETPIx1M) 6 | * 2022-06-01: [minutes](https://docs.google.com/document/d/1eFGd6EU3Uv2Vnqdq2QxlCOhcGKdxwdfIJbMUF3KlVGo), [video](https://youtu.be/0FIfsH6DgX8) 7 | * 2022-05-04: [minutes](https://docs.google.com/document/d/1eoGvNcbh26wUPEGZOHJWzd4Y1gKZIAUx3_0NWaghNwg), [video](https://youtu.be/ctHGeIU_WkU) 8 | * 2022-04-06: [minutes](https://docs.google.com/document/d/1MMvQuMfDtcj_cRVPWDnVUMNKWhcmF9um3WsUXK5EC3E), [video](https://www.youtube.com/watch?v=YMgTnplh6S8) 9 | * 2022-03-02: [minutes](https://docs.google.com/document/d/1dcvvcHm59bqO5QWP-sfjclW6HhdPQt9L9g0UNJfUKR8/), [video](https://www.youtube.com/watch?v=Kc3an8kUfK0) 10 | * (2022 February meeting cancelled, [announcement](https://lists.w3.org/Archives/Public/public-multicast/2022Feb/0000.html)) 11 | * 2022-01-07: [minutes](https://docs.google.com/document/d/1hhtgQVjy73FTWP4AIZA_F3C2Pkqtc0Sy_NG2ebwy-fU), [video](https://www.youtube.com/watch?v=StMuMXMRYxQ) 12 | * 2021-12-01: [minutes](https://www.w3.org/2021/12/01-multicast-minutes.html)/[minutes-raw](minutes/minutes-2021-12-01.md), [video](https://youtu.be/nVUO28amBT4) 13 | * 2021-10-27 (TPAC 2021): [minutes](https://www.w3.org/2021/10/27-multicast-minutes.html) (or the [captured text](minutes/minutes-2021-10-27-tpac.md) in case of availability issues), [video](https://www.youtube.com/watch?v=VV4gbOczhkU), [slides](https://docs.google.com/presentation/d/1YAFs3Pif0o2e3hLdFbEnpm0iAC8NBPXuDBZKi2FTO6A) 14 | * 2021-10-06: [minutes](minutes/minutes-2021-10-06.md), [video](https://youtu.be/ukm0bzwDEno) 15 | * 2021-09-01: [minutes](minutes/minutes-2021-09-01.md), [video](https://youtu.be/mTAtgUrPbt4) 16 | * 2021-08-04: [minutes](minutes/minutes-2021-08-04.md) 17 | * 2021-06-23: [minutes](https://www.w3.org/2021/06/23-multicast-minutes.html), [Jake's slides](slides-2021-06-23.1-jholland.pdf) 18 | 19 | -------------------------------------------------------------------------------- /meetings/minutes/minutes-2021-08-04.md: -------------------------------------------------------------------------------- 1 | I forgot to record the session, but I captured a few notes from the 2 | meeting. 3 | 4 | Attendees: 5 | 6 | - Jake Holland 7 | - Kyle Rose 8 | - Sam Hurst 9 | 10 | (Brett Sheffield also sent apologies offline, and hopes to make it 11 | next time.) 12 | 13 | Agenda: 14 | 15 | * Welcome & Agenda-bash 16 | * Questions/comments on recent IETF 111 and upcoming TPAC 17 | * Discuss using QUIC and libnghq to solve the packet level encryption problem 18 | 5 minutes: Schedule working session in 1-2 weeks for those 19 | who are interested. 20 | 21 | Recommended reading: 22 | 23 | * https://github.com/bbc/nghq/blob/master/docs/public-api.md 24 | * https://datatracker.ietf.org/doc/html/draft-pardue-quic-http-mcast 25 | I've got a couple of points of confusion here that I'm hoping 26 | to clear up by digging on it over the next week or 2, and 27 | anyone who can help shed light here will be invited to do so. 28 | 29 | After a brief "no particular questions or comments" about the IETF 30 | meetings, we dove into details on the QUIC/nhgq implementation 31 | questions. 32 | 33 | Notable clarifications we covered included: 34 | 35 | - the unidirectional streams don't need session establishment or alpn 36 | - but it does need to get the push promises or it might throw things 37 | away. (Sam mentioned some unimplemented thoughts toward repeating 38 | the push promise later to cover losses/late starts better, and the 39 | same with headers) 40 | - unicast recovery is (optionally) done at the app layer, not built 41 | into the library 42 | - there's not a built-in concept of coupling between multicast and 43 | unicast streams, though there's ways to set the connection and 44 | session ids in the library and that might be a path to having one 45 | - Sam explained that in DVB they've been aiming to support a satellite 46 | broadcast use case with no return path, so some of the design on the 47 | library has aimed toward that. 48 | - There's not datagram support implemented now 49 | - I mentioned I was thinking datagram support would be a useful way 50 | to do a transparent port of existing UDP multicast apps, so I'd 51 | probably want to get that working. 52 | 53 | The rough plan over the next couple of weeks is: 54 | 55 | - bring up the example sender & receiver as-is 56 | - make it use some encryption (the example just uses memcpy and passes 57 | the data in the clear in the encrypt/decrypt callbacks) 58 | - try to get it running with the browser 59 | - this likely needs some browser API changes, where things will 60 | maybe get interesting, but as a starting point try to make the 61 | object payloads arrive at the app via the ReadableStream and 62 | 63 | We did not schedule a working session, but might do so later as part 64 | of step 3 of that plan. 65 | 66 | Kyle had a late agenda-bash with draft-krose-multicast-security. We 67 | decided "as soon as practical" was the best time to raise it on 68 | secdispatch, so he's going to kick that off after a few changes he 69 | has pending, with Friday as the target. 70 | 71 | We did not touch on the TPAC question, I expect we'll do that next 72 | time instead. 73 | 74 | -------------------------------------------------------------------------------- /meetings/minutes/tpac-2021-agenda.md: -------------------------------------------------------------------------------- 1 | 2 | # Proposed Agenda 3 | 4 | 1. Welcome, Agenda-bash (~5 mins) 5 | 2. Intro to Multicast-CG (15 mins) 6 | 3. Next Steps: discuss briefly & schedule working sessions (25 mins) 7 | 1. QUIC with multicast (https://datatracker.ietf.org/doc/html/draft-pardue-quic-http-mcast) 8 | 1. Get basic functionality demo running (no browser) with 9 | 2. Also look into the latest [webtransport implementation](https://github.com/web-platform-tests/wpt/tree/master/tools/webtransport/h3), which has datagrams. See about hacking in multicast like nghq did? 10 | 3. Once something works, get it running in browser. 11 | 1. datagrams+webtransport better match to existing api? nghq's object approach better match for xhr, I think. Any others? 12 | 4. Look into addding AMBI to quic-http-mcast () 13 | 2. Anyone know anyone willing who hasn't chimed in on IETEF secdispatch support for work on ? 14 | 3. IETF hackathon to play VLC mcast streams from internet2 in browser demo. Thread: 15 | 1. This can anchor the datagrams use case and carry forward if we can get it working. 16 | 4. Wrap-up & Summary (5 mins) 17 | 18 | # Logistics 19 | 20 | Please note: 21 | 22 | 1. This meeting will be recorded if nobody withholds consent, as covered by the latest draft process guidelines:\ 23 | 24 | 25 | The purpose of recording is to aid with minutes, enable later review of comments, and to help future new or prospective group members get oriented. The video will be posted to Youtube and made publicly available without an expiration. However, if requested by recorded participants, sections of the public recording will be redacted to their satisfaction as needed, before or after publication (though after publication of course there may be copies outside our control). A link to the recording will be kept in the meeting log here (and updated if replaced with a redacted recording): 26 | 27 | 28 | 2. This is a W3C Community Group meeting, so it's to operate under 29 | the W3C Code of Ethics and Professional Conduct: 30 | 31 | 32 | # Coordinates 33 | 34 | 1. Meeting link should work for most (webex client install if missing):\ 35 | 36 | 37 | Otherwise, should let you put in the meeting number and password: 38 | 39 | * Meeting number: 2598 001 6648 40 | * Password: yay-multicast! 41 | 42 | 2. Join by phone: 43 | 44 | * 1-408-792-6300 Call-in number (US/Canada) 45 | * 1-877-668-4490 Call-in toll-free number (US/Canada) 46 | 47 | 3. Join by video system: 48 | 49 | * Dial 25980016648@akamai.webex.com 50 | * Access code: 2598 001 6648 51 | 52 | Global call-in numbers: 53 | 54 | Toll-free calling restrictions: 55 | 56 | 57 | -------------------------------------------------------------------------------- /WORK.md: -------------------------------------------------------------------------------- 1 | # Overview 2 | 3 | This doc lists work items believed to be in scope for the multicast community group. 4 | 5 | # Docs targeting normative consensus 6 | 7 | ## W3C 8 | 9 | To be authored by this group, targeting adoption by a WG for development as a standard: 10 | 11 | * WebTransport Extension:\ 12 | Formal proposal for a suitable API extension to WebTransport 13 | 14 | ## IETF 15 | 16 | Known high-priority dependencies for this group's scope: 17 | 18 | * [Multicast Security Considerations](https://github.com/squarooticus/draft-krose-multicast-security) 19 | * [AMBI](https://datatracker.ietf.org/doc/html/draft-ietf-mboned-ambi) 20 | 21 | See also: 22 | 23 | * [DORMS](https://datatracker.ietf.org/doc/html/draft-ietf-mboned-dorms) (AMBI dependency) 24 | * [CBACC](https://datatracker.ietf.org/doc/html/draft-ietf-mboned-cbacc) (may be required for certain threat models) 25 | * [MNAT](https://datatracker.ietf.org/doc/html/draft-ietf-mboned-mnat) (may be required for certain networks) 26 | 27 | Possibly important items for consideration: 28 | 29 | * A new DNS RRType to provide a multicast channel via domain name, instead of IP pair. 30 | * URL-based generic multicast streams? (see expired [draft-singer-appsawg-mcast-url](https://datatracker.ietf.org/doc/html/draft-singer-appsawg-mcast-url)) 31 | * perhaps a new url scheme to indicate secured multicast channel? 32 | 33 | # Implementation & Test 34 | 35 | ## API/API components 36 | 37 | * [chromium demo implementation](https://github.com/GrumpyOldTroll/chromium_fork) 38 | * Needs authentication ([AMBI](https://datatracker.ietf.org/doc/draft-ietf-mboned-ambi/)) 39 | * Probably needs batched payload transfer (or more generally a performance pass) 40 | * Needs automated tests in the build process 41 | * with coverage reports 42 | * with fuzzing 43 | * May need MNAT support 44 | * [libmcrx](https://github.com/GrumpyOldTroll/libmcrx) (used by chromium implementation) 45 | * Needs implementations for: 46 | * Windows 47 | * Android 48 | * IOS 49 | * Needs packaging for distros 50 | * Needs test suite with coverage checking 51 | * Port to more browsers besides Chromium: 52 | * Firefox at least. (libmcrx wrapper for rust or separate implementation?) 53 | * Others as volunteers are willing 54 | * WPT test suite 55 | 56 | ## Sample Apps 57 | 58 | * [Demo page](https://htmlpreview.github.io/?https://github.com/GrumpyOldTroll/wicg-multicast-receiver-api/blob/master/demo-multicast-receive-api.html) ([source](https://github.com/GrumpyOldTroll/wicg-multicast-receiver-api/blob/master/demo-multicast-receive-api.html)) 59 | 60 | # Non-normative Documents 61 | 62 | * [Explainer](https://github.com/GrumpyOldTroll/wicg-multicast-receiver-api/blob/master/explainer.md) 63 | 64 | ## Tutorials/primers 65 | 66 | * Getting Started:\ 67 | how to receive multicast traffic in a lab web browser, the better to experiment with 68 | * Building:\ 69 | how to build a browser that can receive multicast 70 | * Example app:\ 71 | an app that does something useful 72 | 73 | ## Useful resources 74 | 75 | * Evangelization/enabling docs 76 | * Case studies 77 | * ROI/cost analyses 78 | * Efficiency/savings modeling 79 | * Notes about devices 80 | * Gotchas encountered (with model & version, ideally) 81 | * Confirmed-good reports (with sample configs, ideally) 82 | * Vendor statements 83 | 84 | -------------------------------------------------------------------------------- /meetings/minutes/minutes-2021-10-27-tpac-2021-notes.md: -------------------------------------------------------------------------------- 1 | Video: https://www.youtube.com/watch?v=VV4gbOczhkU 2 | Slides: https://docs.google.com/presentation/d/1YAFs3Pif0o2e3hLdFbEnpm0iAC8NBPXuDBZKi2FTO6A/edit 3 | 4 | Present: 5 | 6 | Discussion 1: 11m50s 7 | Eric: - sustainability +1 8 | - suggestion: get the same metric estimate value for video game downloads and video (instead of % of total carbon footprint for 1 vs. tonnes for the other) 9 | - it'd be good to educate the stakeholders on how much impact multicast would have 10 | - jake: did some of this with ISPs especially, gave them some data about offloadability for them. Peak traffic especially interesting to the ISPs we spoke to (user experience angle), but energy usage savings likely come heavily from average/day-to-day usage. 11 | 12 | 13 | Discussion 2: (24m) 14 | - how active are the browser vendors in IETF work so far? 15 | - jake: not very. Ekr from Mozilla responded but was somewhat negative. In general browsers not yet interested. 16 | - Amazon involved? 17 | - jake: not at IETF. Amazon did call to ask about multicast due to NFL TNF deal over next 10 years. They are examining options. We don't have a production implementation yet, but they are looking for a way to start next year. They're supportive of the standards work, they may or may not be able to use it on the early side. Also had conversations with some at Google, not everyone there is convinced. A few have have privately expressed support, but have not publicly engaged. Lots of people start out skeptical on multicas--ASM was a big false start that got a lot of burned fingers. However, this means it's already widely deployed for some purposes and is in active use in many networks, but not for global interdomain traffic. 18 | - Eric: first task for CG is to articulate pain points and business prop for stakeholders. CG should be engaging them and gaining support. Youtube would be a natural supporter, Amazon as well. Need to get them to feel the pain points and get them interested in this, and the other one is how to get the Chrome people comfortable with the security story 19 | - jake: there's a chicken and egg problem here. If the technical capability is actually executable, this raises interest level. The slideware demos are unconvincing, especially given multicast history. 20 | - Eric: can you get the ISPs involved here? 21 | - jake: a few have joined the group, mostly haven't really dug in yet. Some are members, but are only tangentially interested in the browser work, they just want it to be there. I'd love to have a big-picture plan in place that works well. The multicast-cg is about getting the browser in shape, but some of this has to happen outside standards bodies. 22 | - Eric: It's a good point, the business people have to drive the standards. My big concern here is that business won't adopt, that has to be the immediate challenge to address. The benefits are quite obvious, but how do we as a group rally the ecosystem around it? 23 | - jake: this is why I was engaging with demos, and why my next steps are getting the demos closer to releasable. Having a browser fork that does something useful is to me one of the key next steps to make the case that we can do something real here that people will believe. And a key piece of that is the browser tech side, particularly the security. It has to be a credible proposal for the browser people to pay attention. Right now, yes it can play video but not in a way that can be accepted into browsers, and if we can get it to where it could be, with growing consensus that it's workable, that would make it more likely for browsers to become interested. But you're right, this is just a hope, and we're missing the buy-in we need, even from people who have a lot to gain here. Our analysis says there's a lot of money to be saved here, we think the low interest is because people don't think it's credible until they spend effort looking at it for real, but not sure. 24 | - Dominique: interesting challenge to coordinate the challenges. Part o the conversation that might be needed would be bound to the timeline. What's your best guess on the time needed to align the stars? Like the demo, how long before the browser is operational, and then how long to go door to door and convince people? 25 | - jake: you probably shouldn't trust my estimate. I thought I had a demo running, so I thought I'd be done by now. 26 | - dom: so what I'm hearing is that in your plan, the security obstacle is a key one to lift to give confidence we can build momentum across stakeholders--once you have something you can convince a browser to ship, then you have something you can convince at least one ISP and one content owner to use, and then you'd build steam 27 | - jake: basically, yes. There's a few other rays of hope, for instance geant and internet2 have some interdomain multicast delivery today, and on both their timelines are deploying some ingest platform instances to pull in multicast and distribute it, which is a big part of what the ISP lab tests were doing. There's several moving parts here, some of which are outside the w3c charter, but are critical to the ultimate success here. So in this CG, I was hoping to move forward the receiver distribution side of this story, but I do encourage people to engage in IETF as well. 28 | - Gang: question: customers want this if it's transparent. In DVB, they do this thru an mpeg-dash player, and they don't seem to have the same complex security model problem. Here we seem to need to manage the source and the encryption on each multicast stream. Can we do this on the server side instead in an edge server? Won't this help with the last mile bandwidth issue? If we do it from the edge server doesn't it simplify the security problem? 29 | - Jake: If you're making use of the broadcast capability at the edge that way, you're trusting the edge servers. There's been a history of abuses like ad-theft, when you send stuff an ISP can change on the way. That's actually the way it works today in the broadcast tv world because you can't get the scale, but there's a gap on security considerations for doing this transparently. The current proposal addresses this with AMBI, which makes it impossible to do unauthenticated injection in a way not done with the handoff model. The idea that the broadcast part happens inside the walled-gardens is possible to make some of this happen, but then you have new problems, which is that each use case needs a separate set of specs. If you standardize on video, you won't get VR or downloads. It's possible to do it separately for those, but then you still have trouble--4g had this capability and nobody used it, the northbound interfaces were challenging. 30 | - Gang: yes, but there's an incentive for the ISP to make a change since it'll save them bandwidth. It's easier to make the change from the ISP position 31 | - jake: I think the way we've proposed is the easier way for the ISP, they don't have content to manage that they have to be the source of, and own the send/receive and the protocols those use. But yes, this is one of the big design questions, should it be only the end isp is the one that can broadcast and you have to give it to them as an object they can unpack and distribute, or is there a way to do this as opaque multicast packets they can just stream through? People have different opinions, mine is that we should do packet streaming. Most of the ISPs we've talked to tend to prefer this moel because they don't have as much to maintain, because they can focus on deelivring packets, without having to maintain user applications, and things that work with some content but not others, they can just standardize on ip transport, which brings it closer to the way http works. But yes, great question, and opinions sometimes differ. 32 | 33 | 34 | 35 | -------------------------------------------------------------------------------- /meetings/minutes/minutes-2021-09-01.md: -------------------------------------------------------------------------------- 1 | Attended: 2 | 3 | - Jake Holland 4 | - Casey Russell 5 | - Chris Lenart 6 | - Chris Needham 7 | 8 | Recording: 9 | 10 | - 11 | 12 | # Introduction 13 | 14 | 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 15 | 16 | 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. 17 | 18 | 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. 19 | 20 | Jake: That makes sense to me. Happy to keep involvement. 21 | 22 | Casey: Sounds like Cisco is working on whatever prevents them doing this on their peering sessions, but no timeline for that yet. 23 | 24 | Jake (?) are setting up a similar relay system, putting it into i2. They haven’t started on ingest yet. 25 | 26 | # Timelines 27 | 28 | From the email: 29 | 30 | - Standards Efforts 31 | - Soliciting some engagement on security considerations doc: 32 | https://datatracker.ietf.org/doc/html/draft-krose-multicast-security 33 | - Can we find people to respond to the secdispatch thread expressing 34 | interest? 35 | https://mailarchive.ietf.org/arch/msg/secdispatch/LRMHRKiHfk3vgV43KRbG31x-y4I/ 36 | - confirming that consensus on this-or-similar along with robust implementation 37 | would address feedback from chromium net-dev (recently raised offline as a 38 | point of uncertainty): 39 | https://groups.google.com/a/chromium.org/g/net-dev/c/TjbMyPKuRHs/m/79PVEJl-GwAJ 40 | - Making progress with quic: 41 | https://github.com/bbc/nghq 42 | (status: got hung up on my side this month, but progress from others 43 | would be welcome also) 44 | - Also an integrated AMBI 45 | - TPAC? 46 | - Ask for half an hour each with Networking Interest group and WebTransport? 47 | Anyone else? (Media interest group?) 48 | - Shift November meeting a week early and get on the CG list? 49 | https://www.w3.org/wiki/TPAC/2021/GroupMeetings 50 | - Implementation & Deliverables Efforts 51 | - Tests, interesting use cases/demos, API change proposals? 52 | - we previously discussed trying to see if webcodecs can do anything with 53 | the vlc traffic from some of the internet2 streams 54 | - I saw a very cool talk from Brett about a chat server--maybe an integration? 55 | - Review/confirmation on the first primer? 56 | https://github.com/w3c/multicast-cg/blob/main/primers/01-getting-started.md 57 | - Other primers needed? 58 | - Deployability Efforts 59 | - known stream monitoring & up/down reporting 60 | - tests, refinements, review on connectivity specs (ingest platform & mnat 61 | prototype cleanup, more & better IPv6 testing & examples) 62 | 63 | # W3C TPAC Demo 64 | 65 | 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. 66 | 67 | Demo video message last night: 68 | 69 | - 70 | 71 | Chris Needham: W3C will create a showcase of demos, open invitation to all W3C groups if they want to show something 72 | 73 | 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. 74 | 75 | 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. 76 | 77 | 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. 78 | 79 | Chris Needham: Also show the API part? 80 | 81 | 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. 82 | 83 | 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. 84 | 85 | 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. [draft](https://datatracker.ietf.org/doc/html/draft-krose-mboned-alta-01)[Modadugu2001](https://crypto.stanford.edu/~pgolle/papers/auth.pdf) 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. 86 | 87 | 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. 88 | 89 | 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. 90 | 91 | Casey: I’d be willing to spend time, but I’m not a programmer. 92 | 93 | 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. 94 | 95 | * 96 | 97 | Casey: So I’ll look at the GitHub link and follow up with questions. 98 | 99 | 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. 100 | 101 | # IETF secdispatch 102 | 103 | Jake: Would anyone be willing to express interest on IETF secdispatch, or are there any blockers to doing that? 104 | 105 | Chris Needham: I can mention to Sam and Richard. 106 | 107 | 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. 108 | 109 | Chris Lenart: I’m not a security expert, so if it’s more a case of voicing support, it’s something I could do. 110 | 111 | Jake: When someone has a security related proposal for IETF work, secdispatch is the entry point for finding a venue. 112 | 113 | Chris Lenart: So the gap was authentication and encryption? 114 | 115 | 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 116 | 117 | Chris Lenart: Related to QUIC over HTTP. QUIC also has mechanisms like this 118 | 119 | 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. 120 | 121 | Jake: So it’s more a case of expressing interest and saying that security work is needed on it. 122 | 123 | Chris Lenart: I’ll follow up with you offline on that. 124 | 125 | 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. 126 | 127 | Chris Lenart: Makes sense. Had a call with Bell Canada. 128 | 129 | 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. 130 | 131 | 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. 132 | 133 | # W3C TPAC Meeting 134 | 135 | Chris Needham: Also have a group meeting at TPAC? 136 | 137 | Jake: We could ask for a 10 minute slot at Web & Networks and Web Transport. 138 | 139 | Chris Needham: It’s an opportunity to bring to a wider W3C audience. A WebTransport meeting could be focused on the integration points. 140 | 141 | Jake: Could have our regular meeting a week early, as part of the breakout week. Then the demo could generate interest. 142 | 143 | Chris Needham: Let’s follow up. 144 | 145 | 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. 146 | 147 | 148 | -------------------------------------------------------------------------------- /meetings/minutes/minutes-2021-10-06.md: -------------------------------------------------------------------------------- 1 | Present: Brett Sheffield, Chris Needham, Jake Holland, Kyle Rose, Michiel De Backker, Sam Hurst 2 | 3 | Chair: Jake 4 | 5 | Scribe: Chris 6 | 7 | Topic: TPAC plans 8 | 9 | Jake: We have a scheduled slot, hoping to get some new people to join. Not sure what to expect. Ideal would be line up some development work to experiment with the QUIC library. I haven't had time to do that so far. The demo video is up: https://www.w3.org/2021/10/TPAC/demos/multicast.html. I'll give intro, then go into the ongoing work, things we need to solve to integrate into browsers, on security. 10 | 11 | Chris: Anyone we'd specifically want to try to bring in? 12 | 13 | Jake: Harald Alvestrand has been supportive of the work, and has experience with WebRTC. A few people at the last IETF BAR BOF, not sure how much overlap with W3C members though. I'd like to get more people who can help with the browser integration questions to give feedback. 14 | 15 | Chris: Probably the same people as on the blink-dev email thread 16 | 17 | Jake: Anyone from Chrome or Firefox who can help describe potential obstacles 18 | 19 | Brett: Who's working on it at the moment? 20 | 21 | Jake: There have been people involved at Akamai from time to time, but right now I'm the only one. 22 | 23 | Brett: We've had people say they're keeping an eye on it, but not getting involved in development. In terms of feedback from other people outside Akamai? 24 | 25 | Jake: Some from IETF, at the BAR BOF, about 26 people. People were supportive, but not writing code. 26 | 27 | Topic: IPv6 28 | 29 | Brett: I'm quite enthusiastic. There's some overlap between my work and yours, on IPv6, multicast and transitional tunneling. I had a chat app using WebSockets with multicast in the background. Maybe we can do something with that. 30 | 31 | Jake: On IPv6, ?? asked for this recently. They're setting up AMT relays and peer forwarding in their network. There's an IETF hackathon upcoming, early November. 32 | 33 | Brett: Is that IPv4 only? 34 | 35 | Jake: I believe it supports both v4 and v6. The gateway and AMT relay. I added IPv6 support a few years back, and it worked fine. I don't have any relays running yet, it's on the list. I was hoping to set one up for you to send VLC traffic. It's a useful test. The next step would be to render in a browser. It should in principle be similar to what WebCodecs does. How it handles missing packets is a question. Building that is an aim for the hackathon. 36 | 37 | Jake: I also have what's shown in the demo video. A port of a TV receiver to WASM, running in the browser. That's a reliable transport, rebuilding the segments from the multicast data. They checksum checked before feeding them in, and there's a unicast fallback. The code isn't public though. 38 | 39 | Jake: When we get to the QUIC implementation, that will be similar. There's a reliable transport that rebuilds segments after receiving over multicast, then play with MSE. It could be inside the XHR rather than WebTransport, where you'd have a ReadableStream. That's a different path in the implementation. I'd like to get it so that datagrams go through a ReadableStream path that could be used in WebTransport. 40 | 41 | Sam: There's no datagram support in that yet. 42 | 43 | Jake: It might not be hard to add v6 support. If I manage to get a v6 relay up, I'll share an update. 44 | 45 | Brett: Our approach with Librecast is v6 only, which uses tunneling. If there's only v4 multicast we'd still tunnel to get v6 going. Some of the things we're doing require v6 such as 112 bits for group addresses. 46 | 47 | Jake: In SSM I think you have only 31 bits. 48 | 49 | Brett: You lose some bits if you're embedding the address there. 50 | 51 | Jake: The part assigned to SSM is /96 with the top bit reserved 52 | 53 | Brett: Some later RFC use more bits. 54 | 55 | Jake: I'll find a reference - IANA considerations in RFC 4607. 56 | 57 | Jake: We're doing SSM as ASM has been deprecated for interdomain multicast (RFC 8815)? 58 | 59 | Brett: It's an acknowledgement that ASM doesn't work for inter-domain. 60 | 61 | Jake: Would you use a v4 tunnel? 62 | 63 | Brett: The multicast we use is v6 only, so if only v4 is available we'd tunnel. ipv4 unicast is sufficient 64 | 65 | Jake: Let's follow-up offline. We do want v6 to work in the browser. 66 | 67 | Topic: TPAC meetings 68 | 69 | JakeL Not sure if we'll get a slot in WebTransport WG. We have an hour in Second Screen. Not sure 70 | 71 | Chris: They're focused on discoveery on a local network. Potential collaborations with them? 72 | 73 | Jake: Interested in the privacy issues. Privacy exposure footprint to the local network. Is there a threat model to exposing information on the local network. 74 | 75 | https://github.com/w3c/secondscreen-wg/issues/3#issuecomment-935156371 76 | 77 | Raised in the net-dev threat that there's different privacy aspect than with TLS, so the exposure footprint is an area of concern, and questions about how usable it may be. 78 | 79 | The other issue to dicuss is the discovery of a join to the local network. The last-hop router will know where its routing streams. Exposure from discovery protocols on the network. 80 | 81 | Brett: Didn't Apple have something recently about blocking multicast from apps, to prevent fingerprinting on the local network? 82 | 83 | Jake: Yes, saw that. I think it might be helpful to the security story. On those platforms, there's a mechanism to switch it off if there's abuse. Well-behaved developers register the purpose of their usage. If they misbehave, their app can be prevented from using the capability. It's not necessarily a full solution, but it helps address some concern. Untrusted apps could be blocked by the OS. 84 | 85 | Chris: The Open Screen Protocol design was careful to avoid not exposing information, and decisions made on what information to share during disovery and after authentication. Could be valuable to learn from their approach. 86 | 87 | Jake: I can imagine someone wants to subscribe to the same multicast stream from mutliple screens for synchronized playback. If that's the intent, multicast has some restrictios over WiFi, RFC 9119, soon to be published. Links in the GitHub comment. If anyone does have that in mind, not sure of the strategy for handling Wifi constraints. 88 | 89 | Jake: Could make sense if there's lots of devices on the network. Could do with wired. 50 screens all showing the same thing could usefully be subscribed to the same multicast stream, even on Wifi 90 | 91 | Jake: I'm hoping to get some of the Second Screen group members interested. 92 | 93 | Michiel: They're publishing to browsers, are you also thinking of publishing from the browser? 94 | 95 | Jake: So far it's receive only. Don't want to rule it out. Could be possible to subscribe to the same multicast stream from the outside, but you probably won't get gains if it's over Wifi. If it's on a wired network or potentially a cell network, it could be worthwhile. 96 | 97 | Jake: It's why UDP sockets were turned off, web pages could use for a DDoS attack. Needs rate controls with some feedback channel. There's although authentication that's hard to do 98 | 99 | Kyle: I can imagine a case in future where someone wants to use mutlicast to do user-to-user video conferencing. You'd be sending to a multicast group. There could be a case for allowing UDP packets to be sent to a multicast group address only, but needs protection. For SSM, need to ensure you can't spoof a source address. You don't want someone's browser to be able to inject packets into someone else's multicast. So there could be some cases that could be made safe, but receive only is reasonable for now. 100 | 101 | Jake: That would be beyond the browser's capability, I think. Not doing outbound mutlicast here. 102 | 103 | Brett: Allowing unicast outbound UDP is quite a risk, but outbound mutlicast UDP isnt' a smilar risk. Could be dropped by the router, can't do an amplification attack. Are we protecting against a threat that's not there? If TTL1 was necessary, we wouldn't be here now. Read-only works well if you're only thinking about video streaming. But for a chat application over multicast, you need to read and write. 104 | 105 | Kyle: That's what I was thinking of. Send stream to everyone watching, rather than the hub and spoke model 106 | 107 | Michiel: Ad networks could create shadow networks on your LAN for fingerprinting. Gets hairy quickly. Jake's probably right to keep to read only for now to avoid those concerns. 108 | 109 | Kyle: I agree, just saying "never say never". 110 | 111 | Jake: That's right, but it's not our focus. 112 | 113 | Michiel: I try to generalise with what the second screen is doing. I suggested that to the WICG on that: https://discourse.wicg.io/t/idea-local-devices-api-lan-services/5056 114 | 115 | Topic: Hackathon 116 | 117 | Jake: We could try receiving VLC, pass to WebCodecs. Has anyone done that before? 118 | 119 | Kyle: What's the structure of the hackathon? 120 | 121 | Jake: It's similar to before, but remote. A champion registers it in the wiki page, notifies IETF. It's the week before the meeting. Can structure it how you want in the group. There are lightning talks to share what you did. 122 | 123 | Jake: I'll send an update on that. It might be relevant use case for datagrams more than the QUIC work. The vision there is exising multicast capable things like VLC, and put something in the front, encode UDP packets, within certain constraints. You can turn that into a QUIC UDP datagram, build the hash, send to AMBI, send to browser and unpack and handle. From the browser point of view, it'll look the same as a raw UDP payload, with the QUIC part built around it. It opens the door to things that already exist. For performance, eed to batch datagrams when delivering to the API, and avoid copying. The demo currently uses a lot of CPU. 124 | 125 | Michiel: Currently the JS API uses ReadableStream. Are you also thinking about direct handover to media APIs, such as painting to a canvas or a video element? I'd advocate for both. 126 | 127 | Jake: Good suggestion, which also came up in the net-dev thread. Our charter says we'd look at that. Targeted APIs would be fine, but we're aiming at WebTransport first. With MSE, as long as you're building sem 128 | 129 | Chris: WebCodecs for MSE is coming, so you could have multicast reception, decode using WebCodecs, pass to MSE for buffered playback. 130 | 131 | Jake: Seems useful too, opens it up to streaming. I'd like to avoid cutting things out like chat, so want to still keep transport of HTTP objects for that use case. Datagrams is also handy. If MSE accepts a WebCodecs input, that might make. 132 | 133 | Jake: How does WebCodecs handle unreliable transport? 134 | 135 | Chris: I haven't tried using it, so don't know. 136 | 137 | Michiel: May want to talk to WebRTC about it, as SRTP handles that. 138 | 139 | Jake: Thank you. 140 | 141 | [Adjourned] 142 | -------------------------------------------------------------------------------- /primers/01-getting-started.md: -------------------------------------------------------------------------------- 1 | # Overview 2 | 3 | This is a walkthrough for how to get started with receiving multicast traffic in a web app. 4 | 5 | # Implementations 6 | 7 | In 2021-06 there's only 1 implementtion yet, which is a demo fork of chromium that does not yet have the security model implementation. 8 | 9 | ## How to Install 10 | 11 | The latest binary .deb installer (from a patch applied to a recent chromium stable build) can be downloaded from the top link here: 12 | 13 | * [CURRENT_BINARIES.stable.md](https://github.com/GrumpyOldTroll/chromium_fork/blob/main/CURRENT_BINARIES.stable.md) 14 | 15 | ~~~ 16 | URL=$(curl https://raw.githubusercontent.com/GrumpyOldTroll/chromium_fork/main/CURRENT_BINARIES.stable.md | grep https | head -n 1 | cut -f3 -d " ") 17 | curl -O ${URL} 18 | sudo apt install ./$(basename ${URL}) 19 | ~~~ 20 | 21 | To remove it later: 22 | 23 | ~~~ 24 | sudo apt remove chromium-browser-mc-unstable 25 | ~~~ 26 | 27 | ## How to Build (optional) 28 | 29 | If you want to build the installer yourself instead of downloading the binary. You need plenty of RAM and disk space (at least ~8 and ~100 GB respectively in 2021-06, but it may grow). It takes something like 10 hours. 30 | 31 | ### Ubuntu/Debian 32 | 33 | (tested on Ubuntu 18.04 and 20.04) 34 | 35 | ~~~ 36 | sudo apt-get install -y docker.io screen snapd git python3 python-is-python3 37 | sudo snap install jq 38 | git clone https://github.com/GrumpyOldTroll/chromium_fork/ 39 | sudo usermod -aG docker ubuntu 40 | # log out and back in 41 | CHAN=stable 42 | VER=$(curl -s -q -f https://raw.githubusercontent.com/GrumpyOldTroll/chromium_fork/main/LAST_GOOD.${CHAN}.sh | grep LAST_GOOD_TAG | cut -f2 -d=) 43 | cd chromium_fork 44 | CHAN=${CHAN} VER=${VER} ./nightly.sh 45 | ~~~ 46 | 47 | ### Cloud build (AWS) 48 | 49 | Also possible is building on a cloud device. (NB: This can't be done on free tier, the machines don't have enough ram, and the disk space also needs to be bigger.) 50 | 51 | These will all try to pick decent defaults, but if you don't have a key pair in the default region (us-west-1) or the first key-pair isn't the one you've got loaded with ssh-add it won't work if nothing is set explicitly, so you may need to set one or more variables: 52 | 53 | Most likely to be necessary: 54 | 55 | * [REGION](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RegionsAndAvailabilityZones.html#Concepts.RegionsAndAvailabilityZones.Regions) (AWS region) 56 | * [KEYPAIR](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) (keypair for connecting to the instance) 57 | 58 | If you have a preference or you're aiming for something specific, several others are possible, for instance: 59 | 60 | * [INSTTYPE](https://aws.amazon.com/ec2/instance-types/) (the instance type) 61 | * [AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/finding-an-ami.html) (image id). NB: the same release in different regions is a different id 62 | * CHAN: stable or dev 63 | * VER: version (recommended: LAST_GOOD_TAG from the [fork](https://github.com/GrumpyOldTroll/chromium_fork/blob/main/LAST_GOOD.stable.sh)) 64 | 65 | Also setting 'KEEP' to anything besides 0 will keep the instance alive afterwards (this will have [extra costs](https://aws.amazon.com/ec2/pricing/on-demand/) and you'll need to manually clean it up). 66 | 67 | Note also that manual cleanup may be needed if anything goes wrong. This should make a single instance of INSTTYPE (default=c5.2xlarge) in REGION (default=us-west-1) and a single security group named `cbuild-sg-. 68 | 69 | ~~~ 70 | curl -O https://github.com/GrumpyOldTroll/chromium_fork/blob/main/aws-build.sh 71 | chmod +x aws-build.sh 72 | KEYPAIR=my-key REGION=us-west-2 ./aws-build.sh 73 | ~~~ 74 | 75 | # Traffic Sources 76 | 77 | In order to receive multicast, you'll need to have a source of multicast traffic sending from somewhere you can receive from. 78 | 79 | ## Running a Local Sender 80 | 81 | There's several ways to send traffic locally, and a few possibilities for where to run it from. 82 | 83 | ### External Machine on Same LAN 84 | 85 | If you've got your receiving device physically connected to a LAN and an external device on the receiver's default route, that's one of the easiest and most normal realistic cases. This one doesn't need any special routes, but it does need a separate device. Some VM setups can do this between VMs, but not always. 86 | 87 | From the sender: 88 | 89 | ~~~ 90 | curl -O https://raw.githubusercontent.com/GrumpyOldTroll/libmcrx/master/test/send.py 91 | chmod +x send.py 92 | ./send.py -g 232.2.2.2 -p 6000 -i 500 -d 7200 & 93 | ./send.py -g ff3e::8002:202 -p 6000 -i 500 -d 7200 & 94 | ~~~ 95 | 96 | A tcpdump should show these packets, either on the sender or the receiver: 97 | 98 | ~~~ 99 | sudo tcpdump -n udp and ip dst 232.2.2.2 100 | sudo tcpdump -n udp and ip6 dst ff3e::8002:202 101 | ~~~ 102 | 103 | If the sender has multiple interfaces and you want the sending on the non-default interface, you might have to add a route on the sender, giving it the output interface's device name for SSM addresses. You can check which interface is the output, either with tcpdump or by checking the route: 104 | 105 | ~~~ 106 | ip route get 232.2.2.2 107 | ip -6 route get ff3e::8002:202 108 | ~~~ 109 | 110 | If you need to change the output interface, setting the route for SSM addresses should do it (here the interface is named `xdn0`): 111 | 112 | ~~~ 113 | sudo ip -6 route add ff3e::/96 dev xdn0 114 | sudo ip route add 232.0.0.0/8 dev xdn0 115 | ~~~ 116 | 117 | If the packets are being sent but the receiver can't see them, it might mean you need to do a join first, or it might mean you'll need to use another method. 118 | 119 | At this point receiving should work with the steps in the "[Receiving Traffic](#receiving-traffic)" section, e.g. on the [demo page](https://grumpyoldtroll.github.io/wicg-multicast-receiver-api/demo-multicast-receive-api.html) or with `mcrx-check`: 120 | 121 | ~~~ 122 | SRC=10.7.1.1 123 | ./mcrx-check -s ${SRC} -g 232.2.2.2 -p 6000 -c 50 -d 0 -v 124 | ~~~ 125 | 126 | ### Internal Sender on Same Machine 127 | 128 | This doesn't require any external machines or traffic, which can be helpful for testing and development, but it does require setting local routes to get the traffic going the right way. 129 | 130 | The route for the destination group address needs to go to the sending interface, and the route for the source interface needs to go thru the receiving interface. 131 | 132 | There are a few different options, but perhaps the easiest is to run the sener in a [netns](https://man7.org/linux/man-pages/man8/ip-netns.8.html) connected by a [veth pair](https://man7.org/linux/man-pages/man4/veth.4.html). It can also be ok to just set the route for the send traffic on a veth pair without using a netns. (NB: For IPv4 I've also seen loopback interfaces work, but IPv6 had trouble with sending and receiving on the same interface.) 133 | 134 | ~~~ 135 | sudo << EOF 136 | ip netns add sender 137 | ip link add vtx0 type veth peer name vrx0 138 | ip addr add 10.20.20.2/24 dev vrx0 139 | ip link set dev vtx0 netns sender 140 | ip netns exec sender ip addr add 10.20.20.1/24 dev vtx0 141 | ip netns exec sender ip link set up dev vtx0 142 | ip netns exec sender ip route add default dev vtx0 143 | EOF 144 | sudo ip netns exec sender python3 src2/libmcrx/test/send.py -g 232.2.2.2 -p 6000 -i 500 -d 7200 & 145 | ~~~ 146 | 147 | At this point receiving should work with the steps in the "[Receiving Traffic](#receiving-traffic)" section, e.g. on the [demo page](https://grumpyoldtroll.github.io/wicg-multicast-receiver-api/demo-multicast-receive-api.html) or with `mcrx-check`: 148 | 149 | ~~~ 150 | SRC=10.20.20.1 151 | ./mcrx-check -s ${SRC} -g 232.2.2.2 -p 6000 -c 50 -d 0 -v 152 | ~~~ 153 | 154 | ### Other Senders 155 | 156 | In addition or instead of running `send.py` or similar test traffic, it's also possible to run video traffic that can be consumed by [VLC](https://www.videolan.org/) and probably [ffmpeg](https://www.ffmpeg.org/). 157 | 158 | ~~~ 159 | vlc -vvv ./vid.mp4 --sout '#udp{dst=232.3.3.3,port=5004,mux=ts}' --ttl 15 --loop --file-caching 10000 160 | ~~~ 161 | 162 | ~~~ 163 | ffmpeg -re -i vid.mp4 -c copy -f mpegts udp://232.10.10.2:12000?pkt_size=1316 164 | ~~~ 165 | 166 | ## Tunneling a Remote Sender 167 | 168 | These instructions are to sort of manually set up the network to tunnel the external multicast traffic into the local machine. 169 | 170 | It's possible to set this all up externally. Ideally your network will be the one that does this, in which case you have nothing to do here, your browser can just receive the traffic. 171 | 172 | But until your network gets to that, you can still tunnel the traffic in yourself. 173 | 174 | For advanced and persistent setup, you can stand up a multicast-capable network that does the ingest for you. There are instructions in the [multicast-ingest-platform](https://github.com/GrumpyOldTroll/multicast-ingest-platform/blob/master/sample-network/README.md) repo. The sections below describe how to do the same thing manually for your local machine. 175 | 176 | ### Internet2 Sources 177 | 178 | Internet2 has several public relays running. To connect to one of the relays, run an [AMT](https://www.rfc-editor.org/rfc/rfc7450.html) gateway instance: 179 | 180 | ~~~ 181 | AMTIP=$(dig +short amt-relay.m2icast.net | head -n 1) 182 | sudo docker run -d --rm --name amtgw --privileged grumpyoldtroll/amtgw ${AMTIP} 183 | ~~~ 184 | 185 | There's a bunch of sources sending traffic reachable via those relays. There's a [catalogue](https://multicastmenu.herokuapp.com/) that's kept more or less up to date. Many of the entries say their UDP port, and most of them use `1234`. 186 | 187 | You can pick a source and group from that catalogue: 188 | 189 | ~~~ 190 | SRC=162.250.138.201 191 | GRP=232.162.250.141 192 | PORT=1234 193 | ~~~ 194 | 195 | You also need the source to be routed via the gateway so the join will go in that direction: 196 | 197 | ~~~ 198 | sudo ip route add ${SRC}/32 dev docker0 199 | ~~~ 200 | 201 | At this point receiving should work with the steps in the "[Receiving Traffic](#receiving-traffic)" section, e.g. on the [demo page](https://grumpyoldtroll.github.io/wicg-multicast-receiver-api/demo-multicast-receive-api.html) or with `mcrx-check`: 202 | 203 | ~~~ 204 | ./mcrx-check -s ${SRC} -g ${GRP} -p ${PORT} -c 50 -d 0 -v 205 | ~~~ 206 | 207 | ### DRIAD Sources 208 | 209 | There are several sources that are publicly reachable whose relays are discoverable with [DRIAD](https://www.rfc-editor.org/rfc/rfc8777.html). 210 | 211 | You can pull in traffic from those by discovering the relay and setting the route for the source of the (S,G) to go through the docker interface: 212 | 213 | ~~~ 214 | SRC=23.212.185.14 215 | GRP=232.1.1.1 216 | PORT=5001 217 | ~~~ 218 | 219 | Setting up the docker container needs to do a DRIAD lookup: 220 | 221 | ~~~ 222 | curl -O https://raw.githubusercontent.com/GrumpyOldTroll/libmcrx/master/driad.py 223 | AMTIP=$(python3 driad ${SRCIP}) 224 | sudo docker run -d --rm --name amtgw --privileged grumpyoldtroll/amtgw ${AMTIP} 225 | ~~~ 226 | 227 | And you need the source IP routed to the docker container: 228 | 229 | ~~~ 230 | sudo ip route add ${SRC}/32 dev docker0 231 | ~~~ 232 | 233 | At this point receiving should work with the steps in the "[Receiving Traffic](#receiving-traffic)" section, e.g. on the [demo page](https://grumpyoldtroll.github.io/wicg-multicast-receiver-api/demo-multicast-receive-api.html) or with `mcrx-check`: 234 | 235 | ~~~ 236 | ./mcrx-check -s ${SRC} -g ${GRP} -p ${PORT} -c 50 -d 0 -v 237 | ~~~ 238 | 239 | # Receiving Traffic 240 | 241 | ~~~ 242 | URL="https://grumpyoldtroll.github.io/wicg-multicast-receiver-api/demo-multicast-receive-api.html" 243 | chromium-browser-mc-unstable --enable-blink-features=MulticastTransport ${URL} 244 | ~~~ 245 | 246 | ## Network Troubleshooting with Simpler Receiver 247 | 248 | If it's all working right, the browser receive will work. But to check whether it's the networking or something in the browser build, it's also possible to use the underling receive library, [libmcrx](https://github.com/GrumpyOldTroll/libmcrx) for a more isolated test. There are many ways the browser test can go wrong that this one cannot, but if this one fails the browser test will not succeed. 249 | 250 | In either case, you'll need the source IP address of those packets, and you pass it to the libmcrx testing program like this: 251 | 252 | ~~~ 253 | git clone https://github.com/GrumpyOldTroll/libmcrx 254 | cd libmcrx 255 | ./autogen.sh 256 | ./configure 257 | make 258 | ~~~ 259 | 260 | Running is like this: 261 | 262 | ~~~ 263 | SRC=10.7.1.1 264 | ./mcrx-check -s ${SRC} -g 232.2.2.2 -p 6000 -c 50 -d 0 -v 265 | ~~~ 266 | 267 | The output should look like this: 268 | 269 | ~~~ 270 | 06-27 16:25:48: joined to 10.7.1.1->232.2.2.2:6000 for 2s, 2 pkts received 271 | 06-27 16:25:50: joined to 10.7.1.1->232.2.2.2:6000 for 4s, 6 pkts received 272 | 06-27 16:25:52: joined to 10.7.1.1->232.2.2.2:6000 for 6s, 10 pkts received 273 | ~~~ 274 | 275 | If that's not working, the first thing to check is whether the join is going out on the right interface. From another shell, tcpdump for igmp (for v4) or mld (for v6) on the receiving device: 276 | 277 | ~~~ 278 | sudo tcpdump -n -vv igmp 279 | ~~~ 280 | 281 | Output looks like this when joining if it's working: 282 | 283 | ~~~ 284 | sudo tcpdump -n -vv igmp 285 | tcpdump: listening on enx00e04cab9b3b, link-type EN10MB (Ethernet), capture size 262144 bytes 286 | 16:47:24.578717 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 44, options (RA)) 287 | 10.7.1.58 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 232.2.2.2 allow { 10.7.1.1 }] 288 | 16:47:24.894738 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 44, options (RA)) 289 | 10.7.1.58 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 232.2.2.2 allow { 10.7.1.1 }] 290 | ~~~ 291 | 292 | And like this when leaving (by e.g. killing the receiver): 293 | 294 | ~~~ 295 | 16:47:32.186650 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 44, options (RA)) 296 | 10.7.1.58 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 232.2.2.2 block { 10.7.1.1 }] 297 | 16:47:32.188429 IP (tos 0xc0, ttl 1, id 19185, offset 0, flags [DF], proto IGMP (2), length 40, options (RA)) 298 | 10.7.1.1 > 232.2.2.2: igmp query v3 [max resp time 1.0s] [gaddr 232.2.2.2 { 10.7.1.1 }] 299 | 16:47:32.862698 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 44, options (RA)) 300 | 10.7.1.58 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 232.2.2.2 block { 10.7.1.1 }] 301 | 16:47:32.864340 IP (tos 0xc0, ttl 1, id 19351, offset 0, flags [DF], proto IGMP (2), length 40, options (RA)) 302 | 10.7.1.1 > 232.2.2.2: igmp query v3 [max resp time 1.0s] [gaddr 232.2.2.2 { 10.7.1.1 }] 303 | ~~~ 304 | 305 | Or for IPv6, the tcpdump filter implementation as of 2021-06 is less mature: 306 | 307 | ~~~ 308 | sudo tcpdump -n -vv icmp6 and ip[40]==128 309 | ~~~ 310 | 311 | (NB: seeing some trouble in ubuntu 20.04, MLD apparently not going out.) 312 | 313 | ## Known Things to Check 314 | 315 | ### Is the Port Correct? 316 | 317 | If you're seeing packets in tcpdump but not in the packet count, the first thing to check is whether the destination UDP port matches what the receiver is listening to. 318 | 319 | ### Is a Firewall Blocking? 320 | 321 | In some setups we've seen firewall rules blocking the forwarding of traffic. 322 | 323 | The symptom here is that native multicast arrives on the expected interface (for example, docker0), but is not received by the receiver. 324 | 325 | Running `dmesg` in this case would show lines that look something like this: 326 | 327 | ~~~ 328 | [5370076.311276] [UFW BLOCK] IN=docker0 OUT= PHYSIN=vethc1cd9d5 MAC=01:00:5e:00:00:01:02:42:ac:11:00:02:08:00 SRC=172.17.0.2 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2 329 | ~~~ 330 | 331 | The workaround is to add an allow rule: 332 | 333 | ~~~ 334 | sudo ufw allow in proto udp to 224.0.0.0/4 335 | ~~~ 336 | 337 | This may require restarting the receiver and/or the gateway. 338 | 339 | -------------------------------------------------------------------------------- /meetings/minutes/minutes-2021-10-27-tpac.md: -------------------------------------------------------------------------------- 1 | Please see the [IRC Log minutes](https://www.w3.org/2021/10/27-multicast-minutes.html) for a more readable version. 2 | 3 | The text dump from that is here, with many thanks to Chris Needham: 4 | 5 | ~~~ 6 | IRC log of multicast on 2021-10-27 7 | Timestamps are in UTC. 8 | 9 | 15:03:40 [RRSAgent] 10 | RRSAgent has joined #multicast 11 | 15:03:40 [RRSAgent] 12 | logging to https://www.w3.org/2021/10/27-multicast-irc 13 | 15:03:41 [takio] 14 | takio has joined #multicast 15 | 15:03:46 [Zakim] 16 | Zakim has joined #multicast 17 | 15:03:55 [cpn] 18 | Meeting: Multicast CG TPAC meeting 19 | 15:04:07 [cpn] 20 | Topic: Introduction 21 | 15:04:17 [cpn] 22 | Jake: Welcome to the Multicast CG meeting 23 | 15:05:48 [cpn] 24 | Present: Jake_Holland, Eric_Siow, Dominique_Hazael-Massieux, Gang_Shen, Kazuhiro_Hoya, Kyle_Rose 25 | 15:06:02 [cpn] 26 | Present+ Chris_Needham 27 | 15:06:16 [cpn] 28 | Present+ Takio_Yamaoka 29 | 15:07:31 [cpn] 30 | ... [Reviews Code of Conduct and IPR policy] 31 | 15:08:06 [cpn] 32 | Present+ Sudeep_Divakaran 33 | 15:08:37 [cpn] 34 | Jake: I'll walk through what we're doing and where we are, then a review of next steps for the work 35 | 15:08:51 [cpn] 36 | ... We'll schedule some sessions for the next month. Anything to add to the agenda? 37 | 15:09:01 [cpn] 38 | ... (none) 39 | 15:09:24 [dom] 40 | Present+ AnssiKostiainen, XiaoqianWu 41 | 15:09:27 [cpn] 42 | ... We're aiming to add a multicast receive capability to browsers 43 | 15:09:45 [cpn] 44 | ... We've not decided on whether an API is needed 45 | 15:09:57 [cpn] 46 | ... It could possibly fit inside WebTransport 47 | 15:10:17 [cpn] 48 | ... There probably will be some form of API to allow web pages to use it, to leverage the multicast transport that exists 49 | 15:10:42 [cpn] 50 | ... The reasons for that are: user experience 51 | 15:10:44 [EricSiow] 52 | EricSiow has joined #multicast 53 | 15:11:21 [cpn] 54 | ... [Shows histogram] During peak times, it gets a bit worse. Increases at the low-end of rates achieved 55 | 15:11:36 [cpn] 56 | ... This is normal, but on a heavy traffic day it gets bad 57 | 15:11:58 [cpn] 58 | ... Half the goodput for about 9 hours, e.g., when a game download is released 59 | 15:12:10 [cpn] 60 | ... These can be addressed with multicast, doesn't have to hammer the network 61 | 15:12:27 [anssik] 62 | anssik has joined #multicast 63 | 15:12:35 [anssik] 64 | Present+ Anssi_Kostiainen 65 | 15:12:39 [cpn] 66 | ... Sometimes it's CDN traffic, sometimes others. We get complaints from networks because users see lower than usual performance 67 | 15:12:56 [cpn] 68 | ... The key problem that multicast solves is congestion on the access networks to homes 69 | 15:13:12 [cpn] 70 | ... These are typically oversubscribed. You can put caches in networks, but there's no IP addressability 71 | 15:13:29 [cpn] 72 | ... Not just cable networks, also fiber networks and different access types. 5G can leverage these thigns 73 | 15:13:49 [cpn] 74 | ... The slides show a rough guide to how much offload is achievable 75 | 15:14:23 [cpn] 76 | ... With 3000 customers on a cable loop, if a large percentage is watching a particular event or downloading a game, traffic could be shared 77 | 15:14:40 [cpn] 78 | ... If you try to do it from cache, you have the same problem as you send it 1:1 to each user 79 | 15:15:07 [cpn] 80 | ... Possible to share the traffic, e.g., video on demand that's not popular enough. Large file downloads and live video streams 81 | 15:15:34 [cpn] 82 | ... Can talk separately about the transport protocols, but there's interest from ISPs 83 | 15:16:07 [cpn] 84 | ... Also the climate impact. The internet takes a lot of power. A BBC research project concluded that the internet takes 3.7% of total carbon footprint 85 | 15:16:12 [dom] 86 | Present+ LouayBassbouss 87 | 15:16:32 [cpn] 88 | ... Some problems can't be addressed by multicast. We're looking to get that down to 1% of total carbon footprint 89 | 15:16:43 [EricSiow] 90 | Q+ 91 | 15:16:49 [xiaoqian] 92 | xiaoqian has joined #multicast 93 | 15:16:55 [xiaoqian] 94 | present+ 95 | 15:17:06 [cpn] 96 | ... The article talked about proof of work bitcoin. Usage changes, but 20% day to day or 50% on big days is addressable through wider use of multicast 97 | 15:17:25 [cpn] 98 | ... The other reason is cost reduction 99 | 15:18:16 [cpn] 100 | Eric: About climate change, we had a separate breakout session on sustainability 101 | 15:18:24 [dom] 102 | -> https://www.w3.org/2021/10/19-sustainability-minutes.html Environmental Concerns and Sustainability (s12y) of Web Technologies - TPAC 2021 breakout 103 | 15:18:32 [cpn] 104 | ... There's some interest and movement to include sustainability as a horizontal review 105 | 15:18:41 [cpn] 106 | ... It's good you're including this 107 | 15:19:16 [cpn] 108 | ... If we're quoting percentages, we should be consistent, e.g, give the same measure for video games as well 109 | 15:19:36 [cpn] 110 | ... It would be good to educate stakeholders in terms of how much impact multicast would have 111 | 15:20:14 [cpn] 112 | Jake: This is where we started. Before we came to W3C we did some work in IETF, then we went to ISPs to ask if they'd use it 113 | 15:20:36 [cpn] 114 | ... We showed them the traffic data, and potential reduction through multicast offload 115 | 15:20:54 [cpn] 116 | ... I've talked to more than 30 ISPs. There's been a range of responses 117 | 15:21:17 [cpn] 118 | ... Two said they don't plan to use it. One said they thought it would reduce revenue, they charge by traffic served 119 | 15:21:46 [cpn] 120 | ... Almost all ISPs were more positive, good to reduce traffic. Some identified logistical difficulties to roll it out 121 | 15:21:59 [cpn] 122 | ... We ran lab trials with four ISPs, showed it's practical 123 | 15:22:28 [cpn] 124 | ... Many were positive, different ranges of skepticism 125 | 15:23:16 [cpn] 126 | ... Some saw offloading peak traffic as beneficial, more so than the day to day, but that's where reductions are 127 | 15:23:32 [cpn] 128 | ... It's not an Akamai black-box, hence the standards approach 129 | 15:24:08 [cpn] 130 | ... [Avoidable traffic: video] Example of reduction in peak traffic in a sports event 131 | 15:24:42 [cpn] 132 | Jake: The CG has created a getting started primer, to try out the API. I can help people get set up 133 | 15:25:00 [cpn] 134 | ... Where we are now, on the IETF side, is we're trying to get engagement on the security model 135 | 15:25:28 [cpn] 136 | ... We got feedback from the Chromium net-dev list. They rejected our PR as it would be a new type of mixed content, and needs a better security model 137 | 15:26:25 [cpn] 138 | ... With that feedback, Kyle wrote a security document. I'm hoping to talk about this at IETF secdispatch in a few weeks, then take it into a standard we can build from to run multicast safely for web traffic 139 | 15:26:35 [cpn] 140 | ... That's a precondition for getting into browsers properly 141 | 15:27:10 [cpn] 142 | ... We need something integrated in the browser for authenticating packets. Also QUIC integration 143 | 15:27:16 [EricSiow] 144 | Q+ to ask question. 145 | 15:27:47 [cpn] 146 | ... The way backpressure works in that setup is different. There's a proposal for that in MBONED 147 | 15:28:07 [cpn] 148 | ... Could send the same kind of information in a QUIC frame in a WebTransport context 149 | 15:28:33 [cpn] 150 | ... Then there's signalling for browser APIs. The BBC QUIC multicast draft is a good place to start experimenting 151 | 15:29:04 [cpn] 152 | ... The current multicast CG charter says we'll go to WebTransport first, to get datagram support to plug in existing multicast applications thar un in walled garden context 153 | 15:29:33 [cpn] 154 | ... If you have WebTransport you can put something in front at the sender side that puts it into QUIC datagram framing, then unpack at the receiver side 155 | 15:29:59 [cpn] 156 | ... I can share a demo video. We ported our existing multicast receiver to WASM and used it to play video 157 | 15:30:23 [cpn] 158 | Eric: How are active are browser vendors involved in the IETF discussion? 159 | 15:30:56 [cpn] 160 | Jake: Not very. Eric Rescorla at Mozilla commented, but I'm hoping to see support 161 | 15:31:08 [cpn] 162 | Eric: What about companies like Amazon? 163 | 15:31:46 [cpn] 164 | Jake: I did get a call from Amazon. They signed a deal with the NFL for Thursday night football. We've explored whether it's viable to do this with multicast 165 | 15:32:15 [cpn] 166 | ... That has a lot of viewers, at the high end of what the internet can support 167 | 15:32:34 [cpn] 168 | ... They're supportive of the standards work we're doing. Not clear we'll be ready in their timeframe 169 | 15:32:57 [cpn] 170 | ... I've not seen them engage in the standards work, but I hope they will as they have a driving use case 171 | 15:33:24 [cpn] 172 | ... I've talked privately with people at Google. Not everyone is convinced. YouTube Live traffic 173 | 15:33:43 [cpn] 174 | ... I hope we can drive their interest, but I don't think we've successfully done that yet 175 | 15:34:16 [cpn] 176 | ... People in networking may be skeptical from the last attempt at multicast. A vast amount of work went into any source multicast, that didn't pan out 177 | 15:34:43 [cpn] 178 | ... RFC8815 deprecated anysource multicast for inter-domain usage. That was a big false start for multicast 179 | 15:34:59 [dom] 180 | -> https://datatracker.ietf.org/doc/rfc8815/ Deprecating Any-Source Multicast (ASM) for Interdomain Multicast - RFC8815 181 | 15:35:12 [cpn] 182 | ... It's widely deployed in the operating systems. IGMP is already there 183 | 15:35:51 [cpn] 184 | Eric: I think the first task for the CG is to articulate the pain points and benefit to stakeholders 185 | 15:36:32 [cpn] 186 | ... You have some natural stakeholders. Google has multiple groups, so YouTube could be a supporter. The goal is to get them to feel the pain points and get them on side 187 | 15:36:48 [cpn] 188 | ... How do you get the Chrome browser people comfortable with the security issue? 189 | 15:37:22 [cpn] 190 | Jake: There's a chicken and egg problem. It needs ISPs interested in delivering it. I'd like to have the technical capability in place, that creates interest 191 | 15:38:05 [cpn] 192 | ... A few ISPs have joined the group but not active, e.g., Verizon and Comcast. I'd like to get more 193 | 15:38:11 [dom] 194 | -> https://www.w3.org/community/multicast/participants Participants in the Multicast Community Group 195 | 15:38:26 [cpn] 196 | ... They'll be less interested in the browser work, which is the charter for this group 197 | 15:38:56 [cpn] 198 | ... I'd like to have a big-picture plan for how this comes together. The multicast group is about browser support, but it plays into the overall story of what needs to happen 199 | 15:39:06 [cpn] 200 | ... Some is outside standards groups, getting people to invest 201 | 15:39:24 [cpn] 202 | Eric: If the business need is there, they'll commit people to standards work 203 | 15:39:51 [cpn] 204 | ... The benefit is obvious, but how do we rally the ecosystem? That's the immediate challenge 205 | 15:40:25 [cpn] 206 | Jake: Getting demos closer to what's releasable helps. The standards work is important, but a browser fork that does something usable is a key next step to make the case 207 | 15:41:04 [cpn] 208 | ... The other piece is getting buy-in from the browser tech side. Most objections have come from the security side. The proposal needs to be credible for people to pay attention 209 | 15:41:41 [cpn] 210 | ... So my proposal for next steps is the demo. If it can play video and there's some consensus in standards that it satisfies security concerns 211 | 15:41:58 [cpn] 212 | ... We don't have the level of buy-in from the people who stand to gain 213 | 15:42:19 [cpn] 214 | ... Similar story for CDNs and content owners, who can realise cost savings 215 | 15:43:25 [cpn] 216 | Dom: The conversation may be bound to having a timeline. How much time is needed to align things? 217 | 15:43:56 [cpn] 218 | ... How long is needed for the demo, then getting stakeholder input using the demo? 219 | 15:44:28 [cpn] 220 | Jake: So I have a demo running, that's close to ready. There's a Chromium binary you can download and install 221 | 15:44:36 [dom] 222 | -> https://www.w3.org/2021/10/TPAC/demos/multicast.html Multicast for the Web - TPAC 2021 demo 223 | 15:44:38 [cpn] 224 | ... I can share a link to the demo 225 | 15:45:15 [cpn] 226 | ... There's the open question of whether it can ship in a browser. If it's there, will ISPs use it, then will content owners use it? 227 | 15:45:46 [cpn] 228 | Dom: I'm hearing that the security is a key part of the plan to build confidence to use it 229 | 15:46:36 [cpn] 230 | Jake: ?? and Internet2 have multicast working groups. They are supporting research, and I'm working with them 231 | 15:46:57 [cpn] 232 | ... Ingest protocol for how traffic gets into the network. Our labs tests with ISPs looked at this 233 | 15:47:08 [cpn] 234 | ... A number of moving parts are essential to adoption, but outside W3C 235 | 15:47:22 [cpn] 236 | ... In this group, what I'm hoping to do is move forward the receive side of the story 237 | 15:47:37 [cpn] 238 | ... I encourage people to engage in IETF, to get the whole picture to stakeholders 239 | 15:47:49 [cpn] 240 | ... There's a lot of money at stake and potential big impact 241 | 15:48:12 [cpn] 242 | Gang: I think customers want this to be as transparent as possible 243 | 15:48:28 [dom] 244 | s??/GEANT/ 245 | 15:48:47 [cpn] 246 | ... DVB enable this through a MPEG DASH player. They have an easier problem 247 | 15:49:27 [cpn] 248 | ... We're considering the receiver side, but what about the server side, e.g., the 5G edge which is closer to the last mile. Our target is to resolve the last mile bandwidth issue 249 | 15:49:39 [cpn] 250 | ... Can we simplify this security model issue? 251 | 15:50:01 [cpn] 252 | Jake: If you really make use of the broadcast capability at the edge, it may be possible to do something 253 | 15:50:57 [cpn] 254 | ... The issue is that you're trusting the edge servers. Handing off control, if you send somethign that an ISP on the path can change, they could do that. This is a big source of concern at IETF 255 | 15:51:55 [cpn] 256 | ... It's part of what we addressed with AMBI authentication, there's not a way for it to be spoofed, it creates and end to end authentication chain, so there's no scope any more for ad theft or unauthenticated injection 257 | 15:52:03 [cpn] 258 | ... That's one of several problems 259 | 15:52:37 [cpn] 260 | ... In a walled garden, there's a different set of problems. Could be how you get the scale in the end 261 | 15:52:59 [cpn] 262 | ... But it only works for video, gameplay and other downloads need different solutions 263 | 15:53:18 [cpn] 264 | ... 4G had this capability, but people didn't use it. The north-bound interface is hard 265 | 15:53:27 [cpn] 266 | ... Multicast TV has been used, but not inter-domain yet 267 | 15:54:01 [kazho] 268 | kazho has joined #multicast 269 | 15:54:10 [cpn] 270 | Gang: There's an incentive for ISPs to make changes, saving bandwidth. With unicast fallback it's easy to make changes 271 | 15:54:37 [cpn] 272 | Jake: I think we way we proposed is easy, just pass through the streams. A design question is which way that can be done 273 | 15:55:18 [cpn] 274 | ... Give them a coherent object to unpack and distribute, or how to pass through an ingested stream 275 | 15:55:40 [cpn] 276 | ... ISPs tend to prefer this model, they have less to maintain, as they can focus on moving packets rather than end-user applications 277 | 15:56:08 [cpn] 278 | ... If it's just IP that you pass through, and senders and receivers decide how it's interpreted, there's less for them to do 279 | 15:56:13 [cpn] 280 | ... It's a great question 281 | 15:56:37 [cpn] 282 | Jake: What I'd like to do in the next month is some experiments with QUIC and WebTransport API integration 283 | 15:56:59 [cpn] 284 | ... If anyone would like to join me, I'd like to collaborate with people, probably after IETF 285 | 15:57:47 [cpn] 286 | ... Not sure whether the BBC nghq QUIC or aioquic will be easier, that's part of the investigation 287 | 15:58:00 [cpn] 288 | ... If you can comment on secdispatch, it's an important moment 289 | 15:58:20 [cpn] 290 | ... There's a hackathon opportunity to work on the browser demo, next week 291 | 15:58:37 [cpn] 292 | ... I can introduce you to the right people to follow up 293 | 15:58:52 [cpn] 294 | present+ LouayBassbouss 295 | 15:58:57 [cpn] 296 | Topic: Wrap up 297 | 15:59:33 [cpn] 298 | Jake: Thank you for all for coming. I hope I've piqued your interest to look into this 299 | 16:00:05 [cpn] 300 | ... The CG meets monthly, first Wednesday in December 7:30am Pacific. Feel free to contact me offline before then 301 | 16:01:14 [cpn] 302 | rrsagent, draft minutes 303 | 16:01:14 [RRSAgent] 304 | I have made the request to generate https://www.w3.org/2021/10/27-multicast-minutes.html cpn 305 | 16:01:18 [cpn] 306 | rrsagent, make log public 307 | 16:02:51 [takio] 308 | takio has left #multicast 309 | 18:58:31 [Zakim] 310 | Zakim has left #multicast 311 | ~~~ 312 | -------------------------------------------------------------------------------- /multicast-cg-charter.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | Multicast Community Group Charter 6 | 7 | 8 | 9 | 10 | 29 | 30 | 31 |

32 | Multicast Community Group Charter 33 |

34 | 35 |

36 | This Charter was ratified by group consensus on 2021-06-23. To submit feedback, 37 | please use the Github Repo Issues list. 38 |

39 | 49 |

50 | Mission 51 |

52 |

53 | The mission of the Multicast web community group is to enable multicast 54 | IP transport for web traffic to efficiently solve scalability problems 55 | in networking and web operations. 56 |

57 |

58 | Scope of Work 59 |

60 |

In general, topics related to secure transport using multicast IP and the application-layer signaling to support it are in scope. 61 |

62 |

The CLA is applicable (as described in the process section) to any work contributing to normative specifications. This includes in-scope work such as: 63 |

    64 |
  • Explore and incubate APIs to enable multicast transport on the 65 | web (and their test suites), leveraging existing protocols and 66 | APIs where possible 67 |
    • 68 |
  • Define application layer negotiation mechanisms to signal 69 | multicast support and communicate necessary parameters 70 |
    • 71 |
  • Define fallback mechanisms for networks where multicast 72 | availability is limited or disabled by the network. 73 |
    • 74 |
75 |

76 |

Other work that's in-scope but where the CLA is not expected to directly apply includes activities like: 77 |

    78 |
  • Identify and refine use cases that can improve network 79 | efficiency and user experience through the use of multicast 80 |
    • 81 |
  • Find working group homes for incubated APIs after incubation 82 |
    • 83 |
  • Evaluate multicast transport protocols, implementations, and 84 | deployment profiles on their performance characteristics and 85 | their suitability for web use cases. 86 |
    • 87 |
  • Liaison statements suggesting refinements and fixes to existing 88 | and emerging specifications in the IETF or other standards bodies, 89 | especially with regard to security considerations and protocols 90 | relevant to web applications for multicast-based transport 91 |
    • 92 |
  • Evangelize open web and internet standards and APIs that enable 93 | the use of multicast with web developers, browser vendors, and 94 | network operators 95 |
    • 96 |
  • Evangelize the scalability benefits of leveraging multicast 97 | transport for appropriate use cases and where available. 98 |
    • 99 |
100 |

101 |

102 | Considerations on Proprietary Protocols 103 |

104 |

Work on open standards is preferred, but many existing uses of multicast have proprietary implementations, and some of these may be possible to operate on top of some web APIs as they become available. 105 |

106 |

Existing proprietary transport protocols MAY be evaluated and tracked for their performance characteristics and potential to address scalability problems, as long as their usage is consistent with the appropriate security considerations. For example, evaluating performance characteristics of a proprietary implementation of a video player built on top of a multicast-enabled WebTransport API would not be out of scope for this group--it would be a case study of an example usage of a multicast WebTransport API. 107 |

108 |

Although such case studies may inform the analysis of use cases within the group, examination of such protocols does not imply that the proprietary implementation is subject to the CLA. 109 |

110 |

Proprietary implementations SHOULD NOT be individually evangelized by this group, but lists and reviews that include information about proprietary implementations without unduly highlighting specific vendors MAY be included during evangelization of multicast APIs in general. 111 |

112 |

113 | Out of Scope 114 |

115 |

The definition of network protocols for multicast transport or 116 | routing is out of scope for this group. In general, it is expected that 117 | protocol definition will be handled in the IETF. (Note however that 118 | liaison statements to appropriate IETF groups or evaluations of how 119 | such protocols impact performance or otherwise impact web use cases 120 | would be in scope.) 121 |

122 |

123 | Deliverables 124 |

125 |

126 | Specifications 127 |

128 |

129 | Phase 1 130 |

131 |

The initial priority will focus on a proposal to extend WebTransport with a multicast receive capability. 132 |

133 |

(Suggested starting point for incubation: early Multicast Receive API proposal and implementation.) 134 |

135 |

This is a low-level API that can be used to incubate the later stages by experimenting with transport protocols implemented inside web apps. 136 |

137 |

138 | Phase 2 139 |

140 |

Later work will aim to extend other W3C specifications that may be able to get improved performance by embedding interoperable open standards for multicast transport into various delivery APIs. Specifications under consideration for this phase will include: 141 |

149 | This work MAY proceed in parallel with higher priority work, provided there are group members actively engaged with it. 150 |

151 |

152 | Non-Normative Reports 153 |

154 |

The group may produce other Community Group Reports within the scope of 155 | this charter but that are not Specifications, for instance: 156 |

    157 |
  • Use Cases document 158 |
    • 159 |
  • Primers 160 |
    • 161 |
  • Position statements 162 |
    • 163 |
  • Resources for evangelism (explanatory docs for different audiences, statistics-gathering) 164 |
    • 165 |
166 |

167 |

In general, other documents related to in-scope multicast work are welcome. If there are individuals who will commit to being editors for a document, the group should agree to accept it as a work item. 168 | 169 |

170 |

171 | Test Suites 172 |

173 |

174 | The group MAY produce test suites to support the Specifications. Any test suites produced by this group will be made available under the same license as WPT. 175 |

176 | 178 |

179 | Dependencies or Liaisons 180 |

181 |

Progress on any usage of multicast for web traffic will rely on progress on some IETF specifications, and group members will be encouraged to perform IETF reviews for these. The list of these specifications is maintained in the github repo at consensus-dependency-specs.md, to be updated as incubation proceeds according to group consensus. 182 |

183 |

Progress on the specifications in phase 2 will depend on 184 | interoperable open implementations of specifications for multicast-based 185 | transport protocols, and the group 186 | will need to consider the suitability of these protocols for addressing 187 | the specific use cases covered by the target APIs, and to evaluate what 188 | updates might be necessary to meet the requirements of the web security 189 | model. Several such candidate protocols exist, and the list of protocols 190 | recommended for consideration is maintained in the github repo under consensus-transport-protocols.md, to be updated as incubation proceeds according to group consensus. 191 |

192 |

It's expected that implementations of the receive side of these 193 | protocols on top of a secure WebTransport API can aid the success of 194 | these evaluation efforts, which is a key motivator for the phased 195 | approach outlined here. 196 |

197 |

198 | W3C Groups 199 |

200 |

The Multicast Web Community Group will also liaise with the following W3C Working groups: 201 | 202 |

208 |

209 |

The Multicast Web Community Group will also liaise with W3C Interest and Community groups with interests affected by multicast, including: 210 |

220 |

221 | External Groups 222 |

223 | 234 |

235 | 236 |

237 | Community and Business Group Process 238 |

239 |

240 | The group operates under the Community and Business 242 | Group Process. Terms in this Charter that conflict with those of the 243 | Community and Business Group Process are void. 244 |

245 |

246 | As with other Community Groups, W3C seeks organizational licensing 247 | commitments under the W3C Community 249 | Contributor License Agreement (CLA). When people request to 250 | participate without representing their organization's legal interests, 251 | W3C will in general approve those requests for this group with the 252 | following understanding: W3C will seek and expect an organizational 253 | commitment under the CLA starting with the individual's first request to 254 | make a contribution to a group Deliverable. 255 | The section on Contribution Mechanics describes 256 | how W3C expects to monitor these contribution requests. 257 |

258 | 259 |

260 | The W3C Code of 261 | Ethics and Professional Conduct applies to participation in 262 | this group. 263 |

264 | 265 |

266 | Work Limited to Charter Scope 267 |

268 |

269 | The group will not publish Specifications on topics other than those 270 | listed under Specifications above. See 271 | below for how to modify the charter. 272 |

273 |

274 | Contribution Mechanics 275 |

276 |

277 | Substantive Contributions to Specifications can only be made by Community 278 | Group Participants who have agreed to the W3C Community 280 | Contributor License Agreement (CLA). 281 |

282 |

283 | Specifications created in the Community Group must use the 285 | W3C Software and Document License. All other documents produced by 286 | the group should use that License where possible. 287 |

288 |

289 | Community Group participants agree to make all contributions in the 290 | GitHub repo the group is using for the particular document. This may be 291 | in the form of a pull request (preferred), by raising an issue, or by 292 | adding a comment to an existing issue. 293 |

294 |

295 | All Github repositories attached to the Community Group must contain a 296 | copy of the CONTRIBUTING 298 | and LICENSE 300 | files. 301 |

302 |

303 | Transparency 304 |

305 |

306 | The group will conduct all of its technical work in public. If the group 307 | uses GitHub, all technical work will occur in its GitHub repositories 308 | (and not in mailing list discussions). This is to ensure contributions 309 | can be tracked through a software tool. 310 |

311 |

312 | Meetings may be restricted to Community Group participants, but a public 313 | summary or minutes must be posted to the group's public mailing list, or 314 | to a GitHub issue if the group uses GitHub. 315 |

316 |

317 | Decision Process 318 |

319 |

320 | This group will seek to make decisions where there is consensus. Groups 321 | are free to decide how to make decisions (e.g. Participants who have 322 | earned Committer status for a history of useful contributions assess 323 | consensus, or the Chair assesses consensus, or where consensus isn't 324 | clear there is a Call for Consensus [CfC] to allow multi-day online 325 | feedback for a proposed course of action). It is expected that 326 | participants can earn Committer status through a history of valuable 327 | contributions as is common in open source projects. After discussion and 328 | due consideration of different opinions, a decision should be publicly 329 | recorded (where GitHub is used as the resolution of an Issue). 330 |

331 |

332 | If substantial disagreement remains (e.g. the group is divided) and the 333 | group needs to decide an Issue in order to continue to make progress, the 334 | Committers will choose an alternative that had substantial support (with 335 | a vote of Committers if necessary). Individuals who disagree with the 336 | choice are strongly encouraged to take ownership of their objection by 337 | taking ownership of an alternative fork. This is explicitly allowed (and 338 | preferred to blocking progress) with a goal of letting implementation 339 | experience inform which spec is ultimately chosen by the group to move 340 | ahead with. 341 |

342 |

343 | Any decisions reached at any meeting are tentative and should be recorded 344 | in a GitHub Issue for groups that use GitHub and otherwise on the group's 345 | public mail list. Any group participant may object to a decision reached 346 | at an online or in-person meeting within 7 days of publication of the 347 | decision provided that they include clear technical reasons for their 348 | objection. The Chairs will facilitate discussion to try to resolve the 349 | objection according to the decision process. 350 |

351 |

352 | It is the Chairs' responsibility to ensure that the decision process is 353 | fair, respects the consensus of the CG, and does not unreasonably favour 354 | or discriminate against any group participant or their employer. 355 |

356 |

357 | Chair Selection 358 |

359 |

360 | Participants in this group choose their Chair(s) and can replace their 361 | Chair(s) at any time using whatever means they prefer. However, if 5 362 | participants, no two from the same organisation, call for an election, 363 | the group must use the following process to replace any current Chair(s) 364 | with a new Chair, consulting the Community Development Lead on election 365 | operations (e.g., voting infrastructure and using RFC 2777). 367 |

368 |
    369 |
  1. Participants announce their candidacies. Participants have 14 days to 370 | announce their candidacies, but this period ends as soon as all 371 | participants have announced their intentions. If there is only one 372 | candidate, that person becomes the Chair. If there are two or more 373 | candidates, there is a vote. Otherwise, nothing changes. 374 |
    2. 375 |
  2. Participants vote. Participants have 21 days to vote for a single 376 | candidate, but this period ends as soon as all participants have voted. 377 | The individual who receives the most votes, no two from the same 378 | organisation, is elected chair. In case of a tie, RFC2777 is used to 379 | break the tie. An elected Chair may appoint co-Chairs. 380 |
    3. 381 |
382 |

383 | Participants dissatisfied with the outcome of an election may ask the 384 | Community Development Lead to intervene. The Community Development Lead, 385 | after evaluating the election, may take any action including no action. 386 |

387 |

388 | Amendments to this Charter 389 |

390 |

391 | The group can decide to work on a proposed amended charter, editing the 392 | text using the Decision Process described above. 393 | The decision on whether to adopt the amended charter is made by 394 | conducting a 30-day vote on the proposed new charter. The new charter, if 395 | approved, takes effect on either the proposed date in the charter itself, 396 | or 7 days after the result of the election is announced, whichever is 397 | later. A new charter must receive 2/3 of the votes cast in the approval 398 | vote to pass. The group may make simple corrections to the charter such 399 | as deliverable dates by the simpler group decision process rather than 400 | this charter amendment process. The group will use the amendment process 401 | for any substantive changes to the goals, scope, deliverables, decision 402 | process or rules for amending the charter. 403 |

404 | 405 | 406 | --------------------------------------------------------------------------------