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

Mon Jun 2 13:27:53 EDT 2014

josh,
thanks for the explanation. a little above my pay grade but I think I understand.  Interesting stuff.
If I can figure out how to, maybe I'll experiment with the options in OLSRv1.  However, what I'm probably looking for is dynamic gateway selection or possibly what you call multiplex uplink capacity.  Those sound complicated and not likely to be implemented in the near future.
thanks again,
john

commotion-discuss-request at lists.chambana.net wrote the following on 6/2/2014 11:00 AM:
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 01 Jun 2014 21:34:38 -0400
> From: Josh King <jking at opentechinstitute.org>
> To: Dan Staples <danstaples at opentechinstitute.org>
> Cc: commotion-discuss at lists.chambana.net
> Subject: Re: [Commotion-discuss] distribution of load among gateways
> 	and speed gains?, (Dan Staples)
> Message-ID: <538BD4AE.3040509 at opentechinstitute.org>
> Content-Type: text/plain; charset="utf-8"
>
> 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
>>>