Network2: Difference between revisions

From OLPC
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
 
(226 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{TOCright}}
This page proposes a fresh design for network configuration in a highly collaborative world, based on Scott's [[Network Principles]] in general and on these micro-principles in particular:
Last updated: [[User:Mstone|Michael Stone]] 04:15, 15 January 2010 (UTC) | '''[[Network2/Paper|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 [[OLPC Human Interface Guidelines/Design Fundamentals/Key Design Principles|human interface guidelines]].
# Ease of debugging is paramount.
# Orthogonal pieces.
# Self-test functionality.


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.
However, unlike the Network Principles situation, we also describe how to integrate several kinds of NAT-traversal technology, primarily to support dog-fooding and diagnosis by remote developers.


'''Quick links''': '''[[Network2/Paper|the Paper]]''' : (finished/''unfinished'' sections)
== Client Design ==


* Prior work: [[networking]], [[collaboration]], [[network principles]]
Your job is to be an [http://tools.ietf.org/html/rfc2460 IPv6] node.
* 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...'''
# Bring up your interfaces and perform [http://tools.ietf.org/html/rfc2461 IPv6 Neighbor Discovery] over [http://tools.ietf.org/html/rfc2463 ICMPv6] looking for routers. (See <tt>sysctl net.ipv6.conf.all.accept_ra</tt> and related variables.)
# If you don't find any and you can join a VPN ([http://openvpn.net/ openvpn], IPsec+L2TP), do so.
# If you want to, bring up [http://tools.ietf.org/html/rfc4380 Teredo] ([http://www.remlab.net/miredo/ miredo]).


# "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."
== Server Design ==
# "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!
Your job is to be an IPv6 router and a DNS server. One of several situations might obtain:


==Subpages==
# You might discover an IPv6 router advertising one or more IPv6 prefixes on your outbound link(s).
{{Special:PrefixIndex/{{PAGENAMEE}}/}}
# You might have some kind of IPv4 connectivity. If so, [http://www.sixxs.net/faq/connectivity/?faq=comparison connect] to the Internet or to a internetwork (VPN) of your choice.


[[Category:Network2]]
[[Category:Subsystems]]

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)

Personal goals...

  1. "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."
  2. "I want a design that has 20% fewer ways to fail, and that offers manual overrides for the failure modes that remain."
  3. "I want to chop 2-3 levels from the current collaboration stack's 6-level 'fast-path'."
  4. "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