Multicast bitswap query in local network

[RubenKelevra]

Checklist

• My issue is specific & actionable.
• I am not suggesting a protocol enhancement.
• I have searched on the issue tracker for my issue.

Description

I was wondering if a somewhat simple multicast group for the local network wouldn't be easier and lighter in terms of communication necessary than a local DHT.

If we're using mDNS, we are likely to be connected to all peers anyway. So sending a database around isn't really efficient, if we do bitswap queries to the connected nodes anyway … and then a DHT search afterwards.

Using a multicast group, we could avoid all this background chatter for the DHT and reduce also the bandwidth from n (where N are local nodes) to 1 for queries while also avoiding the DHT search requests on top.

The only limitation is encryption, as we would need to encrypt it for a group of keys instead of 1:1 encryption. Not sure if that's possible without a protocol change.

But I think sending the queries in plaintext to multicast would be the better option here. As by default, we would send all queries to all nodes which are connected to us – there's no real difference regarding privacy concerns.

Or we create a group key – but that's hardly more secure than chatting in plain text – if we allow anyone to join.

[Jorropo]

We already do that in the mdns layer.

I dont get what you are asking for would change to what is currently there.

[RubenKelevra]

We do currently the following:

• Send mDNS packages to discover local clients.
• Connect to them
• Create a LAN-based DHT database
• If something isn't found in the LAN-based DHT database, ask directly the locally connected clients via unicast

The proposal:

• Skip the LAN based DHT completely
• Create a dedicated multicast address and listen to it
• Convert the direct requests from unicast to the multicast address
• Requests received via multicast would be answered directly with the content via unicast

This would:

• Remove the need to keep track of all content in the LAN via DHT
• Remove all unnecessary background traffic associated with the local DHT
• Make all content of all nodes instantly available to the local network (no DHT delay)
• Avoid keeping LAN connections open all the time (just listen passively to the multicast address and dial if necessary)
• Reduce the outbound traffic in larger networks, as the switches will multiply the single multicast packages for us

[welcome]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[RubenKelevra]

@Jorropo thanks for the move! :)

[RubenKelevra]

@Stebalien if you got time, this might be interesting as the Lan-DHT functionality is AFAIK incompatible with the new Accelerated DHT Client. So instead of making it compatible, could this be used to make the communication lighter overall. :)

[Jorropo]

@RubenKelevra my understanding was that mdns broadcasted provider records, but it don't mb.

I don't think there is much to gain from this anyway, as we would likely not write a bitswap fast respond path, the node would need to do a full libp2p handshake anyway.
Having a high RTT protocol over LAN is not that bad of an issue, if you have an extra DHT hop is it really that bad ?

[Jorropo]

Lan-DHT functionality is incompatible with the new Accelerated DHT Client

We could dual DHT this fairly easy, we don't for some reason (on IPFS).
Should be a new issue like about that.

[RubenKelevra]

@Jorropo well, correct me if I'm wrong but the reconnect should be 0 RTT with QUIC. So if the connection gets dropped and there's a request coming in from one of the nodes on the LAN bitswap could initiate the connection and start responding to it without doing any round-trips.

I'm currently using IPFS in a home LAN/WLAn environment and it doesn't seem to perform very well:

I do have 10-40 GB of data in each ipfs node and the nodes need the data at different times. So one of the nodes should have the data already cached in most cases.

But like 90% of the time I'm not fetching the data from a LAN node but the Internet.

I was attributing this to the LAN DHT. Since the nodes are normal computers they tend to be restarted or taken off the WLAN and on again.

So the LAN-DHT is presumably most of the time not up to date, as the standard reprovide interval is 12 hours.

Asking just via multicast all nodes which are currently on the network would result in instant responses without the DHT needing to learn which blocks are stored where.

[BigLep]

2022-09-08 triage conversation: there are already complaints about mdns creating too much network traffic. This proposal will only create more. You are free to create a protocol that does what you want, but we don't see adding it to Kubo and go-bitswap.

Perhaps discussing this in a public forum (e.g., https://discuss.ipfs.tech/c/protocol/30) will get more engagement on the idea than as an issue in the go-bitswap repo.