search

vacp2p / research

Thinking in code
MIT License
62 stars 4 forks source link

Research: Discv5 feasibility #15

Closed decanus closed 4 years ago

decanus commented 4 years ago

The purpose of this feasibility study is to investigate discv5s ability to function efficiently on resource restricted devices. The goal is to be able to judge both the bandwidth consumption and the ability to function within small windows of connectivity.

Acceptance Criteria

This feasibility study looks at various problems:

It is supposed to provide insight on all of these problems allowing for us to form a conclusion on discv5s viability.

Method

The testing should be kept fairely simple, the configurable paramters are the following:

A discv5 DHT should, n amount of nodes should be generated and added to the DHT of which there are an amount of nodes that fit the needle description. A mobile client is simulated that connects to the DHT in short bursts indicated by window. Bandwidth should be recorded while connecting and disconnecting and synchronizing packets. It should also be checked how many round trips are required to find the specified needles.

Notes

decanus commented 4 years ago

ping @oskarth & @kdeme for comments

oskarth commented 4 years ago

Re topic radius estimation issue (h/t Jacek) https://d.n0.is/pub/doc/gnunet/gnunetbib/cache/2012_5.pdf

kdeme commented 4 years ago

Some further (perhaps obvious) parameters that might be considered as they will influence the test:

Another item that is important for mobile devices is that the IP-address will change more often. This makes the IP-address registered in the ENR not so useful (if you even manage to get the external one), or it needs to get updated very often, but even then it will take a while to get propagated over the network. Practically this will probably mean that for devices that are briefly online, they will have to initiate contact to peers mostly and will not be able to receive as much incoming communication.

Also, currently it is advised in the specification to link a "session" (shared secrets after handshake) to a nodeid + ip addres + udp port. This means that for each change of IP-address, a mobile device will have to renegotiate handshake with its peers. This too might end up costly for mobile devices.

oskarth commented 4 years ago

Adding to April milestone. That doesn't mean it should take until end of month, IMO we should be able to timebox PoC to a week, create follow up issues, do a write up of results, and then call it a day. That's roughly what was needed for https://vac.dev/feasibility-semaphore-rate-limiting-zksnarks

decanus commented 4 years ago

So as discussed on the call yesterday, we will test this without topic stuff too. This will allow us to measure bandwidth and allow us to see what it would be like if we run discv5 in isolation. @arnetheduck believes this could be a solution, in order to test that feasibility it should be checked how easy it is to pollute the DHT by running an ethereum node on the same server as a waku node.

oskarth commented 4 years ago

Perhaps we should clarify the issue, as I took it to be implicit: the problem isn't to see if mobile nodes can be useful for others in Discovery v5. The problem is if Discover v5 can be useful for mobilephones to find nodes they care about, under the restrictions of (a) short connection windows (b) possibly few nodes providing the service they care about (how many).

arnetheduck commented 4 years ago

we can probably quantify it mathematically how much churn discv5 can support (ie average "refresh" time etc)