Main Page

Data Roads Foundation

All roads should lead to all people.

• "Information Surface Streets" (ISS) routing and protocols. 

• Open source hardware and software projects.
• A new set of networking protocols and routing methods, designed bottom-up as people-centric instead of institution-centric.
• Learn from existing IETF standards, but better suit or alter them to serve person-person communications first, and institutional communications last.
• More emphasis on both data security and privacy from the start.

• Data roads should be open and fair to everyone, but data vehicles are in complete control of the sender, especially the vehicle identity and contents.

• Router project: provides seamless path traversal from a dense Neighborhood Area Network (NAN) scale, to main street level Metropolitan Area Network (MAN) scale. 

• Provide a big enough address space (minimum 64 bit) and robust enough navigation to efficiently traverse a global-scale (WAN) mesh.
• Physical geographic routing analogies may be the most useful. 32-bit longitude and 32-bit latitude provide a 64-bit unique address value, assessed by fixed and confirmed physical position, instead of arbitrary central assignment. 
• Packet hop count survival based on distance, not arbitrary anti-loop counts. 

• Loops are prevented by destination reachability assessment only near the end of a route.

• Each routing node provides a minimum of 8 connections, for traversal in 8 (or multiple of 8) cardinal directions.

• More cardinal directions are useful (in multiples of 2), but an 8 cardinal direction minimum provides interesting parallels to raster graphics processing methods.

• Potentially enables GPGPU route processing techniques. A modern low cost gaming PC with 8 or more network connections could become a powerful ISS router.

• When directions of connections < number of connection links, multiple links in a single direction can be trunked, to help alleviate route congestion problems created by a lack of connection in an adjacent cardinal direction.
• 8 (and multiples 16, 24, 32, 48, 72, and 96) seems to be a "magic number" for commercial network hardware chip production.

• http://www.broadcom.com/products/BCM5682
• http://www.theregister.co.uk/2008/05/02/broadcom_interop_2008/
• http://www.fulcrummicro.com/products/focalpoint/index.htm
• http://www.intelcommsalliance.com/kshowcase/view/view_item/bc21d64da6d22d4daa7ca667f78846ec267fad36
• http://www.broadcom.com/press/release.php?id=s453172
• http://www.aristanetworks.com/en/products/7500series/technology

• Home Area Network (HAN)-ISS gateways designed for all residential or stand-alone property uses. 

• Can and should be embedded in any Internet direct access device.
• Supports continuous address space provided for trivial ISS-HAN traversal.

• 64-bit geographic address space allows roughly one unique address per each square centimeter of the Earth's surface.
• HAN "subnet" range(s) determined by lot size and convex space corners.

• Last-chance whitelist and blacklist "firewall" control point.
• Allows NAT and port obfuscation for HAN-ISS transmission conversion.
• The most trusted ISS node for HAN-owned devices and security policy.
• Negotiates web-of-trust (WoT) relationship values with all directly-linked neighbor ISS nodes.
• More distant WoT nodes and ratings are all provided by the confirmed HAN owner manually.

• Support efficient routing on cheap hardware, via ad-hoc protocols with limited network state knowledge, i.e. GPSR.
• Allow a variety of routing capability levels throughout the ISS mesh network.

• The most trivial case routing nodes can assume that received traffic from one direction is intended to be pushed to the connected node in the most opposite direction.

• This can be done via consistent wiring standards alone, aided via junction connection labeling by cardinal direction.
• Trivial case junctions do not get labeled as routing nodes. They are treated more like wiring junctions or signal distribution amplifiers. This treatment may be the literal truth in many deployment scenarios.
• Trivial case junctions do not receive routable addresses, or their address is ignored until a minimum "dumb" router state can be achieved by a node. 

• "Dumb" store-and-forward router nodes can read the destination address in a packet header, and blindly choose from any active connections in roughly the same cardinal direction as the destination.

• Truly "dumb" router nodes merely forward packets to "smarter" nodes in the current best-fit cardinal direction for each packet.
• "Dumb" forwarding may be used as the default routing method when/where it best serves latency requirements.
• Even current low-cost consumer grade off-the-shelf (COTS) network hardware with 8 or more connections should be able to handle "dumb" forwarding.

• "Smart" nodes have a comprehensive knowledge of all mesh nodes comprising the interior of at least one local convex hull, with sufficient edge node information for efficient traversals into adjacent convex hulls.

• Cusps, averages, and deltas can be used to compress knowledge about a convex hull mesh, without having to store discreet data about every single node or link.

• Convex hull region cusps and edges that are created by physical border disconnection issues are good places to install "Smart" routing nodes and WAN gateways.
• When/where convex hull regions are defined more by router memory limits than edge border disconnections, the smartest router nodes will tend to reside in the center of their known convex hull region(s). This property makes it easier to estimate the position of the smartest router nodes in adjacent convex hulls, even when they are outside the current known region.

• "Intelligence" rating in a routing node is judged by how large a convex hull mesh map it can store. 

• Even the dumbest routing node can store knowledge about itself and all ~8 immediate linked neighbors, comprising a filled octagon.

• Any retail COTS smart (marketing term) Layer 2+ switch or router sold today should have sufficient hardware to far exceed "dumb" node requirements.

• The smartest possible useful node is one that can store a world-wide map of all convex hulls, comprising all terrestrial mesh nodes, including gateway positions and metrics.

• Any commercial router with IPv6 BGP routing capability sold today should be able to handle efficient ISS routing over Earth-sized meshes. 

• Faster memory and more processing power would just enable lower latency routing decision algorithms, and deeper suggested redirect lists.
• Storage may allow retaining knowledge of network state changes over time, for later analysis into cyclical heuristic prediction of near-future network state changes.

• A modern data-center hardware router with diverse connection link types could simultaneously handle multiple ISS overlay meshes, matching "best-fit" CoS metrics to each packet QoS by mesh scale and link medium capability.

• Smart nodes can choose to fork routing jobs off to dumber sub-processes and neighbor nodes, depending on current local traffic loads, to minimize latency.
• Video game AI navigation principles may be useful for "limited sight" and "aggregate terrain assessment" mesh routing situations.
• Packets can be re/encapsulated by smartest router nodes into redirection list header packets, which provide guidance for defined dumber downstream nodes.

• The smartest nodes in a given path thus give directions to packets originating from nodes unfamiliar with local convex hull territory.

• Each smart route node closer to the destination node is considered to have better route "expertise," due to closer proximity to destination node connections. 

• Mesh connection map data quality is imbued with a natural time decay, due to time-delay of state update transmissions, and higher link hop count by farther distances.

• Encryption provided at application, transport, and link layers.
• Sender anonymity.

• Destination-only address(es) in packet headers, and encrypted packet body contents.
• Encrypted sender address, decrypted only at destination node.
• Blind response packets sent on same route where the original requesting packet was received from, in the opposite direction. 

• No node has specific knowledge of the sender address, just the direction.
• Response packet alway stops at original sender node, but the sender node can pretend to send it on randomly further to avoid detection.

• Receiver anonymity. 

• Intended receiver captures packets mid-stream via intentional "overshoot" routing, and pretends to send it on. This is only possible on some trivial routes or bottlenecks.
• Routing given a vague direction only, with no destination address provided. 

• This method should prepare to incur high packet losses, unless aimed at a wide area service cluster. 
• Traffic appears similar to multicast service subscription-by-direction data.

• "Matryoshka doll" capsule route obfuscation.

• Redirection list capsule packets, with key-based node receipt. 
• Randomized excess redirection headers serve to obfuscate the true recipient, even when unencrypted.
• Results in destination node ignoring further redirection header entries.
• All but the next-closest recipient in the redirection list can be encapsulated and/or encrypted.

• Dynamic node service provision and advertisement protocols. 

• Service ID and URI consistency handling for multi-node clustered service protocols.
• Service or URI contention handling via key resolution, with neutral arbiter priority assignment.
• Priority given to nodes in closest local convex hull mesh.
• Dynamic service mirror and caching-forwarder offers, primarily from nodes in web-of-trust (WoT).

• Arbitrarily deep hierarchy of service forwarding and redundancy, by successive WoT member nodes. 

• Provides Freenet-alike service redundancy, obfuscation, and plausible deniability where desired. 

• Routing protocols are link medium agnostic, wired or wireless.

• CoS metrics are tested and stored upon initial link connection. 

• These metrics will naturally vary on medium used, and revise over time.

• ISS-IPv4/6 gateways for "legacy" Internet communications.

• BGP subnet route services with "best metric" advertisements.
• Per-subnet CoS estimates, including wholesale bandwidth charge estimates.
• Expandable Storage Area Network (SAN) access on trusted ISS nodes for caching data. 

• Cache, but never log.

• NAT traversal, and/or anonymous port state traversal. 

• Dynamically set by each client's  ISS gate portal request parameters.

• ISS-Mobile mesh gateways for mobile device communications.

• Mobile nodes will have different link characteristics and timing.
• Mobile nodes require an emphasis on client node power efficiency.
• Mobile nodes require efficient fixed gateway hand-off methods.
• Mobile mesh node links are far less reliable over time.
• Mobile nodes are innately wireless, and only temporarily fixed, and thus defy fixed addressing schemes.

• 32-bit geographic point with 16-bit directed vector prediction based temporary addressing could be a viable method, with time-decay on address trust value.

• Anonymization of mobile device MAC via address translation at gateway.
• Mobile devices should assist hand-off and route forwarding by advertising last known gateway connection list to new gateways. 
• Location assist via multi-gateway signal triangulation, provided only when specifically requested.
• Mobile devices are able to choose between nearby gateways based on known web-of-trust (WoT) ratings.
• Mobile devices will tend to send lots of requests to the owner's HAN via encrypted end-to-end tunnels.
• ISS-Mobile device ad-hoc routing may be a viable sub-project of the primary fixed ISS router project.

• Multicast send protocols.

• Directional aggregate (anonymized) subscription (whitelist), un-subscription, and active blocking (blacklist).

• All protocols allow time-decay based directional blocking (blacklist), to help prevent and diffuse DDoS attacks. 
• Nearest-node route automated security assessment, via web-of-trust (WoT) rating systems, assessed per subscriber privately.

• Automated acceptance of a neighbor node's blacklist and whitelist settings, depends on WoT rating and distance-decay parameters.
• Core service acceptance and resolution (i.e. Secure DNS) depends on WoT rating, then distance.

• Cost of Service (CoS) calculations applied to each link choice in a given route.

• Bandwidth costing metric (data set size).
• Speed costing metric (latency).
• Security costing metric (anonymity, trust, encryption layering).
• Reliability costing metric (jitter, loss).
• Provision billing cost metric (monetary, billing, maintenance expense).

• Some QoS reliability requirements handled via parity-encoded and striped data sent over multiple parallel routes in dense meshes.

• Redundant Array of Inexpensive Routes (RAIR). RAIR# ~= RAID#

• RAIR0: Split data over multiple parallel routes.
• RAIR1: Mirror data over 2 or more routes.
• RAIR3: Stripe data over multiple parallel routes, with a dedicated parity route.

• (Probably only useful when one route is consistently more reliable than the others)

• RAIR5: Stripe data over multiple parallel routes, with parity data on a different route each stream segment.
• RAIR6: Stripe data over multiple parallel routes, with redundant parity data on 2 or more different routes.
• Combine 2 of the above for obvious desirable effects -- best akin to RAID10, RAID50, or RAID60.
• Increase total redundant parity or mirror route paths based on packet loss increases.

• Data Roads Scholarship

• Awards for best research in people-centric networking.
• ISS Killer-app contests.
• Only awarded for open source, open standards, and openly accessible research.
• If any patents are allowed, all patents must be assigned to the Foundation and pooled defensively.

• Grant programs for regional Internet Service Cooperatives.

• Grantees must use some form of stable ISS routing on their network, and provide testing nodes.
• Grantee upstream providers must use open access, non-discriminatory, and wholesale provision (whenever a choice is possible).
• Grantees must take a basic oath of service.
• Low income membership subsidies, only in certified Grantee Cooperatives' regions.
• Give-one Get-one (GOGO) style hardware distribution.

• Spin off (subsidiary or independent 501(c)(4)): American Data Drivers' Club

• Analogous to Automobile Clubs, except this club is for servicing and maintaining "data driving equipment."
• No member has to be a networking or computer expert, because the club provides all needed expertise.
• The club is paid only to work in the club members' best interests. All club members have a democratic vote.
• Rate, certify, and recommend "network mechanics."

• Certified and branded partners take an oath of service.

• Partner exclusively with independent mechanics and open access or non-profit network providers.
• Enforce service transparency requirements, on behalf of club members.
• Discounts and promotion programs.
• Travel related foreign network access provision.
• Brokerage for ancillary services.

• Spin off (subsidiary, independent 501(c)(4), or international group): Data Driver's Club Federation

• Consolidate services shared between regional Data Driver's Clubs, perhaps even internationally.
• Member clubs must pay administrative dues, pass shared certifications, and take an oath of service.

• Spin off (subsidiary or independent 501(c)(12)): National Network Cooperative

• IPv4, IPv6, and ISS transit over a national long-range backbone mesh.
• Advisory bodies. 
• Shared services provision. 
• All downstream Cooperative member organizations must take oath.

• Service transparency.
• Resident open access (timeline provided at minimum).
• Network neutrality provisions.

• Spin off (international organization): International Network Cooperative

• IPv4, IPv6, and ISS transit over an international world-wide backbone mesh.
• Members comprised of various National Network Cooperatives.
• Possible cross-over projects with ICANN and IETF, but much more oriented toward bottom-up member control and negotiation of the world-wide ISS mesh links.

• Much less central control of ISS network assignments and service deployment methods. 

• ISS networks are defined by their use of ISS routing methods, not by organization membership.
• All downstream Cooperative member organizations must take oath.

• Membership and service transparency.
• Non-discriminatory open access to membership who are willing to take a similar oath (timeline provided at minimum).
• Network neutrality provisions.