Chances of adding multicast receive to webtransport?

[ROBERT-MCDOWELL]

Any chance to be accepted with webtransport?

[GrumpyOldTroll]

No major change on this yet. We've refactored the proposed API to be roughly similar to what webtransport does as far as we can tell (specifically, the ReceiveStream-like semantics), in hopes that might make a future merge technically plausible.

However, the explainer point about this still represents the latest status of the discussion.

Probably this needs to get further along as an incubating feature with a solid implementation in a deployed browser (especially including the authentication scheme) before we can usefully re-open this question with webtransport in any serious way. That work is ongoing, slowly. I'm hoping to be at that stage by end of 2021 or so, perhaps sooner if we get more attention and interested contributors, but I still can't promise a specific schedule at this point.

Further insight would be very welcome from folks like @pthatcherg or @vasilvv about what it would take to get an API like this one added to webtransport in due course (with the associated change to the webtransport security scope, since this still necessarily has the same sticking point on "providing all of the security properties of TLS, including confidentiality and integrity of the traffic" that we discussed previously, due to the many-to-one packet distribution model in multicast). Especially if they've had a chance to think on the question further since our brief in-person chats about it more than a year ago.

[ROBERT-MCDOWELL]

thanks for your answer. Meanwhile are experiments as a browser extension can be done to start in practice and test security and performance?

[GrumpyOldTroll]

We have a demo fork of chromium that can be built on osx & linux that has the basic receive functionality implemented, when run with a command-line flag: https://github.com/GrumpyOldTroll/chromium/tree/multicast_new/content/browser/multicast

It can't be done as an extension (as far as we know) because it uses low-level network functionality that is not available in the base browser implementation.

We're currently working on getting a patch based on our edits in this fork checked into chromium, but with us being new contributors and the patch being complicated enough that it's hard to review, we're hitting a few temporary challenges that we hope to get past over the upcoming few months, given enough perseverance.

Also, the authentication part and even the security basics (e.g. fuzz testing the rpcs) are not implemented yet, so there is still significant known dev work to do before the security is up to par.

For now, interested researchers should contact me at jholland@akamai.com if you'd like to get an early-access binary and/or discuss your use cases offline, and I'll try to post an update to this issue after an easier way to experiment with it becomes publicly available. (We have given a few trial partners these early-access binaries, but have not published them for general use, though we may consider doing so if our efforts to get a checkin into chromium take much more than a couple of months.)

[ROBERT-MCDOWELL]

ok Jake thanks for the details. will contact you directly. thanks.

[GrumpyOldTroll]

Update: A W3C Community Group to incubate this to the point of getting it into WebTransport has now been proposed: https://www.w3.org/community/groups/proposed/#multicast

Please support its creation if you'd like this to happen, and if you're able please join and contribute.

[GrumpyOldTroll]

Also, the binaries mentioned in late Jan are now regularly updated and posted to the fork we're carrying here: https://github.com/GrumpyOldTroll/chromium_fork

HTH.

[ROBERT-MCDOWELL]

Thanks Jake, I relay this good news to those interested.

[brettsheffield]

Update: A W3C Community Group to incubate this to the point of getting it into WebTransport has now been proposed: https://www.w3.org/community/groups/proposed/#multicast

Please support its creation if you'd like this to happen, and if you're able please join and contribute.

Great to see this moving forward. How does one get involved?

[ROBERT-MCDOWELL]

@brettshefield open an account at w3.org and click on "support this group"

[brettsheffield]

@brettshefield open an account at w3.org and click on "support this group"

Ok - thanks.

[ROBERT-MCDOWELL]

@GrumpyOldTroll I saw the group is for multicast IP, is multicast Application Level a different section to work on?

[GrumpyOldTroll]

Multicast Application Level is the phase 2 work in the charter. Case studies, use case descriptions, and performance analyses on application level work is welcome but protocol design is out of scope because that's traditionally IETF's domain (especially because of considerations like congestion control). But documenting the properties of both open specs and proprietary ones and their applicability to various use cases is in-scope and very welcome.

[GrumpyOldTroll]

Sorry, maybe I should clarify first: It depends what you mean by Application Level Multicast. If you mean reporting on applications that use IP multicast, that's in-scope. But on a search I've remembered just now that some people have been using the term for unicast connections thru distributed nodes, e.g. https://www.usenix.org/legacy/events/usits01/full_papers/shi/shi.pdf.

This kind of overlay-based multicast-like distribution tree via unicast connections is out of scope for this group. Application-level protocols that are designed to run over either could still be examined, but the focus for this group would be in how it does for IP multicast, according to the current charter. If there's another group working on that, we should probably add them to the liaison list though, because the APIs could have some common pathways...

[brettsheffield]

I assume the focus will mainly be on IPv6 multicast?

[ROBERT-MCDOWELL]

@GrumpyOldTroll I agree, thanks to clarify. @brettsheffield I'm almost sure that IPv4 and IPv6 will be supported.

[GrumpyOldTroll]

@brettsheffield the intent is to support both IPv4 and IPv6. I guess if there is something that doesn't work for IPv4 and does for IPv6, it could be possible to narrow the scope to IPv6, but the intent is to handle either.

(There was also a suggestion floated to make a new DNS RRType that maps a domain name to an (S,G) and support that instead or in addition at the API level, which might not be a bad idea, but still the traffic should be ok as either v4 or v6 ideally.)

[brettsheffield]

This is one case where we could take a step forward and leave IPv4 behind. There are a lot more possibilities with IPv6 multicast - the much greater address space for groups being one, and the fact that IPv6 requires multicast. If we're aiming for multicast to be enabled at the IP level, I can't really see any good reason to tie ourselves to an outdated protocol.

Adoption of IPv6 has been lagging, due largely to any real business reason to deploy it. Multicast does things that unicast just can't (that's why we're here, right?) - multicast can potentially result in large $$ savings - we have a lever here to move the Internet forward and get IPv6 deployed along with multicast.

[ROBERT-MCDOWELL]

@brettsheffield as phone networks have to deal with old and new codecs, protocol and frequencies, internet, intranet and extranet must deal also with "outdated" protocol which for me is far to be dead.

[brettsheffield]

@brettsheffield as phone networks have to deal with old and new codecs, protocol and frequencies, internet, intranet and extranet must deal also with "outdated" protocol which for me is far to be dead.

Sure - unicast IPv4 isn't going away yet (unfortunately). However, here, to support multicast any network / ISP is going to need to make changes to support multicast, so why not enable the newer, better protocol? That way we get superior multicast capabilities, and unicast takes a step forward too in terms of IPv6 deployment.

Enabling IPv6 SSM multicast requires only a single setting to be enabled on routers and switch gear. Enabling IPv4 multicast requires more effort for less reward.

If we provide any support for IPv4 at all in this work, it should be clear that it's a second-class citizen, and we shouldn't let design decisions be held back by v4's limitations.

[ROBERT-MCDOWELL]

so why not enable the newer, better protocol? because there are many organization private networks using IPv4 only, The dilemma between developers wishes and reality is always a problem... .;)

[brettsheffield]

The dilemma between developers wishes and reality is always a problem... .;)

Indeed!

Doesn't stop me from trying to drag the Internet forward kicking and screaming. We need to kill off IPv4 if we ever want to move forward. Time for it to go the way of UUCP and Banyan Vines ;-)

BTW - are we moving these discussions onto W3C infrastructure? There's an irc.w3.org #multicast channel and a mailing list. Or do we want a video call to kick things off? @GrumpyOldTroll - I think this is your baby - whither art we bound?

[GrumpyOldTroll]

I'm gonna say killing off IPv4 is out of scope for this group. The goal is to get multicast working, and how much we worry about keeping IPv4 functional depends on how many senders, receivers, and network operators want it that way, IMO.

With that said, I agree with making sure IPv6 is also supported even for those who are not asking for it, because the future is already upon us and we don't want to be left behind, but cutting out IPv4 support seems like a mistake to me unless we encounter something that doesn't work without extreme measures. But unfortunately, more often it's still the other way around, and IPv6 is still the one that needs the extra effort to ensure there's a way to make it happen (most often with some device that's widely deployed and still doesn't have it yet).

I think it's important to remember that lots of people have been running some kind of walled-garden multicast for upwards of 15 years, and these are the ones most likely to consider enabling an extension to OTT multicast, and unfortunately some of their gear still doesn't have IPv6 working right, and we don't want them cut out if it's not necessary (which I think it isn't--I think almost everything here is IP version agnostic). I'm all for stuff like "try IPv6 first", but not for "don't accept IPv4".

[GrumpyOldTroll]

Regarding w3c venue: hilariously, due to a relatively convoluted approval path, although I was approved to propose the group, I'm not yet approved to join it inside the w3c system, so it's still pending for me. I'll hopefully be in on Monday.

I'm aiming to set up the inaugural meeting sometime in 6/21-23, and will send out a doodle poll to find a slot. Thanks for your patience :)

[GrumpyOldTroll]

(With that said, I'm on the multicast channel in https://irc.w3.org/ and will be checking it from time to time, and would love to chat.)

[ROBERT-MCDOWELL]

@GrumpyOldTroll wise and right answer for me as it takes care of the real world, past, present and future.