Network2: Difference between revisions
m (→Context) |
mNo edit summary |
||
(42 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
{{TOCright}} |
{{TOCright}} |
||
⚫ | |||
Sugar's desired realtime collaboration experience can only be provided atop a robust and efficient network stack designed to accommodate automated diagnosis and standardized workarounds -- anything less only wastes students' and teachers' time and patience, contrary to our [[OLPC Human Interface Guidelines/Design Fundamentals/Key Design Principles|human interface guidelines]]. |
|||
⚫ | |||
This '''unfinished''' essay summarizes an attempt to work out a simple way to realize this sort of network experience, with existing software and hardware, while also demonstrating the sort of thinking which might help other parts of the system achieve the same standard of quality. |
|||
== Introduction == |
|||
'''Quick links''': '''[[Network2/Paper|the Paper]]''' : (finished/''unfinished'' sections) |
|||
There are many ways that children involved in the OLPC effort might fail to benefit from their involvement. Some of these educational failures stem from network design and implementation failures such as lack of interoperability, efficiency, and usability. Therefore, we have created a [[Network2#Threat Model|threat model]], a number of [[Network2#Design|designs]], and several [[Security#Design|implementations]] that we think will help mitigate these threats. More information about these artifacts can be gleaned from other [[:Category:Network2|pages on Network2]]. |
|||
* Prior work: [[networking]], [[collaboration]], [[network principles]] |
|||
Unfortunately, providing truly dependable software is a '''challenging''' task at best. Fortunately, there are many ways that you can help out, both [[Developers|generically]], [[Network2#Contributions|particularly]], or via [[Network2/Audience|role-based scaffolding]] according to your preferences. Finally, if you are interested in speaking with [[Network2/Credits|networking people]], know that they are readily available. |
|||
* Background: [[Network2/Purpose|purpose]], [[Network2/Scenarios|scenarios]], [[Network2/Architecture|architecture]] |
|||
* Designs: [[Network2/Design|naming and internetworking]], ''[[Network2/Security|security ideas]]'', [[Network2/Diagnosis|diagnosis techniques]] |
|||
* Analyses: ''[[Network2/Dynamics|cost model]]'', ''[[Network2/Self-test|self-test algorithm]]'' |
|||
* Experiments: [[Network2/Experiments/Dnshash|dnshash]], [[Network2/Experiments/Openvpn|openvpn]], ''[[Network2/Experiments/HE|6to4: HE]]'', ''[[Network2/Experiments/Sixxs|6to4: Sixxs]]'', ''[[Network2/Experiments/Simulation|simulation]]'', ''[[Network2/Experiments/openwrt|openwrt]]'', ''[[Network2/Experiments/tinydns|olpcdyndns1]]'' |
|||
'''Personal goals...''' |
|||
== Context == |
|||
# "I want to use familiar tools in my activities, -- like Twisted, curl, ssh, rsync, and email -- both under a tree, in a walled garden, and out on the public Internet, without modification or wrappers." |
|||
This network design effort is growing in the fertile ashes of previous [[Networking|network]] and [[Collaboration|collaboration]] attempts. Consequently, it proceeds from previously realized [[Network Principles]] according to a multi-faceted statement of [[Network2/Purpose|purpose]], a prioritized list of [[Network2/Scenarios|network scenarios]], and a collection of architectural [[Network2/Architecture|quality principles]] wrought from the aforementioned previous efforts. |
|||
# "I want a design that has 20% fewer ways to fail, and that offers manual overrides for the failure modes that remain." |
|||
# "I want to chop 2-3 levels from the current collaboration stack's 6-level 'fast-path'." |
|||
# "I want to collaborate with people who only have web browsers -- they outnumber people with Jabber clients by millions." |
|||
'''Finally, to help out''', please improve my writing, experiment with my ideas, and share this work with your friends! |
|||
== Design == |
|||
==Subpages== |
|||
Networking is intimately related to all aspects of the Sugar experience, including both usage and creation. Here are some pages describing many aspects of this experience: |
|||
{{Special:PrefixIndex/{{PAGENAMEE}}/}} |
|||
; [[Network2/Advice|Activities]] |
|||
: We provide advice for activity authors on special factors to consider when writing networked or collaborative activities. |
|||
; [[Network2/Design|Naming and Internetworking]] |
|||
: We intend to use DNS and IPv6 for naming and internetworking. |
|||
; [[Network2/Management|Management]] |
|||
: t.b.d. |
|||
; [[Network2/Dynamics|Dynamics]] |
|||
: In order to efficiently study scaling costs, we maintain bandwidth and latency models for our most important links, protocols, and implementations. |
|||
; [[Network2/Diagnosis|Diagnosis]] |
|||
: Our [[Network2/Architecture|quality principles]] mandate that we provide fault diagnosis procedures even before providing implementations! |
|||
; [[Network2/Self-test|Self-test]] |
|||
: A logical extension of good ''manual'' diagnosis procedures is the creation of good ''automated'' diagnosis procedures. |
|||
; [[Network2/Experiments|Experiments]] |
|||
: We have begun experimenting with naming and tunneling technologies like [[Network2/Experiments/Dnshash|dnshash]] and [[Network2/Experiments/Openvpn|openvpn]]. |
|||
; [[Network2/Future work|Future work]] |
|||
: As with any ambitious project, there's always more to do! |
|||
'''Caveats''' |
|||
When judging, please also note that the design is '''not yet complete''' in several important respects: |
|||
* it has only a stub of a bandwidth model, hence we ''yet'' know how much it costs to scale it up |
|||
* its self-test algorithm is not yet written, (though good diagnostic primitives are systematically identified) |
|||
* it lacks truly clear implementation guidance and comprehensive sample code, and |
|||
* there are unresolved questions about |
|||
** how routing and timeouts should be configured so that peers search their target address space in a useful fashion |
|||
** how [[communications security]] might best be provided. |
|||
* it lacks an "integration and deployment" plan outlining how to get it adopted. |
|||
== Contributions == |
|||
You can contribute to the education received by hundreds of thousands of children this year by: |
|||
; writing software |
|||
: Review the documentation cited above, then bring your questions and patches to the [mailto://sugar-devel@lists.sugarlabs.org sugar-devel mailing list] ([http://lists.sugarlabs.org/listinfo/sugar-devel subscribe]). |
|||
; refining the threat model and design |
|||
: Did we miss an important threat (e.g. to availability)? If so, please work with us to fix our model. |
|||
: Alternately, if you have expertise in a related field like mathematical modeling (''how far can this scale?'') or usability (''how should we inform users of failure?''), please improve our theories and recommended practices. |
|||
; breaking assumptions |
|||
: Networking is proven both in the mind and under fire. Here's your opportunity to crank up the heat. |
|||
; organizing other people |
|||
: Many people are capable of improving the networking ecosystem but for the lack of some critical resource like knowledge, motivation, or criticism. Find and provide the missing piece. |
|||
; spreading the word |
|||
: Many of our networking ideas are transferable to other operating systems and environments -- particularly to other Unix-like machines. Help port our ideas or software to another platform so that others can benefit from them and can help us improve them on their own terms. |
|||
== Procedures == |
|||
Some day soon, we'll try to write up some simple procedures to ease the task of making the networking contributions described above. Ping the [mailto://sugar-devel@lists.sugarlabs.org sugar-devel list] ([http://lists.sugarlabs.org/listinfo/sugar-devel subscribe]) if you want this up. |
|||
== Thanks == |
|||
Many people, both named and anonymous have contributed to the network ecosystem containing the XO and hence to the quality and power of the education received by hundreds of thousands of kids this year. If you or your organization would like to be recognized for your contributions, please add your name and affiliation to the [[Network2/Credits|Network2 credits]] page along with a brief description of what you worked on. |
|||
[[Category:Network2]] |
[[Category:Network2]] |
Latest revision as of 04:15, 15 January 2010
Last updated: Michael Stone 04:15, 15 January 2010 (UTC) | paper version
Sugar's desired realtime collaboration experience can only be provided atop a robust and efficient network stack designed to accommodate automated diagnosis and standardized workarounds -- anything less only wastes students' and teachers' time and patience, contrary to our human interface guidelines.
This unfinished essay summarizes an attempt to work out a simple way to realize this sort of network experience, with existing software and hardware, while also demonstrating the sort of thinking which might help other parts of the system achieve the same standard of quality.
Quick links: the Paper : (finished/unfinished sections)
- Prior work: networking, collaboration, network principles
- Background: purpose, scenarios, architecture
- Designs: naming and internetworking, security ideas, diagnosis techniques
- Analyses: cost model, self-test algorithm
- Experiments: dnshash, openvpn, 6to4: HE, 6to4: Sixxs, simulation, openwrt, olpcdyndns1
Personal goals...
- "I want to use familiar tools in my activities, -- like Twisted, curl, ssh, rsync, and email -- both under a tree, in a walled garden, and out on the public Internet, without modification or wrappers."
- "I want a design that has 20% fewer ways to fail, and that offers manual overrides for the failure modes that remain."
- "I want to chop 2-3 levels from the current collaboration stack's 6-level 'fast-path'."
- "I want to collaborate with people who only have web browsers -- they outnumber people with Jabber clients by millions."
Finally, to help out, please improve my writing, experiment with my ideas, and share this work with your friends!
Subpages
- Network2/Advice
- Network2/Architecture
- Network2/Audience
- Network2/Concept/Address
- Network2/Concept/Bandwidth
- Network2/Concept/Bridge
- Network2/Concept/Capacity
- Network2/Concept/Interface
- Network2/Concept/Internetwork
- Network2/Concept/Jitter
- Network2/Concept/Latency
- Network2/Concept/Layer
- Network2/Concept/Link
- Network2/Concept/Medium
- Network2/Concept/Name
- Network2/Concept/Network
- Network2/Concept/Protocol
- Network2/Concept/Router
- Network2/Concept/Scenario
- Network2/Concept/Tunnel
- Network2/Credits
- Network2/Design
- Network2/Diagnosis
- Network2/Dynamics
- Network2/Experiments
- Network2/Experiments/Dnshash
- Network2/Experiments/HE
- Network2/Experiments/OpenWRT
- Network2/Experiments/Openvpn
- Network2/Experiments/Simulation
- Network2/Experiments/Sixxs
- Network2/Experiments/tinydns
- Network2/Future work
- Network2/Paper
- Network2/Purpose
- Network2/Scenarios
- Network2/Security
- Network2/Self-test