New, more realistic multi-hop network testbed

[Michail Bletsas]

cananian at gmail.com wrote on 06/08/2008 11:33:15 AM:

> To clarify, there are at least seven different directions to follow 
here:
>  a) telepathy-based collaboration on 802.11g networks
>  b) telepathy-with-cerebro-backend collaboration on 802.11g networks
>  c) cerebro-based collaboration in 802.11g networks.
>  d) 802.11s meshing in dense networks
>  e) 802.11s meshing in sparse (wide-area) networks
>  f) 802.11s Mesh Portal Point functionality (bridging a school 802.11g
> network to a neighborhood 802.11s network)
>  g) OLSRd wide-area meshing on an 802.11g sparse (wide-area) network
>  h) plain ol' 802.11g in 100+ node schools
> 
> Let me try to summarize current status on a few of these:
>  a) what we're currently deploying.  believed working for ~20
> machines, but there are problem reports from the field.
The number depends on the traffic paterns of the specific applications.
Chat will scale to much higher numbers than write for example.
Careful optimization and debugging is the short term action path.
APs that support high rate multicasts can also help here.



>  b) collabora did some work to abstract out avahi, in theory the
> groundwork is present for a cerebro backend.
That's more like wishful thinking at this point. We need to push more on 
that end.

>  c) Poly has demonstrated this with 70 laptops (limited only by the
> size of his testbed); would require modification of activities.
Cerebro will work just fine over a mesh transport also. It uses nearest 
neighbor broadcast only.
We need to settle on a solution for #6211 soon and we need to get some 
form of Cerebro into Joyride (not-necessarily integrated with Telepathy - 
just a simple D-BUS/UI integration with some Cerebr-ized apps like chat 
and file tranfer)

>  d) nortel and our old mesh testbed looked at this, but I believe
> Michalis' current opinion is that we should be using APs in this
> scenario.  So, not important?
The bottom line is that there is no need to use a multi-hop transport with 
all of its associated overhead, when everybody can talk to everybody else. 
We could also be using simple ad-hoc mode, however we don't support that 
from a UI perspective. So, for the moment, we suggest that people use APs. 
In the long term we should be able to address the intermediate cases 
(between sparse and dense) via better broadcast support on the mesh (ex: 
Scalable Broadcast Algorithm, Ad-Hoc Broadacast Protocol) Marvell will be 
working on this one.
It is not clear if we have the necessary memory/cpu resources on the 8388 
but it seems a lot more feasible on the 8682.

>  e) No one looking at this.  Poly has proposed a testbed for this.
I wouldn't call that Wide Area since it involves mobile devices. It's more 
of a MANET and less of a WMN (Wireless Mesh Network)
We have done testing in the past and Polychronis' has been doing it in 
various forms for a long time now.

>  f) yanni is looking at this?  No test bed yet.
Ricardo and Yanni (whose last day was Thursday) looked at that, there is 
the original scheme adapted so that it doesn't take much memory and it 
awaits integration in the builds and (more importantly on the UI)
And given that we have the Active Antenna to think under the same context 
as well as an Ethernet adapter and that it operates at layer-3, lets stop 
calling it "MPP" and call it "Internet Sharing" from now on. I will submit 
a functional spec.


>  g) demonstrated in vienna, berlin, and athens with 600+, 800+, and
> ~2000 nodes.  Tradeoff: we can't route w/ CPU power turned off;
> doesn't make progress towards getting 802.11s working for gen2,
> probably requires further tuning for optimal performance in dense
> networks.
Again, we are interested in a MANET scenario much more than a WMN. We are 
doing the work so that code like that can run on the XO (in the form of 
the thin mac driver). I am sure that given the proper tools present on the 
XO, people will come up with interesting ways to use them. I don't see us 
putting a lot of resources in WMN operation though.


>  h) Ricardo looking at this?  No test bed that I know of. We know that
> tweaks are required to get any 802.11x standard to work in a dense
> scenario: media access protocols, probe request/response, beacon
> tuning, etc.  Marvell's done some of this tuning already, but we don't
> have any local resources validating/verifying behavior.
Why is that different from a) ? Will it be really hard to make spectrum 
out of thin air ? (OLPC's form of Alchemy I guess ;-).
Setting aside the fact that we still leak packets/frames occasionaly in 
the layer-2 stack, this is more about layer-7 than layer-2


> 
> Which should we invest in?  Which should we invest in most heavily?
> Let the politicking commence.
And let common sense prevail....

>  --scott
> 
M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080608/3b046993/attachment.html>