Difference between revisions of "Main Page"

From Data Roads Foundation Projects
Jump to: navigation, search
 
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
<strong>MediaWiki has been successfully installed.</strong>
+
== Data Roads Foundation ==
  
Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.
+
'''All roads should lead to all people.'''
  
== Getting started ==
+
<ul class="c4 lst-kix_list_1-0 start"><li class="c12"><span class="c0">&quot;Information Surface Streets&quot; (ISS) routing and protocols.&nbsp;</span></li></ul><ul class="c4 lst-kix_list_2-1 start"><li class="c2"><span class="c0">Open source hardware and software projects.</span></li><li class="c2"><span class="c0">A new set of networking protocols and routing methods, designed bottom-up as people-centric instead of institution-centric.</span></li><li class="c2"><span class="c0">Learn from existing IETF standards, but better suit or alter them to serve person-person communications first, and institutional communications last.</span></li><li class="c2"><span class="c0">More emphasis on both data security and privacy from the start.</span></li></ul><ul class="c4 lst-kix_list_3-2 start"><li class="c1"><span class="c0">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.</span></li></ul><ul class="c4 lst-kix_list_2-1"><li class="c2"><span class="c0">Router project: provides seamless path traversal from a dense Neighborhood Area Network (NAN) scale, to main street level Metropolitan Area Network (MAN) scale.&nbsp;</span></li></ul><ul class="c4 lst-kix_list_4-2 start"><li class="c1"><span class="c0">Provide a big enough address space (minimum 64 bit) and robust enough navigation to efficiently traverse a global-scale (WAN) mesh.</span></li><li class="c1"><span class="c0">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.&nbsp;</span></li><li class="c1"><span class="c0">Packet hop count survival based on distance, not arbitrary anti-loop counts.&nbsp;</span></li></ul><ul class="c4 lst-kix_list_5-3 start"><li class="c3"><span class="c0">Loops are prevented by destination reachability assessment only near the end of a route.</span></li></ul><ul class="c4 lst-kix_list_4-2"><li class="c1"><span class="c0">Each routing node provides a minimum of 8 connections, for traversal in 8 (or multiple of 8) cardinal directions.</span></li></ul><ul class="c4 lst-kix_list_6-3 start"><li class="c3"><span class="c0">More cardinal directions are useful (in multiples of 2), but an 8 cardinal direction minimum provides interesting parallels to raster graphics processing methods.</span></li></ul><ul class="c4 lst-kix_list_7-4 start"><li class="c5"><span class="c0">Potentially enables GPGPU route processing techniques. A modern low cost gaming PC with 8 or more network connections could become a powerful ISS router.</span></li></ul><ul class="c4 lst-kix_list_6-3"><li class="c3"><span class="c0">When directions of connections &lt; 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.</span></li><li class="c3"><span class="c0">8 (and multiples 16, 24, 32, 48, 72, and 96) seems to be a &quot;magic number&quot; for commercial network hardware chip production.</span></li></ul><ul class="c4 lst-kix_list_8-4 start">
* [//www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
+
<li class="c5"> http://www.broadcom.com/products/BCM5682 </li>
* [//www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
+
<li class="c5"> http://www.theregister.co.uk/2008/05/02/broadcom_interop_2008/ </li>
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]
+
<li class="c5"> http://www.fulcrummicro.com/products/focalpoint/index.htm </li>
* [//www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
+
<li class="c5"> http://www.intelcommsalliance.com/kshowcase/view/view_item/bc21d64da6d22d4daa7ca667f78846ec267fad36 </li>
 +
<li class="c5"> http://www.broadcom.com/press/release.php?id=s453172 </li>
 +
<li class="c5"> http://www.aristanetworks.com/en/products/7500series/technology </li>
 +
</ul><ul class="c4 lst-kix_list_2-1"><li class="c2"><span class="c0">Home Area Network (HAN)-ISS gateways designed for all residential or stand-alone property uses.&nbsp;</span></li></ul><ul class="c4 lst-kix_list_9-2 start"><li class="c1"><span class="c0">Can and should be embedded in any Internet direct access device.</span></li><li class="c1"><span class="c0">Supports continuous address space provided for trivial ISS-HAN traversal.</span></li></ul><ul class="c4 lst-kix_list_a-3 start"><li class="c3"><span class="c0">64-bit geographic address space allows roughly one unique address per each square centimeter of the Earth&#39;s surface.</span></li><li class="c3"><span class="c0">HAN &quot;subnet&quot; range(s) determined by lot size and convex space corners.</span></li></ul><ul class="c4 lst-kix_list_9-2"><li class="c1"><span class="c0">Last-chance whitelist and blacklist &quot;firewall&quot; control point.</span></li><li class="c1"><span class="c0">Allows NAT and port obfuscation for HAN-ISS transmission conversion.</span></li><li class="c1"><span class="c0">The most trusted ISS node for HAN-owned devices and security policy.</span></li><li class="c1"><span class="c0">Negotiates web-of-trust (WoT) relationship values with all directly-linked neighbor ISS nodes.</span></li><li class="c1"><span class="c0">More distant WoT nodes and ratings are all provided by the confirmed HAN owner manually.</span></li></ul><ul class="c4 lst-kix_list_2-1"><li class="c2"><span class="c0">Support efficient routing on cheap hardware, via ad-hoc protocols with limited network state knowledge, i.e. GPSR.</span></li><li class="c2"><span class="c0">Allow a variety of routing capability levels throughout the ISS mesh network.</span></li></ul><ul class="c4 lst-kix_list_b-2 start"><li class="c1"><span class="c0">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.</span></li></ul><ul class="c4 lst-kix_list_c-3 start"><li class="c3"><span class="c0">This can be done via consistent wiring standards alone, aided via junction connection labeling by cardinal direction.</span></li><li class="c3"><span class="c0">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.</span></li><li class="c3"><span class="c0">Trivial case junctions do not receive routable addresses, or their address is ignored until a minimum &quot;dumb&quot; router state can be achieved by a node.&nbsp;</span></li></ul><ul class="c4 lst-kix_list_b-2"><li class="c1"><span class="c0">&quot;Dumb&quot; 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.</span></li></ul><ul class="c4 lst-kix_list_d-3 start"><li class="c3"><span class="c0">Truly &quot;dumb&quot; router nodes merely forward packets to &quot;smarter&quot; nodes in the current best-fit cardinal direction for each packet.</span></li><li class="c3"><span class="c0">&quot;Dumb&quot; forwarding may be used as the default routing method when/where it best serves latency requirements.</span></li><li class="c3"><span class="c0">Even current low-cost consumer grade off-the-shelf (COTS) network hardware with 8 or more connections should be able to handle &quot;dumb&quot; forwarding.</span></li></ul><ul class="c4 lst-kix_list_b-2"><li class="c1"><span class="c0">&quot;Smart&quot; 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.</span></li></ul><ul class="c4 lst-kix_list_e-3 start"><li class="c3"><span class="c0">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.</span></li></ul><ul class="c4 lst-kix_list_f-4 start"><li class="c5"><span class="c0">Convex hull region cusps and edges that are created by physical border disconnection issues are good places to install &quot;Smart&quot; routing nodes and WAN gateways.</span></li><li class="c5"><span class="c0">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.</span></li></ul><ul class="c4 lst-kix_list_e-3"><li class="c3"><span class="c0">&quot;Intelligence&quot; rating in a routing node is judged by how large a convex hull mesh map it can store.&nbsp;</span></li></ul><ul class="c4 lst-kix_list_10-4 start"><li class="c5"><span class="c0">Even the dumbest routing node can store knowledge about itself and all ~8 immediate linked neighbors, comprising a filled octagon.</span></li></ul><ul class="c4 lst-kix_list_11-5 start"><li class="c7"><span class="c0">Any retail COTS smart (marketing term) Layer 2+ switch or router sold today should have sufficient hardware to far exceed &quot;dumb&quot; node requirements.</span></li></ul><ul class="c4 lst-kix_list_10-4"><li class="c5"><span class="c0">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.</span></li></ul><ul class="c4 lst-kix_list_12-5 start"><li class="c7"><span class="c0">Any commercial router with IPv6 BGP routing capability sold today should be able to handle efficient ISS routing over Earth-sized meshes.&nbsp;</span></li></ul><ul class="c4 lst-kix_list_13-6 start"><li class="c9"><span class="c0">Faster memory and more processing power would just enable lower latency routing decision algorithms, and deeper suggested redirect lists.</span></li><li class="c9"><span class="c0">Storage may allow retaining knowledge of network state changes over time, for later analysis into cyclical heuristic prediction of near-future network state changes.</span></li></ul><ul class="c4 lst-kix_list_12-5"><li class="c7"><span class="c0">A modern data-center hardware router with diverse connection link types could simultaneously handle multiple ISS overlay meshes, matching &quot;best-fit&quot; CoS metrics to each packet QoS by mesh scale and link medium capability.</span></li></ul><ul class="c4 lst-kix_list_e-3"><li class="c3"><span class="c0">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.</span></li><li class="c3"><span class="c0">Video game AI navigation principles may be useful for &quot;limited sight&quot; and &quot;aggregate terrain assessment&quot; mesh routing situations.</span></li><li class="c3"><span class="c0">Packets can be re/encapsulated by smartest router nodes into redirection list header packets, which provide guidance for defined dumber downstream nodes.</span></li></ul><ul class="c4 lst-kix_list_14-4 start"><li class="c5"><span class="c0">The smartest nodes in a given path thus give directions to packets originating from nodes unfamiliar with local convex hull territory.</span></li></ul><ul class="c4 lst-kix_list_e-3"><li class="c3"><span class="c0">Each smart route node closer to the destination node is considered to have better route &quot;expertise,&quot; due to closer proximity to destination node connections.&nbsp;</span></li></ul><ul class="c4 lst-kix_list_15-4 start"><li class="c5"><span class="c0">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.</span></li></ul><ul class="c4 lst-kix_list_2-1"><li class="c2"><span>Encryption provided at application, transport, </span><span class="c13">and </span><span class="c0">link layers.</span></li><li class="c2"><span class="c0">Sender anonymity.</span></li></ul><ul class="c4 lst-kix_list_16-2 start"><li class="c1"><span class="c0">Destination-only address(es) in packet headers, and encrypted packet body contents.</span></li><li class="c1"><span class="c0">Encrypted sender address, decrypted only at destination node.</span></li><li class="c1"><span class="c0">Blind response packets sent on same route where the original requesting packet was received from, in the opposite direction.&nbsp;</span></li></ul><ul class="c4 lst-kix_list_17-3 start"><li class="c3"><span class="c0">No node has specific knowledge of the sender address, just the direction.</span></li><li class="c3"><span class="c0">Response packet alway stops at original sender node, but the sender node can pretend to send it on randomly further to avoid detection.</span></li></ul><ul class="c4 lst-kix_list_2-1"><li class="c2"><span class="c0">Receiver anonymity.&nbsp;</span></li></ul><ul class="c4 lst-kix_list_18-2 start"><li class="c1"><span class="c0">Intended receiver captures packets mid-stream via intentional &quot;overshoot&quot; routing, and pretends to send it on. This is only possible on some trivial routes or bottlenecks.</span></li><li class="c1"><span class="c0">Routing given a vague direction only, with no destination address provided.&nbsp;</span></li></ul><ul class="c4 lst-kix_list_19-3 start"><li class="c3"><span class="c0">This method should prepare to incur high packet losses, unless aimed at a wide area service cluster.&nbsp;</span></li><li class="c3"><span class="c0">Traffic appears similar to multicast service subscription-by-direction data.</span></li></ul><ul class="c4 lst-kix_list_18-2"><li class="c1"><span class="c0">&quot;Matryoshka doll&quot; capsule route obfuscation.</span></li></ul><ul class="c4 lst-kix_list_1a-3 start"><li class="c3"><span class="c0">Redirection list capsule packets, with key-based node receipt.&nbsp;</span></li><li class="c3"><span class="c0">Randomized excess redirection headers serve to obfuscate the true recipient, even when unencrypted.</span></li><li class="c3"><span class="c0">Results in destination node ignoring further redirection header entries.</span></li><li class="c3"><span class="c0">All but the next-closest recipient in the redirection list can be encapsulated and/or encrypted.</span></li></ul><ul class="c4 lst-kix_list_2-1"><li class="c2"><span class="c0">Dynamic node service provision and advertisement protocols.&nbsp;</span></li></ul><ul class="c4 lst-kix_list_1b-2 start"><li class="c1"><span class="c0">Service ID and URI consistency handling for multi-node clustered service protocols.</span></li><li class="c1"><span class="c0">Service or URI contention handling via key resolution, with neutral arbiter priority assignment.</span></li><li class="c1"><span class="c0">Priority given to nodes in closest local convex hull mesh.</span></li><li class="c1"><span class="c0">Dynamic service mirror and caching-forwarder offers, primarily from nodes in web-of-trust (WoT).</span></li></ul><ul class="c4 lst-kix_list_1c-3 start"><li class="c3"><span class="c0">Arbitrarily deep hierarchy of service forwarding and redundancy, by successive WoT member nodes.&nbsp;</span></li></ul><ul class="c4 lst-kix_list_1d-4 start"><li class="c5"><span class="c0">Provides Freenet-alike service redundancy, obfuscation, and plausible deniability where desired.&nbsp;</span></li></ul><ul class="c4 lst-kix_list_2-1"><li class="c2"><span class="c0">Routing protocols are link medium agnostic, wired or wireless.</span></li></ul><ul class="c4 lst-kix_list_1e-2 start"><li class="c1"><span class="c0">CoS metrics are tested and stored upon initial link connection.&nbsp;</span></li></ul><ul class="c4 lst-kix_list_1f-3 start"><li class="c3"><span class="c0">These metrics will naturally vary on medium used, and revise over time.</span></li></ul><ul class="c4 lst-kix_list_2-1"><li class="c2"><span class="c0">ISS-IPv4/6 gateways for &quot;legacy&quot; Internet communications.</span></li></ul><ul class="c4 lst-kix_list_20-2 start"><li class="c1"><span class="c0">BGP subnet route services with &quot;best metric&quot; advertisements.</span></li><li class="c1"><span class="c0">Per-subnet CoS estimates, including wholesale bandwidth charge estimates.</span></li><li class="c1"><span class="c0">Expandable Storage Area Network (SAN) access on trusted ISS nodes for caching data.&nbsp;</span></li></ul><ul class="c4 lst-kix_list_21-3 start"><li class="c3"><span class="c0">Cache, but never log.</span></li></ul><ul class="c4 lst-kix_list_20-2"><li class="c1"><span class="c0">NAT traversal, and/or anonymous port state traversal.&nbsp;</span></li></ul><ul class="c4 lst-kix_list_22-3 start"><li class="c3"><span class="c0">Dynamically set by each client&#39;s&nbsp; ISS gate portal request parameters.</span></li></ul><ul class="c4 lst-kix_list_2-1"><li class="c2"><span class="c0">ISS-Mobile mesh gateways for mobile device communications.</span></li></ul><ul class="c4 lst-kix_list_23-2 start"><li class="c1"><span class="c0">Mobile nodes will have different link characteristics and timing.</span></li><li class="c1"><span class="c0">Mobile nodes require an emphasis on client node power efficiency.</span></li><li class="c1"><span class="c0">Mobile nodes require efficient fixed gateway hand-off methods.</span></li><li class="c1"><span class="c0">Mobile mesh node links are far less reliable over time.</span></li><li class="c1"><span class="c0">Mobile nodes are innately wireless, and only temporarily fixed, and thus defy fixed addressing schemes.</span></li></ul><ul class="c4 lst-kix_list_24-3 start"><li class="c3"><span class="c0">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.</span></li></ul><ul class="c4 lst-kix_list_23-2"><li class="c1"><span class="c0">Anonymization of mobile device MAC via address translation at gateway.</span></li><li class="c1"><span class="c0">Mobile devices should assist hand-off and route forwarding by advertising last known gateway connection list to new gateways.&nbsp;</span></li><li class="c1"><span class="c0">Location assist via multi-gateway signal triangulation, provided only when specifically requested.</span></li><li class="c1"><span class="c0">Mobile devices are able to choose between nearby gateways based on known web-of-trust (WoT) ratings.</span></li><li class="c1"><span class="c0">Mobile devices will tend to send lots of requests to the owner&#39;s HAN via encrypted end-to-end tunnels.</span></li><li class="c1"><span class="c0">ISS-Mobile device ad-hoc routing may be a viable sub-project of the primary fixed ISS router project.</span></li></ul><ul class="c4 lst-kix_list_2-1"><li class="c2"><span class="c0">Multicast send protocols.</span></li></ul><ul class="c4 lst-kix_list_25-2 start"><li class="c1"><span class="c0">Directional aggregate (anonymized) subscription (whitelist), un-subscription, and active blocking (blacklist).</span></li></ul><ul class="c4 lst-kix_list_2-1"><li class="c2"><span class="c0">All protocols allow time-decay based directional blocking (blacklist), to help prevent and diffuse DDoS attacks.&nbsp;</span></li><li class="c2"><span class="c0">Nearest-node route automated security assessment, via web-of-trust (WoT) rating systems, assessed per subscriber privately.</span></li></ul><ul class="c4 lst-kix_list_26-2 start"><li class="c1"><span class="c0">Automated acceptance of a neighbor node&#39;s blacklist and whitelist settings, depends on WoT rating and distance-decay parameters.</span></li><li class="c1"><span class="c0">Core service acceptance and resolution (i.e. Secure DNS) depends on WoT rating, then distance.</span></li></ul><ul class="c4 lst-kix_list_2-1"><li class="c2"><span class="c0">Cost of Service (CoS) calculations applied to each link choice in a given route.</span></li></ul><ul class="c4 lst-kix_list_27-2 start"><li class="c1"><span class="c0">Bandwidth costing metric (data set size).</span></li><li class="c1"><span class="c0">Speed costing metric (latency).</span></li><li class="c1"><span class="c0">Security costing metric (anonymity, trust, encryption layering).</span></li><li class="c1"><span class="c0">Reliability costing metric (jitter, loss).</span></li><li class="c1"><span class="c0">Provision billing cost metric (monetary, billing, maintenance expense).</span></li></ul><ul class="c4 lst-kix_list_2-1"><li class="c2"><span class="c0">Some QoS reliability requirements handled via parity-encoded and striped data sent over multiple parallel routes in dense meshes.</span></li></ul><ul class="c4 lst-kix_list_28-2 start"><li class="c1"><span class="c0">Redundant Array of Inexpensive Routes (RAIR). RAIR# ~= RAID#</span></li></ul><ul class="c4 lst-kix_list_29-3 start"><li class="c3"><span class="c0">RAIR0: Split data over multiple parallel routes.</span></li><li class="c3"><span class="c0">RAIR1: Mirror data over 2 or more routes.</span></li><li class="c3"><span class="c0">RAIR3: Stripe data over multiple parallel routes, with a dedicated parity route.</span></li></ul><ul class="c4 lst-kix_list_2a-4 start"><li class="c5"><span class="c0">(Probably only useful when one route is consistently more reliable than the others)</span></li></ul><ul class="c4 lst-kix_list_29-3"><li class="c3"><span class="c0">RAIR5: Stripe data over multiple parallel routes, with parity data on a different route each stream segment.</span></li><li class="c3"><span class="c0">RAIR6: Stripe data over multiple parallel routes, with redundant parity data on 2 or more different routes.</span></li><li class="c3"><span class="c0">Combine 2 of the above for obvious desirable effects -- best akin to RAID10, RAID50, or RAID60.</span></li><li class="c3"><span class="c0">Increase total redundant parity or mirror route paths based on packet loss increases.</span></li></ul><ul class="c4 lst-kix_list_1-0"><li class="c12"><span class="c0">Data Roads Scholarship</span></li></ul><ul class="c4 lst-kix_list_2b-1 start"><li class="c2"><span class="c0">Awards for best research in people-centric networking.</span></li><li class="c2"><span class="c0">ISS Killer-app contests.</span></li><li class="c2"><span class="c0">Only awarded for open source, open standards, and openly accessible research.</span></li><li class="c2"><span class="c0">If any patents are allowed, all patents must be assigned to the Foundation and pooled defensively.</span></li></ul><ul class="c4 lst-kix_list_1-0"><li class="c12"><span class="c0">Grant programs for regional Internet Service Cooperatives.</span></li></ul><ul class="c4 lst-kix_list_2c-1 start"><li class="c2"><span class="c0">Grantees must use some form of stable ISS routing on their network, and provide testing nodes.</span></li><li class="c2"><span class="c0">Grantee upstream providers must use open access, non-discriminatory, and wholesale provision (whenever a choice is possible).</span></li><li class="c2"><span class="c0">Grantees must take a basic oath of service.</span></li><li class="c2"><span class="c0">Low income membership subsidies, only in certified Grantee Cooperatives&#39; regions.</span></li><li class="c2"><span class="c0">Give-one Get-one (GOGO) style hardware distribution.</span></li></ul><ul class="c4 lst-kix_list_1-0"><li class="c12"><span class="c0">Spin off (subsidiary or independent 501(c)(4)): American Data Drivers&#39; Club</span></li></ul><ul class="c4 lst-kix_list_2d-1 start"><li class="c2"><span class="c0">Analogous to Automobile Clubs, except this club is for servicing and maintaining &quot;data driving equipment.&quot;</span></li><li class="c2"><span class="c0">No member has to be a networking or computer expert, because the club provides all needed expertise.</span></li><li class="c2"><span class="c0">The club is paid only to work in the club members&#39; best interests. All club members have a democratic vote.</span></li><li class="c2"><span class="c0">Rate, certify, and recommend &quot;network mechanics.&quot;</span></li></ul><ul class="c4 lst-kix_list_2e-2 start"><li class="c1"><span class="c0">Certified and branded partners take an oath of service.</span></li></ul><ul class="c4 lst-kix_list_2d-1"><li class="c2"><span class="c0">Partner exclusively with independent mechanics and open access or non-profit network providers.</span></li><li class="c2"><span class="c0">Enforce service transparency requirements, on behalf of club members.</span></li><li class="c2"><span class="c0">Discounts and promotion programs.</span></li><li class="c2"><span class="c0">Travel related foreign network access provision.</span></li><li class="c2"><span class="c0">Brokerage for ancillary services.</span></li></ul><ul class="c4 lst-kix_list_1-0"><li class="c12"><span class="c0">Spin off (subsidiary, independent 501(c)(4), or international group): Data Driver&#39;s Club Federation</span></li></ul><ul class="c4 lst-kix_list_2f-1 start"><li class="c2"><span class="c0">Consolidate services shared between regional Data Driver&#39;s Clubs, perhaps even internationally.</span></li><li class="c2"><span class="c0">Member clubs must pay administrative dues, pass shared certifications, and take an oath of service.</span></li></ul><ul class="c4 lst-kix_list_1-0"><li class="c12"><span class="c0">Spin off (subsidiary or independent 501(c)(12)): National Network Cooperative</span></li></ul><ul class="c4 lst-kix_list_30-1 start"><li class="c2"><span class="c0">IPv4, IPv6, and ISS transit over a national long-range backbone mesh.</span></li><li class="c2"><span class="c0">Advisory bodies.&nbsp;</span></li><li class="c2"><span class="c0">Shared services provision.&nbsp;</span></li><li class="c2"><span class="c0">All downstream Cooperative member organizations must take oath.</span></li></ul><ul class="c4 lst-kix_list_31-2 start"><li class="c1"><span class="c0">Service transparency.</span></li><li class="c1"><span class="c0">Resident open access (timeline provided at minimum).</span></li><li class="c1"><span class="c0">Network neutrality provisions.</span></li></ul><ul class="c4 lst-kix_list_1-0"><li class="c12"><span class="c0">Spin off (international organization): International Network Cooperative</span></li></ul><ul class="c4 lst-kix_list_32-1 start"><li class="c2"><span class="c0">IPv4, IPv6, and ISS transit over an international world-wide backbone mesh.</span></li><li class="c2"><span class="c0">Members comprised of various National Network Cooperatives.</span></li><li class="c2"><span class="c0">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.</span></li></ul><ul class="c4 lst-kix_list_33-2 start"><li class="c1"><span class="c0">Much less central control of ISS network assignments and service deployment methods.&nbsp;</span></li></ul><ul class="c4 lst-kix_list_32-1"><li class="c2"><span class="c0">ISS networks are defined by their use of ISS routing methods, not by organization membership.</span></li><li class="c2"><span class="c0">All downstream Cooperative member organizations must take oath.</span></li></ul><ul class="c4 lst-kix_list_34-2 start"><li class="c1"><span class="c0">Membership and service transparency.</span></li><li class="c1"><span class="c0">Non-discriminatory open access to membership who are willing to take a similar oath (timeline provided at minimum).</span></li><li class="c1"><span class="c0">Network neutrality provisions.</span></li></ul><p class="c8"><span class="c0"></span></p>

Latest revision as of 13:35, 10 May 2017

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.
  • 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.