Skip to content

[pre-HIP] High level LongFi overview #1

@JayKickliter

Description

@JayKickliter

Before writing the first draft of LongFi, I'd like for this issue to serve as a place to ask a few high-level questions to help steer the direction of the protocol. It's become apparent that what we've been calling LongFi is two separate protocols, LowFi and HighFi. That leads to some questions. Please do not consider the answers below as gospel but as possibilities or outright bad ideas.

Glossary

  • LowFi: a low-level device ⟷ hotspot protocol

    • MAC layer
    • Likely contains encrypted, application/organization-specific payload
    • Specifies only cleartext fields required to allow hotspots to forward packets to their organizations' routers, and routers to send downlink packets to the correct device
    • Specifies device and hotspot behavior necessary for regulatory compliance
  • HighFi: a high-level device ⟷ router protocol

    • HighFi is to LowFi as TCP is to IP (ish?)
    • Can be application or organization specific
    • Where [de]fragmentation would live
  • ACK: a small and possibly data-free packet sent to acknowledge the receipt of a data-bearing packet

    1. A → B: a data-bearing packet
    2. A ← B: ACK
  • Uplink-ACK: a device ← router ACK in response to an uplink packet

  • Downlink-ACK: a device → router ACK in response to a downlink packet

Q1: Should LongFi specify any of the high-level protocol (HighFi)?

Initial offline discussions lean towards no if possible.

RATIONAL: Not specifying HighFi keeps LongFi simple and easy for third-parties to implement and understand. Additionally, it removes some risk of early decisions leading to unintended consequences.

Q2: What must LongFi specify to support HighFi?

It depends on the semantics of HighFi.

Q3: Does LongFi have the notion of connections (or sessions)?

It appears that LongFi requires sessions from device to its organization's router to operate in a trustless network.

Q4: If LongFi has sessions, how will that work with multiple hotspots?

Sessions are between a device and its organization's router, not with any hotspot in particular. It doesn't matter which Hotspot relays a device packet to a router.

Q5: What about downlink packets?

At a minimum, downlink packets are required for Uplink-ACKs.

Q6: What packets get ACK'd?

Uplink-ACKs are optional, and the conditions on which they are sent are HighFi/application-specific. For example, a device/user/org may only care about receiving Uplink-ACKs occasionally or in response to uplink packets containing critical payloads.

Downlink-ACKs seem to be mandatory. Downlink-ACKs are the only way for a router to detect malicious hotspots who charge for downlink packets but purposely drop them on the floor [1].

  1. Short of adding downlink-witness semantics to the network (which is worthy of further investigation).

TODO

Explain some things that came up at lunch today:

  • Dance Dance Revolution
  • Interaction between Downlink-ACKs and state channel (might need @Vagabond for that one)
  • Timeshare
  • Fallback slots

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions