Meeting minutes
Introduction
Jake: Welcome to the Multicast CG meeting
… [Reviews Code of Conduct and IPR policy]
Jake: I'll walk through what we're doing and where we are, then a review of next steps for the work
… We'll schedule some sessions for the next month. Anything to add to the agenda?
… (none)
… We're aiming to add a multicast receive capability to browsers
… We've not decided on whether an API is needed
… It could possibly fit inside WebTransport
… There probably will be some form of API to allow web pages to use it, to leverage the multicast transport that exists
… The reasons for that are: user experience
… [Shows histogram] During peak times, it gets a bit worse. Increases at the low-end of rates achieved
… This is normal, but on a heavy traffic day it gets bad
… Half the goodput for about 9 hours, e.g., when a game download is released
… These can be addressed with multicast, doesn't have to hammer the network
… Sometimes it's CDN traffic, sometimes others. We get complaints from networks because users see lower than usual performance
… The key problem that multicast solves is congestion on the access networks to homes
… These are typically oversubscribed. You can put caches in networks, but there's no IP addressability
… Not just cable networks, also fiber networks and different access types. 5G can leverage these thigns
… The slides show a rough guide to how much offload is achievable
… With 3000 customers on a cable loop, if a large percentage is watching a particular event or downloading a game, traffic could be shared
… If you try to do it from cache, you have the same problem as you send it 1:1 to each user
… Possible to share the traffic, e.g., video on demand that's not popular enough. Large file downloads and live video streams
… Can talk separately about the transport protocols, but there's interest from ISPs
… 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
… Some problems can't be addressed by multicast. We're looking to get that down to 1% of total carbon footprint
… 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
… The other reason is cost reduction
Eric: About climate change, we had a separate breakout session on sustainability
<dom> Environmental Concerns and Sustainability (s12y) of Web Technologies - TPAC 2021 breakout
Eric: There's some interest and movement to include sustainability as a horizontal review
… It's good you're including this
… If we're quoting percentages, we should be consistent, e.g, give the same measure for video games as well
… It would be good to educate stakeholders in terms of how much impact multicast would have
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
… We showed them the traffic data, and potential reduction through multicast offload
… I've talked to more than 30 ISPs. There's been a range of responses
… Two said they don't plan to use it. One said they thought it would reduce revenue, they charge by traffic served
… Almost all ISPs were more positive, good to reduce traffic. Some identified logistical difficulties to roll it out
… We ran lab trials with four ISPs, showed it's practical
… Many were positive, different ranges of skepticism
… Some saw offloading peak traffic as beneficial, more so than the day to day, but that's where reductions are
… It's not an Akamai black-box, hence the standards approach
… [Avoidable traffic: video] Example of reduction in peak traffic in a sports event
Jake: The CG has created a getting started primer, to try out the API. I can help people get set up
… Where we are now, on the IETF side, is we're trying to get engagement on the security model
… 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
… 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
… That's a precondition for getting into browsers properly
… We need something integrated in the browser for authenticating packets. Also QUIC integration
… The way backpressure works in that setup is different. There's a proposal for that in MBONED
… Could send the same kind of information in a QUIC frame in a WebTransport context
… Then there's signalling for browser APIs. The BBC QUIC multicast draft is a good place to start experimenting
… 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
… 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
… I can share a demo video. We ported our existing multicast receiver to WASM and used it to play video
Eric: How are active are browser vendors involved in the IETF discussion?
Jake: Not very. Eric Rescorla at Mozilla commented, but I'm hoping to see support
Eric: What about companies like Amazon?
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
… That has a lot of viewers, at the high end of what the internet can support
… They're supportive of the standards work we're doing. Not clear we'll be ready in their timeframe
… I've not seen them engage in the standards work, but I hope they will as they have a driving use case
… I've talked privately with people at Google. Not everyone is convinced. YouTube Live traffic
… I hope we can drive their interest, but I don't think we've successfully done that yet
… 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
… RFC8815 deprecated anysource multicast for inter-domain usage. That was a big false start for multicast
<dom> Deprecating Any-Source Multicast (ASM) for Interdomain Multicast - RFC8815
Jake: It's widely deployed in the operating systems. IGMP is already there
Eric: I think the first task for the CG is to articulate the pain points and benefit to stakeholders
… 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
… How do you get the Chrome browser people comfortable with the security issue?
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
… A few ISPs have joined the group but not active, e.g., Verizon and Comcast. I'd like to get more
<dom> Participants in the Multicast Community Group
Jake: They'll be less interested in the browser work, which is the charter for this group
… 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
… Some is outside standards groups, getting people to invest
Eric: If the business need is there, they'll commit people to standards work
… The benefit is obvious, but how do we rally the ecosystem? That's the immediate challenge
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
… 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
… 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
… We don't have the level of buy-in from the people who stand to gain
… Similar story for CDNs and content owners, who can realise cost savings
Dom: The conversation may be bound to having a timeline. How much time is needed to align things?
… How long is needed for the demo, then getting stakeholder input using the demo?
Jake: So I have a demo running, that's close to ready. There's a Chromium binary you can download and install
<dom> Multicast for the Web - TPAC 2021 demo
Jake: I can share a link to the demo
… 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?
Dom: I'm hearing that the security is a key part of the plan to build confidence to use it
Jake: ?? and Internet2 have multicast working groups. They are supporting research, and I'm working with them
… Ingest protocol for how traffic gets into the network. Our labs tests with ISPs looked at this
… A number of moving parts are essential to adoption, but outside W3C
… In this group, what I'm hoping to do is move forward the receive side of the story
… I encourage people to engage in IETF, to get the whole picture to stakeholders
… There's a lot of money at stake and potential big impact
Gang: I think customers want this to be as transparent as possible
<dom> s??/GEANT/
Gang: DVB enable this through a MPEG DASH player. They have an easier problem
… 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
… Can we simplify this security model issue?
Jake: If you really make use of the broadcast capability at the edge, it may be possible to do something
… 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
… 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
… That's one of several problems
… In a walled garden, there's a different set of problems. Could be how you get the scale in the end
… But it only works for video, gameplay and other downloads need different solutions
… 4G had this capability, but people didn't use it. The north-bound interface is hard
… Multicast TV has been used, but not inter-domain yet
Gang: There's an incentive for ISPs to make changes, saving bandwidth. With unicast fallback it's easy to make changes
Jake: I think we way we proposed is easy, just pass through the streams. A design question is which way that can be done
… Give them a coherent object to unpack and distribute, or how to pass through an ingested stream
… ISPs tend to prefer this model, they have less to maintain, as they can focus on moving packets rather than end-user applications
… 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
… It's a great question
Jake: What I'd like to do in the next month is some experiments with QUIC and WebTransport API integration
… If anyone would like to join me, I'd like to collaborate with people, probably after IETF
… Not sure whether the BBC nghq QUIC or aioquic will be easier, that's part of the investigation
… If you can comment on secdispatch, it's an important moment
… There's a hackathon opportunity to work on the browser demo, next week
… I can introduce you to the right people to follow up
Wrap up
Jake: Thank you for all for coming. I hope I've piqued your interest to look into this
… The CG meets monthly, first Wednesday in December 7:30am Pacific. Feel free to contact me offline before then