Collaboration Requirements

[Michael Stone]

On Wed, Jul 30, 2008 at 05:21:34PM -0400, Greg Smith wrote:
>This is my first somewhat rigorous requirements definition for OLPC so
>comments on style as well as substance are welcome.

This feels very similar to an RFC. Take a look at RFC 2223 "Instructions
to RFC Authors" and think about whether you could happily follow its
guidance.

>The concept of "Collaboration" has been around for a long time. I have
>used cuseeme, MeetingPlace, NetMeeting, WebEx, IRC, AIM, Gobbby,
>Sametime, PC Anywhere, Cisco HD Video conferencing and others. 

You cite a number of collaborative systems with which you have personal
experience. I think we should really be citing collaborative systems
(both digital and otherwise) from which we take our inspiration and our
warnings. (I have some favorites, but I'll let you think about the issue
first before sharing.)

> Our challenge is different in three respects.

>- wireless
>- educational use
>- greater scale

I agree that it's different but I think you left some important things
out like the existence of side-channels provided by physical proximity
of the participants.

>Motivation:
>The goal of this requirement definition is to provide all the information
>necessary to define tests and fix critical collaboration bugs in 8.2.0 

At this date, unless we decided to slip the release by several weeks,
there will be essentially no opportunity to fix critical collaboration
bugs in 8.2.0 proper. However, these bugs are certainly of great
interest for follow-on bugfix releases made prior to 9.1.0.

>The best case is that this write up motivates test cases which results 
>in a list of detailed examples of collaboration  that will be supported 
>in 8.2.0. These examples should be deployable and usable by teachers in 
>class. Examples of use cases generated by teachers are at:
>http://wiki.laptop.org/go/Use_Cases#Collaboration_Examples
>
>Collaboration is an area where we are on the cutting edge of available
>technology. 

We're actually on the trailing edge of collaboration technology and far,
far behind on collaborative teaching aids. Email, free web hosting,
filesharing networks, Croquet, erights.org, Alice ML, multi-pointer X,
Groovy, the distributed source control movement, and the Google Apps
suite seem much closer to the leading edge of technology, to name a few.

> It was well promoted and teachers on the "sur" list have
> repeatedly asked for a definition of how to use it successfully.

Insofar as we make no use of our own collaborative technology as part of
our daily learning and teaching, we're not able to use it successfully
ourselves.

>Documentation on previous wireless tests is at:
>http://wiki.laptop.org/go/Test_Config_Notes#Wireless_.26_Network

More relevant documentation is available at 

   http://wiki.laptop.org/go/Collaboration_Network_Testbed

>Requirements Definition:
>
>I set a high bar but I try to balance between available technology and
>the desires of the teachers. I hope can at least test to this standard
>soon, even if we don't close all bugs found by that testing until later.
>
>Requirements beginning with "must" are critical to success, "should" are
>very important but can be deferred and nice to have are "very useful"
>but likely to be deferred.

Please consider using RFC 2119's definitions instead.

>If a "must" requirement cannot be met, we should still attempt to
>support as much of it as possible (e.g. if we can't do 50 XOs in N9, 40
>or 30 should be tested and supported).
>
>I - Network Requirements
>
>i - Supported Architectures
>N1 - Must support one of the four network scenarios defined at:
>http://wiki.laptop.org/go/Networking_scenarios

Please define "support" before using it here.

>The scenarios in priority order are named as follows.

>S1 - Simple Wifi
>S2 - School Wifi
>S3 - Simple Mesh
>S4 - School mesh (no need to test, just recorded here for completeness)

I'm not sure that your priorities are correct. My understanding was that
I believe that School Wifi is higher-priority (for collaboration;
perhaps not for networking) than Simple Wifi.

>ii - RF Environments

Is there an "N1" that I missed.

>N2 - Must support environments where there are no other RF signals
>beyond the APs as needed by the network scenario.

You need to be more precise here. RF signals and visible APs are
_wholly_ different measurements. In particular, I believe that I should
be able to hook up a spectrum analyzer (or run some software on my XO)
and be able to immediately judge whether my environment meets your
criteria.

Furthermore, understand that APs by themselves consume relatively little
bandwidth. It's the _clients_ of those APs (and other sources of noise)
which consume the bandwidth that is inherently present in the spectrum.

>II - Scale
>i - Scale of XOs collaborating
>N5 - Must support up to 10 XOs collaborating together. See activity
>examples for exact steps.

Since different collaborative activities consume different amounts of
bandwidth, this is not an adequately specified requirement.

>ii - Scale of XOs visible within range of each other
>
>N8 - In N5 above must allow up to 1500 XOs within range in the school.
>Can require that all other XOs aside from those collaborating have their
>antennas turned off.

If the other XOs are genuinely radio-silent (and are not physically
absorbing the RF radiation being generated by the nearby transmitters)
then their numbers are largely irrelevant to collaboration. Moreover, we
have no great way of putting 1500 laptops into a testbed on any of the
timeframes you're interested in.

>N9 - Must allow 50 (should allow 100, nice to have 300) other XOs within
>range in the school where all XOs have their radios turned on. Can
>require that only those collaborating are using the network (AKA
>everyone else is verbally asked to stop using the Internet and stop
>collaborating) but they can leave their XO radios on in scenario S1

XOs broadcast presence information even when their owners are not
otherwise engaged in networking activities. They also broadcast 802.11s
control-plane traffic even when suspended. Some measurements indicate
that both of these sources of traffic account for large quantities of
available bandwidth.

>N10 - Must allow 50 (should allow 100, nice to have 300) XOs within
>range in the school where all XOs have their radios turned on. Can
>require that only those collaborating are using the network (AKA no
>collaboration and no Internet access) in scenario S2.

Is N10 different from N9 only in that in N9, non-collaborating users
have been explicitly asked to avoid intentional network actions?

>N11 - Must allow 50 (should allow 100, nice to have 300) XOs within
>range in the school where all XOs have their radios turned on. Can
>require that only those collaborating are on a given Mesh channel (1,6
>or 11) while all the other XOs are on different Mesh channels in scenario S3

Incidental note: none of your requirements so far describe limitations
on what other non-XO radio transmitters are doing or on the RF noise or
absorption manifolds (which are heavily influenced by antenna placement,
geometry, walls, atmospheric conditions, etc).

>In all cases, a single XO starts activity, then shares it, then other
>XOs join the shared activity.

You should discuss presence first. You also, on the 9.1.0 timeframe,
need to recognize that there are faults with our collaboration _model_;
not just with its architecture, design, implementation, and environment.
We're _really screwed_ at the moment.

>N12 - Must support up to 3 XOs using an activity and all others XOs (as
>allowed by the scale) watching what happens on that screen.

You _must_ specify some limitations on behavior of actors. As it stands,
misbehavior on any sufficiently powerful and appropriately tuned
transmitter in the same RF environment can prevent all nearby XOs from
collaborating as you currently use the term.

>N15 - Nice to have all XOs as allowed by scale using an activity
>simultaneously.

"Allowable scale" is conditioned on parameters that you are not fixing
in your requirements. You need to specify those parameters.

>N16 - Must support pairs of two XOs collaborating with each other up to
>the number of XOs supported by scale.
>
>N16 - Where an activity allows saving, must support saving at any time
>where the XO which saves gets a current copy of the shared file. If its
>a "save as" or "save" but not exit action then the XO which saves
>returns to the shared view. Where its an automatic "save" by leaving the
>activity, the journal must store a current copy of the shared file. All
>of these saving actions must not interfere in any way with the saved  or
>shared file on the other XOs or with the collaboration or network
>connectivity of any XOs.

Beware of collaboration scenarios which give access to state that is
larger than the capacity of any single XO. Think about how super-peers
like the school server might be represented in collaboration use cases.

>IV - Activity Level Details
>N17 - Must support Chat

Is the requirement for "Chat" (today's activity) or "chat" (the human
activity, as implemented by, say, Xavier)?

>N18 - Must support Write including adding pictures, formatting with
>tables and other write tasks.
>
>N19- Must support record including sharing pictures and recorded video
>with audio.

This can probably be better cribbed from the existing collaboration
tests.

>That's it! Do that and version 10.2 will be coded by kids who grew up
>sharing activities on an XO :-)

You're not aiming high enough. You should also think about goals for
external adoption of our collaboration technologies by the larger
software community. 

Michael