ultralight-beam/specs

Ultralight Beams MANET specification

specs's Issues

Reliability: MVDS over UB

Problem

Due to the routing in our MANET, we have very unreliable data consistency which could result in messages not reaching their destination.

Solution

We run MVDS over Ultralight beam in order to ensure message delivery.

ACKs are returned whenever node N has done its duties which are either broadcasting the message to a given service, or sending it to node N + 1.

Routing: With or Without Target

Problem

Due to the fact that our MANET is supposed to handle various different scenarios we also have different routing requirements, for example in a chat context messages should be routed to a specific target as fast as possible. However when we are broadcasting ethereum transactions a flooding type system may be perfectly legitimate.

Solution

Allow for various routing methodologies that can messages can either be sent to a specific target, service provider or broadcasted within the network. This should also affect metering, messages that affect less nodes should cause less to be "metered".

Acceptance criteria

Nodes are able to receive messages in various means, being sent them directly or receiving them through broadcasts. Nodes should also provide "static" identifiers in order for messages to be able to be forwarded to them directly.

Identity

Problem

Currently in the UB.swift the node ID is based on the on the Transport. This isn't optimal as there is no verifiability that a message really originally came from a certain node. Any malicious node could change who the sender was.

Solution

Nodes should hold private keys with which they sign to ensure that they really are the original sender of a message, this means no middle node can change the original sender.

Notes

• https://github.com/libp2p/specs/blob/master/identify/README.md
• https://github.com/libp2p/specs/blob/master/peer-ids/peer-ids.md

Versioning: Version Negoation

Problem

Currently there is no version negotiation between clients. This means that clients may try communicating to incompatible clients and fail.

Acceptance Criteria

Design a Handshake that includes version negotiation so clients communicate correctly.

Topics in Messages

Problem

Currently, in the current CoreBluetooth Transport, we communicate all message over the same Characteristic. So, to differentiate between message types, we need additional processing (decoding headers) to determine if the received message is something we care about. Note that Characteristics are a Bluetooth specific concept.

More research is needed w.r.t. topics and messaging to ensure that we don't pollute the network.

Accounting: Bandwidth metering

Problem

1. Leeches: Some nodes put too much of a burden on the network
2. Capacity: Some nodes are helping nodes by relaying messages but they have limited capacity

Solution

Keep track of how much each node contributes and takes from the network based on local information. Similar to Bittorrent seed ratio.

Acceptance criteria

Detect, store and display bandwidth UP and DOWN for each connected peer. This can for example be stored to an in-memory DB and printed to STDOUT at some interval.

If bandwidth can't be directly detected, this may be approximated with message count.

Not in scope

This issue is purely about the accounting aspect. Explicitly out of scope are:

• Incentives build on top of this
• any form of settlement

Consequences such as:

• disconnects
• feedback of capacity
• tit for tat / throttling strategies a la Bittorrent

are also out of scope, but can be natural follow up issues to this.

Notes

• It might be useful to distinguish between originating sender and relayer in terms of who acts as a cost to the network
• If there are other limited resources identified outside of BW, these can also potentially be limited (disk/computed/connections/etc)

Misc:

• https://ethersphere.github.io/swarm-home/ethersphere/orange-papers/1/sw%5E3.pdf
• Bittorrent game theory / economics specs
• Adaptive nodes idea