[serval-project-dev] Why wireless mesh networks wonbt save us from censorship

[Paul Gardner-Stephen]

Hi Steve,

Jeremy has already answered your questions well from a Serval
perspective, but I offer my perspective as well.

On Sun, Nov 27, 2011 at 8:22 PM, Song, Stephen <stephen.song at gmail.com> wrote:
> On 27 November 2011 11:32, Jeremy Lakeman <jeremy at servalproject.org> wrote:
>> "Reason 1: Management is hard and expensive."
>> That's why we want a network that auto-discovers topology. And
>> provides easy to use debugging information to assist in placement of
>> additional nodes.
>
> I agree that there is lots of scope for improving this. B Computers
> used to be hard to use and Apple has succeeded in making them stupidly
> easy. B This can happen for mesh networks too.

Absolutely agree here.  Indeed, Serval has worked from the outset to
make mesh telephony insanely simple to use, and I think we have made
significant advances on the state ease of use and management of mesh
networks in the process, with more innovation in the pipeline.

>> "Reason 2: Omni-directional antennas suck. ... Reason 3: Your RF
>> tricks wonbt help you here. ... Reason 4: Single-radio equipment
>> doesnbt work; multi-radio equipment is very expensive."
>> Fair enough. But we don't actually plan to build a wifi mesh network
>> covering the globe. One un-censored connection to the internet is
>> enough to join each little mesh network into the global internet.
>> Store and forward; and wandering nodes may be enough to enable *some*
>> communication in places where there isn't enough coverage yet for
>> real-time traffic. Some communication is better than none.
>
> The directional versus omnidirectional debate is a bit of a
> red-herring I think. B The author seems to be assuming that all
> connections would be distant or at the edge of WiFi capacity. B If mesh
> nodes are reasonably close you could actually consider turning the
> radio power down as opposed to up which would reduce interference.
> Also, there is no reason not to have a "directed" mesh where
> semi-directional devices like nsIIs or similar cover an arc of a
> community. B  There are lots of creative things that can be done here
> such as mesh segmenting, supernodes, etc. B Perhaps that would
> disqualify them from being traditional mesh networks but who gives a
> stuff about that?

We agree heartily.  Pure mesh networking fails in the way that a lot
of other pure pursuits fail.
But some judicious symmetry breaking can yield large dividends, and
this is the approach we are already
pursuing, e.g., by using the internet for backhaul when it is available.

>> "Reason 5: Unplanned mesh networks break routing"
>> Well, partly. Sure you're going to use bandwidth in order to compute
>> routing paths. But I think this is not insurmountable. Definitely
>> needs to be more work in this area though to ensure you avoid routing
>> loops and black holes. And this is something that we are already
>> researching and plan to tackle further.
>>
>> "unplanned wireless mesh networks never work at scale"
>> Yep, there's an "event horizon" issue. If you spend too much bandwidth
>> describing remote paths through the network, you'll have nothing left
>> for actual data. So we absolutely need to limit the distribution of
>> full topology information to ensure that local nodes can still
>> communicate even if the greater mesh network is practically infinite.
>> Beyond that limit you either interconnect via the internet, or we
>> invent some other high level structure, address prefix / numbering
>> scheme.
>
> So, from a Serval perspective this seems to be a good question. B If
> the mesh protocol takes 1-2 minutes to "settle", how is it possible
> for a mesh network based on moving mobile phones to update routes fast
> enough to keep up. B Unless I miss something, the mesh routing is going
> to be constantly playing catch up unless everyone stays still.

We have some early work on very fast converging mesh networks in
certain circumstances that we expect to map across at the right time.
Basically, I have confidence that this can be substantially worked
around.
Also, the use of UHF/TVWS spectrum, low bit-rates and simple waveforms
offers great potential to work around much of the problem in other
creative ways, for example by switching voice calls to a
very-long-range but very-low-bit-rate circuit, that would be capable
of carrying a call over a single hop that would otherwise require
perhaps half a dozen hops at higher bit-rate.  Frequency hopping to
make interference statistical is also a great help here.
I am still writing up our initial plans in this space, and will make
them public once we have a decent draft.

> Have you guys done any testing of say 10 phones or more in a field
> environment?

As Jeremy has said, we have, and BATMAN has performed quite poorly.
Part of this is really easy to fix, in that the link score calculation
is slow to reflect lost links, and not fast enough to grab new good
links.  But we expect other interesting effects to emerge as we work
on this.

>> There are 2 billion(-ish) people out there with no affordable access
>> to communications. This is absolutely a problem we should be
>> dedicating time to solve. Not just to "fight Internet censorship", but
>> to allow these people to be heard.
>
> Three unique problems:
>
> 1) B provide affordable communication infrastructure for those for whom
> access is either unavailable or unaffordable, the so-called other
> 2-3billion
> 2) B provide resilient alternative communication infrastructure to
> ensure that communication is not restricted by centralised control
> 3) B provide easy-to-deploy infrastructure for use in crisis/disaster
> relief scenario
>
> Mesh network infrastructure can potentially address all three of those
> issue but your technology development priorities will change depending
> on which one of the above is your mission. B Which one is Serval's
> mission?

I think I am inclined to agree with Jeremy that we see a common
technology that is able to address all three fairly well.  For
example, (3) needs fool-proof deployment and management-free
operation, but so does (1) and (2), but for different reasons. So we
see the solution as requiring:

- zero-configuration
- tolerance of partitioning of the network
- ability to scale, and maintain local operation when scaling beyond
the bandwidth-limit event horizon.
- security
- use of existing phone numbers

What differs for each use case is in some ways limited to how people
use this platform, but fundamentally they all depend on the common
ability of a phone to make/receive calls,sms,mms other data without
recourse to infrastructure, and offering individuals the degree of
privacy and security, and to some extent, the reliability, that people
expect from a telephone network.  Our Rhizome store-and-forward
approach is a key element in all this, because it allows for almost
insect-like persistence of retrying delivery, so that the instant a
passage through the network becomes available it can be exploited.
Also, Rhizome solves the nasty exponential bandwidth and arrival
probability problem that otherwise hamstrings multi-hop wireless
meshes.

In fact, I would say that the fundamental reason why we think we (and
this includes Village Telco) are able to make mesh networking work, is
because we have focussed on a telephony-oriented model, where data
volumes are lower, and where the user interface is simplified to
telephone-level, which people understand, and which equally
importantly, hides all of the mess underneath.

It is also why we are not afraid of our planned overlay mesh network
not being backward compatible for use by non-Serval-aware
applications, as it will keep them from making inefficient and
inconsiderate use of bandwidth, while allowing the use of the various
innovations we have prototyped and have on the drawing board. On this
note, we hope to be able to share a technology roadmap for the next 12
months in coming days.

Paul.

> Cheers... Steve
>
>> On Sun, Nov 27, 2011 at 7:17 PM, Alasdair Mclellan
>> <alasdair at servalproject.org> wrote:
>>> Hmm,
>>> There are a bunch of good points in this article, but none of them take into
>>> account the simple facts that;
>>> 1) An unplanned mesh is better than nothing (and 'nothing' is our primary
>>> use case), and
>>> 2) Everyone has a handset.
>>> Replacing the Internet with an unplanned mesh is, indeed, hard - especially
>>> when you need a dedicated node type to do so. Using people's existing
>>> handsets changes the game a bit (although exactly how much remains to be
>>> seen).
>>> Just my quick $0.02.
>>> Cheers,
>>> --
>>> Alasdair.
>>>
>>> On Sun, Nov 27, 2011 at 5:54 PM, Ben Hughes <ben at benrhughes.com> wrote:
>>>>
>>>>
>>>> http://sha.ddih.org/2011/11/26/why-wireless-mesh-networks-wont-save-us-from-censorship/
>>>>
>>>> Via hackernews. Would be interested in hearing what tguys think, seeing as
>>>> you have lots of real-world experience.
>>>>
>>>> Ben
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups
>>>> "Serval Project Developers" group.
>>>> To post to this group, send email to
>>>> serval-project-developers at googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> serval-project-developers+unsubscribe at googlegroups.com.
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/serval-project-developers?hl=en.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Serval Project Developers" group.
>>> To post to this group, send email to
>>> serval-project-developers at googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> serval-project-developers+unsubscribe at googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/serval-project-developers?hl=en.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
>> To post to this group, send email to serval-project-developers at googlegroups.com.
>> To unsubscribe from this group, send email to serval-project-developers+unsubscribe at googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en.
>>
>>
>
>
>
> --
> Steve Song
> http://manypossibilities.net
> http://villagetelco.org
>
> --
> You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
> To post to this group, send email to serval-project-developers at googlegroups.com.
> To unsubscribe from this group, send email to serval-project-developers+unsubscribe at googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To post to this group, send email to serval-project-developers at googlegroups.com.
To unsubscribe from this group, send email to serval-project-developers+unsubscribe at googlegroups.com.
For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en.

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE