Wireless Recommendations
Overview
This page consolidates a series of recommendations on how to achieve better scalability and reliability on the XO mesh network. These recommendations come from the OLPC wireless network team and also from a team of experts from Nortel.
How this document is organized
Each recommendation consists of a the following sections:
executive summary: One or two paragraphs with an overview of the recommendation.
detailed analysis: Where applicable, additional detail (quantitative or qualitative) that supports the recommendations should be provided.
action page(s): Lists procedures, tests and tasks needed to put the recommendations in practice, as well as documenting the progress obtained so far.
other references: Links to related pages on that wiki or to external sites.
Recommendation categories
- (I)mplement: these are recommendations in its usual form: a problem has been detected and understood and a suggestion on how to attack it is already proposed.
- (D)iagnose: we suspect there is something wrong and we should understand the root causes before suggesting a fix. This is the very fisrt step of a recommendation, in other words: we recommend that efforts should be made to better understand a given issue.
- (T)esting: Implementations that are related to testing mechanisms and facilities.
Recommendation priorities
The recommendatiions are not prioritized. It is suggested that it does get renumbered and reordered according to a priorization process. Alternatively a priority field could be added to the Recommendation with typical categories like (high, medium or low)
(I)mplement Recommendations
I1. Detect and Adapt: The Mesh Adaptation Daemon (MAD)
executive summary: Implement a user space daemon that will monitor the mesh envorinment and react/adapt to it accordingly in order to improve scalability and reliability of the XO mesh
detailed analysis:
action page: http://wiki.laptop.org/go/MAD
other references:
I2. Reduce the management traffic
executive summary: The frequancy in which the XOs send wireless management traffic (probe request/response) traffic can be reduced without harming any funcionality and saving significat amounts of airtime.
detailed analysis:
action page:
other references:
I3. Implement a better rate adaptation algorithm
executive summary: Due to limited memory resources, the XO implements a simple Frame Error Rate algorithm that lowers the transmission rate if a given number of consecutive frames are lost and, likewise, raises that rate if a given number of consecutive frames are successfully sent. The problem with that scheme is that when packets are lot due to congestion-induced collisions (and not by poor link quality), lowering the transmission rates will make things even worse.
detailed analysis:
action page: Test Facilities
other references:
I4. Agnosticism of the presence service
executive summary: When the presence service decides it's in a mesh, it uses mDNS to advertise and retrieve presence info. When it decides there's a school server, it switches from mDNS to the XMPP school server. The presence service should use a solution that is agnostic to the presence or absence of the school server.
detailed analysis:
action page:
other references:
I5. Implement a new (PHY) Physical layer
executive summary: Evolve the mesh to use an 802.11n PHY which provides up to 600MBs rates. .11n MAC enhancements include frame aggregation capabilities which might help the mesh when dealing with short frames. There are issues using the .11n MAC for mesh networks that need resolution in the standards committee.
detailed analysis:
action page:
other references:
I6. Adjust costs (metric) in each of the PREQs
executive summary:
detailed analysis:
action page:
other references:
I7. Improve Network Wide Broadcast spectrum efficiency
executive summary: Evolve the mesh to use an 802.11n PHY which provides up to 600MBs rates. .11n MAC enhancements include frame aggregation capabilities which might help the mesh when dealing with short frames. There are issues using the .11n MAC for mesh networks that need resolution in the standards committee.
detailed analysis:
action page:
other references:
I8. Improve ip addressing scheme in the mesh
executive summary: The transition between mesh and mesh portals is problematic. In particular, when the XO is in a mesh it self assigns a 169.254 subnet "link local" address, when it finds a mesh portal, the portal assigns a 172.16 subnet "private" address. A better solution would be to partition the 169.254.x.x subnet into 3 subnets for use on the XO mesh - one for each of channels 1, 6 and 11. The XO keeps this address as long as it's on the mesh. Mesh portals can advertise their presence in mDNS, much like telepathy does for the link local presence service (more on this later). Much of the linux networking s/w looks like it would already support such a configuration, with the exception that Avahi would probably need some tweaking to use a non-standard link local subnet.
detailed analysis:
action page:
other references:
I9. New version of NetworkManager
executive summary:
detailed analysis:
action page:
other references:
(D)iagnose Recommendations
D1. The manually added path enigma
executive summary: paths that have been added manually to the ***
detailed analysis:
action page:
other references:
D2. The Internal Flow control black hole
executive summary: The wireles dirver discards a large volumes of traffic. This may or may not be caused by flow control problems on the USB bus, but it should be debugged and packet loss under overload reduced to whatever OLPC decides is an acceptable level based on application needs, etc. It would also be worth reviewing the debugging tools in the driver and see if we can come up with any good proposals for enhancements.
detailed analysis:
action page:
other references:
(T)esting Recommendations
T1. Test facilities
executive summary: The XO needs a network level test facility that can be run regularly to sanitize/smoke test every build. This is testing the XO network without all of the activities to verify things like network throughput, network routing, mesh portals, error rates, collision avoidance etc. This testing will be used to identify bugs, drive fixes to the bugs,and ensure that new changes don't break existing functionality.
detailed analysis:
action page: Test Facilities
other references:
T2. Test suite
executive summary: There should be a standardized package for test-bed management (published freely) so that development and test of the mesh and the associated software and protocols can be distributed across teams. There should also be a standard test-bed configuration. Nortel has done some work in this area as have several of the members of the OLPC community. These efforts should be consolidated.
detailed analysis:
action page:
other references:
T3. Simulation environments
executive summary:
detailed analysis:
action page:
other references: