[Commotion-dev] Unifying Serval and Commotion Mesh

[Paul Gardner-Stephen]

Hello,

On Thu, Dec 20, 2012 at 7:06 AM, Josh King <jking at chambana.net> wrote:
> Hi Paul,
>
> Something I've thought about but which I should probably ask your
> opinion on: what do you think about the feasibility of a generic serval
>  MDP proxy which presents, say, a SOCKS interface or something for
> sending generic TCP/IP traffic through the overlay network?

Yes, that would be quite feasible, and is something that we have
thought about doing for a while.

The main ingredient needed would be "Reliable MDP", i.e., a TCP-like
reliable stream service to complement the UDP-like MDP.  This would be
quite feasible, but to do it right would take some effort. Naively
implementing TCP semantics is probably not the right solution.  It
probably makes sense to incorporate some of the Network Coding (see
http://www.mit.edu/~medard/papers2011/Modeling%20Network%20Coded%20TCP.pdf)
in this, so that packet loss doesn't get interpreted as congestion.

In the meanwhile, we do have an unofficial HTTP interface to Rhizome
that can be leveraged and extended to provide some internet-connected
services in the meantime. That interface is probably better for
providing off-grid content, and we have plans to implement distributed
content/learning management systems on this at some point.

Paul.

> On Wed 19 Dec 2012 03:31:53 PM EST, Paul Gardner-Stephen wrote:
>> OpenPGP: *Parts of the message have NOT been signed or encrypted*
>>
>> Hi All,
>>
>> From a Serval perspective, we chose to stick with IPv4 for a few reasons:
>>
>> 1. IPv4 headers are smaller, which on limited bandwidth is always a
>> good thing, especially when you start passing around lots of addresses
>> to manage your topology.
>> 2. At a global scale 64 bits of host address in IPv6 is actually a bit
>> marginal for avoiding collisions among randomly self-allocated
>> addresses.  This is more of a concern for networks consisting of very
>> mobile devices, such as phones.  Overall, it can probably be managed.
>> 3. IPv6 adds overhead without actually solving some of the more
>> important problems, such as preventing address spoofing, really
>> avoiding address collisions, and allowing easy end-to-end encryption.
>> Our view is that a public-key based overlay is a better solution,
>> which is why we have created one.  We dealt with the long-address
>> problem by baking in address abbreviation, so that the shortest unique
>> prefix of each address is used, reducing overhead to sub-IPv4 levels
>> in many cases, and combined overlay+IPv4 overhead to less than IPv6
>> overhead.
>> 4. IPv6 is not available on all devices we wish to support, e.g., some
>> Symbian phones, Windows Mobile phones, and very likely some Android
>> phones.  See http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems.
>> 5. We are creating digital packet radio interfaces for long-range
>> meshing that will have insufficient bandwidth to support IPv6
>> overhead.
>>
>> Of course, for Serval the equation is a little different, because
>> routing traditional TCP/IP traffic is not our highest priority.
>>
>> I should add that some of our team is more sympathetic to IPv6 than I
>> am, and that we don't see a problem with making use of IPv6 when it is
>> available, but, personally, I am somewhat reluctant to rely on it, and
>> harbor concerns about the increased overhead, at least unless some
>> sort of address abbreviation is used in the routing protocols (which
>> maybe it already is by now).
>>
>> Paul.
>>
>> On Thu, Dec 20, 2012 at 2:54 AM, The Doctor <drwho at virtadpt.net> wrote:
>>>
>>
>> ********* *BEGIN ENCRYPTED or SIGNED PART* *********
>>
>> On 12/19/2012 10:49 AM, stephane at shimaore.net wrote:
>>
>>> IPv6 in a non-Internet connected network is probably a good
>>> choice.
>>
>> I think that's what Resau Libre' does.
>>
>>> One thing to be careful about (for Internet-connected meshes), is
>>> that IPv6 connectivity is far from ubiquituous: the node(s) on the
>>> mesh that connect to the Internet might not be able to route IPv6,
>>> for example because their ISPs don't support it yet -- this should
>>> become less of an issue over time. Hopefully that's already taken
>>> into account by the mesh routing protocol.
>>
>> It's something of a surprise to find an ISP that does support IPv6.
>>
>> That said, the solution I've seen deployed in the field is v6-in-v4
>> tunneling at the gateways.  I haven't tried it myself but I'm told it
>> works.
>>
>>> Maybe more awkwardly, IPv6 and IPv4 are actually more like two
>>> separate technologies when it comes to connectivity: the same way
>>> that at some point in time you could access the Internet over IPX
>>> and over IPv4 (I'm showing my age..), nowadays you can access it
>>> using IPv6 and IPv4, but
>>
>> Not really.  I went hunting for floppy disks at $work this morning for
>> a spectrum analyzer.
>>
>>> Finally, I don't know about serval, but my experience with IPv6 and
>>> IPv4 and VoIP is that most stacks do not handle both together well;
>>> I'm not even talking about creepy situations where signaling might
>>> use one and media the other. >:)
>>
>> Whoa.  Bizarre...
>>
>> --
>> The Doctor [412/724/301/703] [ZS|Media]
>> Developer, Project Byzantium: http://project-byzantium.org/
>>
>> PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1
>> WWW: https://drwho.virtadpt.net/
>>
>> If it's not PGP signed, it didn't come from me.
>>
>>
>>
>> ********** *END ENCRYPTED or SIGNED PART* **********
>>
>>>
>>> _______________________________________________
>>> Commotion-dev mailing list
>>> Commotion-dev at lists.chambana.net
>>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>>
>>
>> _______________________________________________
>> Commotion-dev mailing list
>> Commotion-dev at lists.chambana.net
>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>
>>
>>
>
>
> --
> Josh King
>
> "I am an Anarchist not because I believe Anarchism is the final goal,
> but because there is no such thing as a final goal." -Rudolf Rocker
>