Network2/Purpose: Difference between revisions

From OLPC
Jump to navigation Jump to search
m (New page: Its abstract purpose is to advance the Network Principles project by explaining how you might build a system based on those principles with currently available tools and by doing a first ...)
 
(purpose)
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
{{Network2 header}}


=== Purpose ===
Its abstract purpose is to advance the Network Principles project by explaining how you might build a system based on those principles with currently available tools and by doing a first round of modeling and prototyping in order to gain some analytic and empirical evidence about whether those principles are sound.
Its abstract purpose is to advance the Network Principles project by explaining how you might build a system based on those principles with currently available tools and by doing a first round of modeling and prototyping in order to gain some analytic and empirical evidence about whether those principles are sound.



Latest revision as of 04:27, 28 July 2009


Purpose

Its abstract purpose is to advance the Network Principles project by explaining how you might build a system based on those principles with currently available tools and by doing a first round of modeling and prototyping in order to gain some analytic and empirical evidence about whether those principles are sound.

Its concrete purpose is to provide internetworking and naming technology to XO-users (and other interested parties) that seamlessly and predictably supports the XO's most important low-latency network scenarios as well as is possible with existing software.

Its social and conceptual purpose is to provide a design that is satisfactory in several ways in which previous networking and collaboration substrates were not, as described in the following principles of design quality:

do no harm -- our users are not volunteers, so don't waste their time
play well with others, since we want a large ecosystem and lots of testing
be realistic, so that we don't promise the impossible
be predictable, so that we can tell people what will work and what will fail in advance
prevent failure, by means of proof, simulation, and wise habits
tolerate failure, by removing inappropriate single points of failure
route around failure, by means of self-test procedures and preplanned maneuvers (manual overrides)

Notes on quality principles:

  1. do no harm and play well with others mean that we believe that previous designs unnecessarily harmed their users by wasting scarce resources (e.g. time, trust, and the capacity to learn) and opportunities (e.g. to grow the ecosystem). Other "harms" inflicted by previous designs include having badly confused their users, having over-promised their scalability, and having been unable to articulate or to meet basic "go/no-go" availability requirements.
  2. realism and predictability are intended to evoke the following "litmus test" questions:
    • how well does the design conform to the physical realities (bandwidth, latency, power, failure, and error) and to the social realities (ignorance, interdiction, authority, and autonomy) that define its niche?
    • is there a public, written, and peer-reviewed design document describing the design?
  3. prevent, tolerate, and route around are all direct usability goals that no networking design intended for real humans (particularly by teachers!) should ignore