multicast support

[RubenKelevra]

Akamai ist currently working on a draft for multicast through the internet.

I'm sure it would be nice to have support in IPFS for this. It would be nice if the IPFS team could take part in the discussions and make sure the standard is compatible with a distributed approach to spread traffic many peers are interested in, like live video streams.

The current status:

20200530_Holland_Ip_Multicast_Next_v1.pdf

Source: https://storage.googleapis.com/site-media-prod/meetings/NANOG79/2209/20200530_Holland_Ip_Multicast_Next_v1.pdf

[autonome]

Thanks @RubenKelevra. Being at least present in standards conversations like this is really important for long term adoption of IPFS. Even if it's not adopted in specific cases, putting it forward as a potential solution will gain socialization of these architectural approaches and also a view into the use-cases where IPFS falls down.

@jacobheun is setting up a tracking issue for the type of metrics infra we'd need to be able to do things like measure n scenarios and measure perf and transfer costs for them. That will allow us to be able to stack up against centralized network solutions and have a conversation about the relative costs and trade-offs with groups like this.

@RubenKelevra are you currently involved in the multicast work?

[RubenKelevra]

@RubenKelevra are you currently involved in the multicast work?

Nope

[RubenKelevra]

@autonome I'm not really sure how "open" clients could subscribe or send data to multicast addresses. But in case there's a (sufficient large) IP block allocated for IPFS usage, the DHT nodes, which work as servers could use the host part of those addresses to subscribe to their "publish" part of the DHT, based on their public key.

They would need to check how many nodes are behind each multicast IP to be able to reduce the outgoing traffic in a probabilistic way to respond as a "cluster" with 2-3 responds per request.

This would reduce the amount of delay for DHT requests massively, since there's no management, like requesting the IPs for the part of the DHT at all.
DHT servers would connect to the requesting node with a zero round-trip QUIC connection, reducing each DHT request to one round-trip to the nearest DHT node.

Streaming could also be a quite interesting usecase - but the massive amount of traffic of legit traffic could make it hard to control this usecase against DDoS attacks - so maybe we need a kind of blockchain for this, where the network agrees on or against a legit usecase based on for example a bitcoin transaction with the public key or a node.

Not really sure about that.