[Commotion-discuss] distribution of load among gateways and speed gains?, (Dan Staples)

Sun Jun 1 21:34:38 EDT 2014

Hi John,

We definitely intend to add OLSRv2 as an option soon, though we also
intend to continue to support OLSRv1 until or unless it is completely
superseded. However, the question of whether it would do what you want
is complex, as there are at least three different factors at play.

The first, which is: can OLSR take gateway bandwidth into account when
it selects a gateway? This is actually something that OLSRv1 can do,
though we don't enable it by default as it's relatively new and fairly
complex. OLSRv1 has SmartGateway, which we enable by default and which
uses IP-over-IP tunnels in order to select and use gateways in such a
way that it helps to avoid breaking connections when a new gateway
becomes 'closer' (you have a better path to it) than your old gateway.
SmartGateway also provides parameters that are disabled by default for
tuning whether the capacity of the gateway is taken into account when
selecting which gateway to use (i.e., whether to sometimes use a fat
pipe that is further away than a thin pipe that is closer). However, the
values that a gateway advertises are not dynamic (OLSR has no inherent
way of 'knowing' how much bandwidth its upstream link has) so the values
it uses are upstream and downstream bandwidth parameters set manually in
the configuration file. So if you knew the speed of a particular
connection, you could set it manually in the config file and set every
other node in the network to take that into account when choosing a gateway.

Relatively recently, a plugin called sgdynspeed was added to OLSR. This
basically allow OLSR to periodically read a text file that contains
updated bandwidth values, and update what SmartGateway advertises for
that gateway accordingly. So what it would be possible to do is set up
some kind of automated bandwidth test that would write its results into
the text file, use sgdynspeed to read that text file and update OLSR's
values for that gateway, and have the other nodes in the network take
that into account when selecting a gateway. Thereby, you can allow for
your network to try and take which gateways are faster and which are
slower into account.

The second question is, what will OLSRv2 get you which will make this
work better? Now, I don't think that OLSRv2 actually has the
SmartGateway support described above ported to the new codebase yet
(though I'm not certain). However, what it does have is a better method
of choosing routes. OLSRv1 uses the ETX metric for deciding which links
to use in the network; ETX is basically just a measure of packet loss.
However, OLSRv2 by default uses an updated metric called ETT. ETT uses
not just packet loss, but link capacity as reported by the radio to
choose routes. ETT would, for instance, conceivably choose a 54Mbps link
with 10% packet loss over a 2Mbps link with 5% packet loss. So it won't
take faster gateways into account on its own, but it will more
accurately choose which gateway you have the best connection to.

The third question is, can you use more than one gateway at once in
order to multiplex uplink capacity? This question is a little more
complicated. The newest versions of SmartGateway (now dubbed
MultiSmartGateway) contain support for using multiple gateways at once.
However, to my understanding, this is designed to work in tandem with
another protocol called BRDP (Border Router Discovery Protocol). BRDP
basically sends information that allows each node to replace its default
route with a statistical table of available default routes.
Unfortunately, as far as I know, no practical implementation of BRDP yet
exists. If it ever does, however, OLSR is already set up to work with it
and would allow for multiple gateways to be used in tandem for a single
connection, dramatically increasing uplink capacity. This is an advanced
application of this capability, and would also need a network with full
IPv6 support as well as multi-path transport protocols like MP-TCP in
order to fully realize it. Also, without communicating to a host on the
internet that is also set up to make best use of it, this applies mostly
to the uplink and not the downlink; there isn't anything in standard
TCP/IP that makes a host aware of multiple return paths.

Anyway, sorry for the overly long explanation. The upshot is that
depending on what you want to do, some stuff is ready to go with OLSRv1
even if we don't turn it on by default, but other stuff may be a longer
way off than just upgrading to OLSRv2.

On Thu 29 May 2014 11:05:08 AM EDT, Dan Staples wrote:
> Upgrading to OLSRd version 2 is something we hope to do in the not too
> long future, perhaps within the next 6 months, but I really can't say
> for sure. For now, it's a limitation we have to live with.
>
> On 05/28/2014 12:43 PM, john coleman wrote:
>> Dan,
>>     as you say bummer.  Any idea when commotion will be moving to 
>> version 2 of OLSRd ?
>>     Also is there a work around the current behavior to link to the
>> nearest node? or do we just have to live with it 'till a switch to
>> version 2?
>> thanks for the info.
>> john
>>
>>
>> commotion-discuss-request at lists.chambana.net wrote the following on
>> 5/28/2014 11:00 AM:
>>>
>>> Hi John,
>>>
>>> As it currently works, OLSRd (the routing program we use) has a
>>> SmartGateway plugin to distribute gateways to the mesh.
>>> Unfortunately, the way this plugin works is to tell a node to use the
>>> nearest gateway it can find, without regard to the capacity or
>>> latency of that gateway compared to others. So, if my node is 1 hop
>>> away from a slow gateway and 2 hops away from a fast gateway, it will
>>> always choose the slow gateway (assuming link quality is relatively
>>> homogeneous). Bummer, I know.
>>>
>>> The good news is that, if I recall correctly, version 2 of OLSRd has
>>> a much smarter way of choosing gateways, that does in fact take into
>>> account gateway characteristics. So once we move to OSLRd version 2,
>>> that problem will hopefully be alleviated.
>>>
>>> But for now, we'll have to work around that limitation.
>>>
>>> hope that helps!
>>>
>>> Dan
>>>
>>> On 05/26/2014 10:27 AM, john coleman wrote:
>>>> Our neighborhood mesh is small but growing steadily.  We have
>>>> gateways on the mesh that vary by about 10 fold in speed.  Can
>>>> someone explain if and how the commotion mesh distributes load
>>>> between the gateways and if those linked to the wireless routers on
>>>> the slow gateways can expect any speed increase because of the
>>>> distributed load? Using common speed test websites
>>>> (www.speedtest.net and www.bandwidthplace.com) I see no gain in
>>>> speed by being linked to the mesh. However, I am unsure if those
>>>> types of speed tests are appropriate for a mesh network. When a
>>>> gateway goes down, the attached node switches to another gateway to
>>>> access the internet, as it should. But I can't see evidence that
>>>> nodes attached to slow gateways receive speed benefits by having
>>>> fast gateways on the mesh.  Any insights or pointers to, not too
>>>> technical, documentation?
>> thanks,
>> john
>> p.s. using PicoStation
>>>> M2-HPs  running grumpy cat 1.1rc1
>>>>
>>>> _______________________________________________ Commotion-discuss
>>>> mailing list Commotion-discuss at lists.chambana.net
>>>> https://lists.chambana.net/mailman/listinfo/commotion-discuss
>>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Commotion-discuss mailing list
>> Commotion-discuss at lists.chambana.net
>> https://lists.chambana.net/mailman/listinfo/commotion-discuss
>>
>
-- 
Josh King
Lead Technologist
The Open Technology Institute
http://opentechinstitute.org
PGP Fingerprint: 8269 ED6F EA3B 7D78 F074 1E99 2FDA 4DA1 69AE 4999

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.chambana.net/pipermail/commotion-discuss/attachments/20140601/403433bb/attachment.sig>