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.