What’s wrong with Internet Protocol?

This post is excerpted from the IsoGrid Protocol Specification v0.220. If you’d like to skip ahead, check out the spec!

The goal of IP was simple: Create an interop-protocol to connect the world’s networks. In this regard, IP has seen fantastic success. However, it wasn’t designed with socioeconomic goals in mind. In this day and age, when much of global commerce seems to rely on IP, it’s tempting to think that “Anything can run on IP, can’t you solve <X> with an overlay network or a blockchain?” But this would be akin to asking “Why not build the grid of roads only on top of the hub-and-spoke railway network?” When you think about the goals of the IsoGrid, you’ll see that this is a ridiculous proposal. It’s reasonable to try to rely on the existing IP infrastructure in the early phases of building its successor: Like the railways connected the cities prior to interstate highway systems.

Below are the problems I see in TCP/IP, along with the succinct requirements for my proposed network protocol that overcomes these problems.

High and Unbounded Latency

IP switches have to decode the entire header of a packet and then lookup routing tables before the packet can be routed to the next switch. But it’s worse than that, with IP, there are no guarantees that a given packet will be routed within a certain amount of time, or even serviced at all. If 10 packets arrive on 10 different links at the same time, and all 10 have the same destination link, then some of the packets need to wait for their turn. If the switch in this case only has buffers for 8 packets, then the last 2 are simply dropped.

The IsoGrid must provide bounded latency, and must provide low latency even as the network scales up.

Wasteful Underused Links

The majority of the links that comprise the Internet run at less than 50% utilization. This is related to the same latency/buffering problem above: In order to have even reasonable latency and low levels of packet-loss, links must typically be at less than 50% utilization.

The IsoGrid must allow for 100% link utilization without any increase in latency on existing connections and without suffering congestive collapse.

Limited Node/Switch/Hop Counts

IP has limits on the number of switches, nodes, and hops that make it ill-suited to an “Internet-of-Everything”.

The IsoGrid must have no limits on the number of participating nodes or switches, and routes must be able to have an arbitrarily large number of hops.

Low Redundancy

Typically, most consumers and businesses have only a single link to the IP Internet. This is often because there is only one high-speed provider at a given location. But also, Internet links are mostly paid for by link bandwidth, rather than the actual bandwidth used. It becomes cost-prohibitive to pay for multiple under-utilized links. Finally, IP itself doesn’t have good support for multi-path.

The IsoGrid must promote a mesh topology, where it actually makes sense to have more than just one link.

Centralization of Power, and thus Wealth

With the IP Internet, Economies-of-Scale make massive centralized services cheaper than distributed services (even if similarly massive). These centralized services seem to leave little room for a healthy middle class.

With the IsoGrid, distributed services should be cheaper to provide than centralized services. Distributed services can spread the benefits of a growing economy more widely.

Choke-point Surveillance and Censorship

Because the Internet and the services running on it are so centralized, powerful governmental systems have the clear capability to surveil and/or censor it.

The IsoGrid must scale up to have no Choke-points or Check-Points: You should be able talk with your neighbors without permission from a central authority.

Vulnerable to Disaster

Major damage to a critical building in most major cities is likely to bring down IP Internet service in the region for weeks or months. War, terrorism, earthquakes, or coronal mass ejections could all completely bring down the Internet, knocking out both local and long distance communications, hindering recovery efforts.

The IsoGrid must not rely on central hubs.

Tragedy of the Commons

The Internet is a Commons, where everyone is expected to behave themselves or face removal from the network by network admins. This is expensive to police. The biggest example of this is how it costs practically zero for spammers to send comment and email spam.

The IsoGrid must not suffer from Tragedy of the Commons, it should rely on micro-payments in exchange for accepting requests.

Discussion is at Hacker News!

Scalable Mesh Routing Update

Yay! Giant swaths of the IsoGrid protocol spec have survived over 2 months of me stewing over them! Over the next week or so, I may publish a few blog posts using some of the new content found in the spec.

Here’s the changelist for version 0.220 vs. 0.215:

  • Outlined the application layer protocols for the IsoGrid stack
    • Scalable mesh mapping and routing using HashMatchLogMap (HMLM)
    • Distributed content addressable storage (CAS)
    • Distributed self-certified naming using HostNameLocatorHash
    • GeoHash abstracted within LocatorHash
  • Specify how to use uPktWithReply to calculate the round trip exchange rate and PaymentCredits to an arbitrary destination at the network layer
  • Rename ‘ReplyPaymentCredits’ to ‘ReplyCostAccumulator’
  • IsoStreamRoute ‘words’ -> ‘tags’
  • Specify in more detail how multiple IsoStreamRoute tags can be packed in a single word
  • Remove vestigial ‘InBandSignal’ references
  • Simplified the EccFlow session options and specified them in more detail
    • ControlSession specified in more detail
    • Switch EccFlow from AES-GCM to AES-OCB
    • Describe plan for future EccFlow initialization protocol evolution
  • Remove multiple priorities from GetBestRoutes (how can you have multiple priorities?)
  • Expand on the Distributed Naming problem and the IsoGrid solution

Here’s the latest spec:
IsoGrid Protocol Specification v0.220.

CC0
To the extent possible under law, Travis.Martin has waived all copyright and related or neighboring rights to:
IsoGrid Protocol Specification v0.220.
This work is published from: United States.

This document is still an early draft. If you’d like to help improve it, check out the IsoGrid Forum.

The next generation of networking: A globally-scalable distributed mesh of streams

The TCP/IP Internet has:

  • High and Unbounded Latency
  • Wasteful, Underused Links
  • Limited Node/Switch/Hop Counts (no IoT support)
  • Low Redundancy
  • A Tendency to Centralize Power
  • Choke-point Surveillance and Censorship
  • Disaster Vulnerabilities
  • Tragedy of the Commons

What follows is a free and open proposal for a solution: A new globally-scalable network protocol with a mesh topology. Instead of being limited to traditional address-routed packets, the protocol uses source routing to set up bounded-latency isochronous streams avoiding the problem of congestive collapse. Once a stream is set up, the route is given a numeric name to support routing micro-packets (µPkt) both directions along the route. In order to support isochronous streams across the entire network, the framerate of every link is a power of 2 frequency relative to TCG time, this opens the door to many new scenarios that require precise relative timekeeping. Micro-payments in arbitrary settlement instruments, which are made ‘by simple agreement’ between each neighbor along a route, are used to pay for sending data across the network, avoiding the Tragedy of the Commons. Client endpoints are responsible for building up multi-path redundant link maps through the network, relying on the advertised 3D-Geohash locations of the nodes to track only a subset of nodes within a given area; providing scalability, redundancy, and wider distribution of power. Contrasted with TCP/IP, the new protocol stack’s layering model provides additional options for streams, packets, safety, reliability, robustness, latency, and extensibility. Most importantly, the entire protocol was morally designed with its socioeconomic side-effects as a guide.

IsoGrid Protocol Specification v0.215.


CC0

To the extent possible under law, Travis.Martin has waived all copyright and related or neighboring rights to:
IsoGrid Protocol Specification v0.215.
This work is published from: United States.

This document is an early draft. If you’d like to help improve it, check out the IsoGrid Forum.

uPkt IsoStream and EccFlow Spec Changes

As I previously promised, here are the big updates to the IsoGrid Protocol Spec.

This version includes:

  1. Major uPkt Network Layer updates.
  2. Major IsoStream Transport layer protocol specification using uPkt Network layer.
  3. More complete specification for EccFlow Session layer protocol.
  4. Removal of IsoGrid Headers (not needed anymore).

As always, if you’d like to discuss or contribute, head over to the IsoGrid Forum!

The requirements doc hasn’t been modified:
IsoGrid_Requirements_v1_002

The Spec has been updated:
IsoGrid_Protocol_Specification_v0_210


CC0

To the extent possible under law, Travis.Martin has waived all copyright and related or neighboring rights to:
IsoGrid Protocol Specification v0.210.
This work is published from: United States.

AnchorForMobile Pattern

I’m spending most of my spare time working on updates to the spec, here’s a preview of some of what I’ve been working on:

AnchorForMobile Pattern

It doesn’t seem possible to have scalable route determination with a mesh of switches that relies heavily on dynamic links. As such, long-distance data transport will mostly occur over switches with reasonably persistent links, or at least predictable links (like satellites). A cell tower or a Wi-Fi router are typical examples of switches with highly transient links, and as such, endpoints with highly transient links are generally just called mobile nodes. Fortunately, relying on highly transient links for only a few hops can be scalable. A simple way to achieve scalability is to allow for layers of indirection, where data flowing to and from a mobile node is routed through one or more persistent link tunnel(s) with stationary anchor nodes.

Each anchor node MAY:

  1. Answer the question: “Where is the mobile endpoint?”
    1. Which IsoGrid nodes is the mobile endpoint near?
    2. What are the best routes to get to the mobile endpoint?
  2. Provide credit payments as needed to sustain the mobile node’s outbound streams
  3. Provide a link tunnel to, from, or through the mobile node

In this AnchorForMobile pattern, the anchor node and the mobile node maintain an Session layer ‘flow’ between each other and use it as the link layer underlying an IsoGrid network link. This is only a suggested pattern, and the specific protocol does not need to be universally supported: The only requirement is that the mobile and anchor nodes MUST agree to use the same protocol.

Coming Soon: 1st Big Protocol Changes

It was bound to happen… And this is likely not the last time…

I need to make some big changes to the protocol in order to efficiently support some new ideas I came up with in the Transport Layer.

I’ve made big changes in the protocol before, but not since I published the spec. Fortunately, nobody seems to have read the spec all the way through yet!   Yay???   🙂

For anyone who happens to have read the spec or is planning to, this post summarizes the changes I’m working on.

  1. I came up with the simple idea to support µPackets in the un-allocated slots between IsoStreams. Since they’re required to be small, µPackets can have really low latency.
  2. I wanted to make Link Tunnels easy to run over an EccFlow, which have a dynamic word-rate. I found that it was a lot easier to support this with every slot having a single slot word-rate (the minimum word-rate for that link). µPackets used to start an IsoStream made this easier to support. This is also likely to make hardware implementations easier.
  3. Scaling up to higher word-rates is easy with a link-layer µPacket at the start of the IsoStream that defines the number of slots to use for the IsoStream.
  4. 16-bit words were too limiting and wasteful. 128-bit words are more useful and likely to be more efficient.
  5. In-band signals can mess up nicely timed word-rates. It’s easy to replace in-band signals with µPackets.
  6. Naming a route is a fantastic way to avoid having to send the route over and over again on IsoStreams. µPackets are great for naming a route using a relative slot number.
  7. µPackets can also use named routes!

None of these changes seem to have any big socio-economic repercussions. But let me know if you disagree and I’ll reconsider 🙂

I’ve got a lot of raw notes for these changes, but it’s not in the spec yet. I’ll be working on getting that done in the next few weeks.

Updated Requirements and Spec

Here are a few minor updates to the IsoGrid Requirements and the Protocol Spec (based on learnings from trying to implement it).

Additionally, I’ve included:

  1. A raw spec for a proposed route-learning mechanism
  2. A raw spec for a proposed Transport layer protocol to run on top of IsoStream Network layer protocol.
  3. More notes on how to bootstrap the IsoGrid in a world of ubiquitous TCP/IP.

If you’d like to discuss or contribute, head over to the IsoGrid Forum!

IsoGrid_Requirements_v1_002
IsoGrid_Protocol_Specification_v0_200


CC0

To the extent possible under law, Travis.Martin has waived all copyright and related or neighboring rights to:
IsoGrid Protocol Specification v0.200.
This work is published from: United States.

IsoGrid vs. IsoMesh

Yesterday I had a discussion on Hacker News about whether pure crypto research was more likely to yield the positive changes I’d like in the world relative to advances in networking technology/protocols. I’m admittedly very biased toward networking in this argument, but I’m definitely open to the possibility that I’m wrong. The primary argument that most folks seemed to use was that “mesh doesn’t scale”. I’m still looking for more details on this assertion. If anyone has a good proof that “mesh doesn’t scale”, I’d love to hear it! It could save me a lot of wasted effort: I could abandon my quest to create a scalable grid/mesh network.

However, I realized in this discussion that most people automatically gravitated toward the “Mesh” name for this concept, rather than the “Grid” name I had previously came up with. So I just grabbed IsoMesh.net and IsoMesh.org to compare to the current IsoGrid.org (I don’t have IsoGrid.net).

What do you folks think? Let me know in the Forum or send me an email at Travis dot Martin at this domain.

By the way, I’m working next on a few minor updates to the IsoGrid Protocol Spec (based on learnings from trying to implement it). After that, I’ll be trying to write up a spec for a proposed route-learning mechanism and then a spec for a proposed Transport layer protocol to run on top of IsoGrid Protocol. Finally, I’ll be providing a lot more details on my proposal for how to bootstrap the IsoGrid in a world of ubiquitous TCP/IP.

Requirements and Protocol Specification

Starting with the belief that technology can make the world a better place for everyone, this concept was developed in my spare time over the past few years.

But what does ‘better’ mean? A moral foundation was required:

Good:

  1. Respect and empowerment for the individual
  2. Economic Freedom
  3. Political Freedom
  4. Social Freedom
  5. Community, freedom to associate
  6. Diversity of {Thought, Government, Community, Genetics, Ecosystem, Consumption}
  7. Long-term Economic growth
  8. Long-term Technological growth

Bad:

  1. Overwhelming sameness
  2. Suffering, followed by death
  3. Death, Destruction, Waste
  4. Suffering

Eventually, I focused on network protocol design as a means to make the world ‘better’. Driven by the belief that decentralization can help promote more of the ‘good’ and help prevent much of the ‘bad’, I set about designing a truly distributed network. The first linked document is an attempt at defining and justifying the requirements. The second linked document is an attempt at defining a protocol.

Enough prototyping was done to show that the protocol is generally workable, but it is not ready for adoption.

The protocol specification is a very early first draft. I am conflicted on the one hand by my pride, knowing that I can make it better before releasing it. On the other hand, since I’m giving away the protocol as a gift to anyone wanting to use it for free, there’s no non-selfish reason to hold it back any longer. I’d love help making it better!

A note about contributing: Since this specification is released into the public domain, all contributions MUST be provided with no rights reserved.

If you’d like to discuss or contribute, head over to the IsoGrid Forum!

IsoGrid Requirements v1.001
IsoGrid Protocol Specification v0.100


CC0

To the extent possible under law, Travis.Martin has waived all copyright and related or neighboring rights to:
IsoGrid Protocol Specification v0.100.
This work is published from: United States.