Re: [Secdispatch] Multicast architectures for the web

["Holland, Jake" <[e-mail]>]

Hi Ben,

Thanks for clarifying this point, I think I might have misunderstood what you meant during the rush at the end of the session, and now I think I can see better where you’re coming from with this suggestion.

I agree running some experimental pages with unmodified browsers to identify bottlenecks in datagram processing on the client side for emulating the handling of worthwhile multicast use cases through webtransport is a very fine idea as an incremental step toward an eventual IP multicast solution.  That’s a helpful suggestion and thank you!

As worthwhile solutions in their own right, I think without IP multicast there is probably zero value proposition for this kind of application level multicast as far as I can tell (my money would even be on “at least slightly negative” for most applications since there’s no network offload to offset the added challenges), and my response during the session was meant as a response to that. But as a stepping stone for easy experimentation that will translate well to a multicast transport, this seems very likely to be a good idea, and I’ll look at how to work it into my plans.

Thanks and regards,
Jake


From: Ben Schwartz <bemasc=[e-mail]>
Date: Tue,2021-11-09 at 8:01 AM
To: "[e-mail]" <[e-mail]>
Cc: "Rose, Kyle" <[e-mail]>
Subject: [Secdispatch] Multicast architectures for the web

Regarding draft-krose-multicast-security, I think the most productive step would be to start with an architecture that sits on top of WebTransport in unmodified browsers.  WebTransport's support for unreliable datagrams opens up a lot of novel possibilities for application-layer multicast (e.g. holding less state at the splitter, backfiling lost segments directly from the origin), and raises some interesting questions about how to implement content security most naturally.  This can all be done without browser changes.

If a system like this can be clearly defined, deployed, and measured, I think that greatly increases the likelihood of some of this functionality being moved down into the web itself.  There's a long history of page-layer innovations being moved into the browser (e.g. crypto in JS -> WebCrypto, asm.js -> WebAssembly), and experiments with solutions within the page can help us to identify the bottlenecks that really need to be alleviated.

--Ben Schwartz