This post outlines the design for a new network protocol with a mesh topology called the IsoGrid.
Layer 0: Physical Layer
- Options include, but are not limited to:
- Ethernet, ATM, USB, etc.
- Tunnels through other networks (like the TCP/IP Internet, etc.)
Layer 1: Link Layer
- Defines how nodes directly communicate with each other across links
- Defines how a µPkt can be sent between two nodes
- Provides for mesh-wide frequency synchronization
- The IsoGrid does NOT mandate a globally-required protocol at this layer
- The IsoGrid does impose generic requirements at this layer
Layer 2: Network (µPkt) Layer
- Defines the extensibility model for µPkt types and µRoute types
- Defines how the network routes µPkts across the IsoGrid
- Defines how nodes send credits in exchange for forwarding µPkts
Layer 3: Transport (IsoStream) Layer
- Defines how the network uses source routing for Isochronous Streams (IsoStream)
- An IsoStream is switched at the word level, one word at a time
- Defines how nodes send credits in exchange for switching IsoStreams
Layer 4: Session (EccFlow) Layer
- Defines how remote nodes use IsoStreams to safely and reliably communicate with each other over an arbitrarily long time period
- Forward Error Correction coding, safety, and multi-path segmentation
- Defines how nodes use the network transport to distribute routing information
Layer 5: Application Layer
- Globally-Scalable mesh mapping and routing using HashMatchLogMap (HMLM)
- Distributed content addressable storage (CAS)
- Distributed self-certified naming using GetNodeInfoFromLocatorHash
- Higher Layers: All the normal protocols you would expect to run on networks
IsoGrid vs. TCP/IP Comparison
|Application||SSH, FTP, HTTP, etc.
|Session/Transport||TCP, UDP, etc.||EccFlow
|Link||Point-To-Point, Ethernet, subnet Broadcast, token ring, ATM, etc.||Point-To-Point only, Isochronous USB, ATM, Point-to-point Ethernet.|
|Physical||Any||Point-To-Point only: Communication mediums that have collisions aren’t well suited to IsoGrid|
How it works
The IsoGrid is a mesh network that supports routing of one-way isochronous streams (IsoStreams) and small packets (µPkts). In order to provide isochronous streams, the IsoGrid runs with a synchronized frequency, very similar to the way an electrical grid runs on Utility Frequency (except much higher frequency). The source provides a series of route instructions to be used at each hop (Source Routing). Each switch along the way uses its route instruction to establish the IsoStream connection. The µPkt that starts a connection defines the length of the IsoStream, and how many credits to send per word. The IsoGrid network and transport layers are optimized to support the IsoGrid session layer (EccFlow) which fragments the data, applies a forward error correction code, and sends the data over many paths across the network.
Credits and Micro-Payments
In order to avoid a tragedy of the commons, the IsoGrid allows for exchanging credits between neighbor nodes so as to pay for the data sent or processed. This allows payments to be made among neighbors instead of having to have a centralized payment processor.
In the IsoGrid model, each node owns its outbound links (but not really its inbound links), its CPU hardware, its storage, etc. Each node SHOULD charge credits for use of those resources. Each pair of neighbor nodes SHOULD agree on the settlement instrument that will represent the value of a credit between themselves, and payment SHOULD be by simple agreement (there is no required third party).
Any settlement instrument is possible, but here are some examples:
- ACH transfer
Nodes MAY have different costs for different outbound links.
IsoGrid Secondary Limitations
No network is without limits. The design of a protocol standard necessitates making tradeoffs in order to meet the requirements. Here are some of the known limitations due to the design of the IsoGrid Protocol:
- Links that use a shared physical medium (ex: those with collisions) aren’t well suited to be used by the network (too much latency).
- The IsoGrid is best suited for running on top of physical layers that have exclusive access to the underlying communication medium. Like fiber, copper, and point-to-point wireless such as 60 GHz
- Highly mobile nodes that want to offer isochronous data transit services might have a harder time competing against stationary nodes (because route tracking across transient links might not be scalable)
- A single IsoStream can use no more than the fastest available slot along a route
- However, an endpoint can create multiple connections such that nearly 100% utilization with EccFlow is possible
- Low-rate connections have higher latency
- Half-Duplex links not supported (except with unacceptably high latency)
- Streams through nodes that move will have non-trivial buffering/timing requirements
- The faster it moves, the more demanding the requirements
- New Links (for example, link tunnels) could take a (longer latency) three-way handshake (and a credit cost) for remote nodes to be able to effectively use the new links
Discussion is at Hacker News!