Closed decanus closed 4 years ago
ping @oskarth & @kdeme for comments
Re topic radius estimation issue (h/t Jacek) https://d.n0.is/pub/doc/gnunet/gnunetbib/cache/2012_5.pdf
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.
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
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.
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).
we can probably quantify it mathematically how much churn discv5 can support (ie average "refresh" time etc)
The purpose of this feasibility study is to investigate
discv5
s 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
discv5
s viability.Method
The testing should be kept fairely simple, the configurable paramters are the following:
nodes
- indicates the amount of nodes.needles
- indicates the amount of nodes which areneedles
in ourhaystack
or set of nodes.window
- indicates the window size in seconds for the searching node to be online.A discv5 DHT should,
n
amount ofnodes
should be generated and added to the DHT of which there are an amount ofnodes
that fit theneedle
description. A mobile client is simulated that connects to the DHT in short bursts indicated bywindow
. 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 specifiedneedles
.Notes
discv5
spec is currently in motion and always changing. Even though we have the nim implementation it may make sense to use the go-ethereum version for this reason.