[Olsr-users] Looking for dev to make custom plug-in for our network

[Michel Blais]

Le 2013-01-10 15:21, Teco Boot a écrit :
>
> Op 10 jan. 2013, om 18:27 heeft Michel Blais het volgende geschreven:
>
>> I know it can be use by other network than adhoc. We use it with 
>> success over a fixed wirless network including wired part of the network.
> Sure, OLSR runs over whatever link, as long as it supports IP.
>
>>
>> To explain a little we're a WISP covering rural area. Some of our 
>> main backhaul use 24 Ghz frequency heavilly affected by rain. When it 
>> happen, olsr will flap a lot between this link and backup link since 
>> without traffic on the link, when olsr route the traffic on a other 
>> link, it don't have any lost so will try back this link again.
> Would the link be overloaded? Why is the link metric influenced by 
> user traffic? I assume you use ETX.

If signal become too low because of rain and the router try to pass the 
traffic through it, yes it will be overload. Now, when olsr stop passing 
traffic traffic through it, the link quality will be perfect.

>
>> We need to disable those link manually for now so what we was 
>> thinking was to make a plug-in that would check link signal via SNMP, 
>> check more often if signal is over a first threshold and cut it if 
>> signal is over a second threshold. Since you can't remove a interface 
>> from olsr without restarting it, we we're thinking about blocking via 
>> iptables olsr paquet (in and out).
> The trick is using link metrics, I think. You could try the old 
> link-cost implementation (didn't made it in olsrd). Or use the new L2 
> link metric. This one uses wifi driver info. Adjusting for SNMP would 
> be possible.
>
> I'm pretty sure Henning would point to DLEP. Not available today. But 
> yet, this is definitely the long term direction.
>
>>
>> The other thing was for QoS. What we was thinking was that OLSR could 
>> drop traffic shapping over a link until the're no lost on this link. 
>> With olsr paquet priorised, that would mean that every traffic 
>> priorised like VoIP would also don't have any lost and bulk taffic 
>> over traffic shapping could be drop by the router instead of send it 
>> via the wireless link and affecting latency. This plugin should also 
>> have a treshold that if traffic shapping goes lower than this 
>> treshold, link should be disable instead and a alert should be send.
> So your radio doesn't support QoS packet scheduling? And you want the 
> router to do it as front-end? The IETF DLEP proposal has some 
> mechanisms for it. But the radio must provide the feedback, e.g. queue 
> depth or flow control.

 From what I read, flow control broke TCP own flow control and create 
more problems than it solves. For queue deep, any way I think of are not 
real time. Maybe the're a protocole for it I'm unaware of.

I really think olsr message is the best way to monitor the link and 
adjust traffic shaping if link quality drop. It would also be compatible 
with any link regardless of fonction supported.

>
>>
>> I know Markus mentionned on this list that it's possible to priorise 
>> olsr paquet without using traffic shapping to have full throughput of 
>> the link but in our case, router and wireless link are not on the 
>> same device, it's impossible to change QoS rule on those wireless 
>> link and latency is more important than throughput.
> If it is a fixed rate radio, it is easy to set up a shaper on your 
> router. If rate is dynamic, but rather slow, you could set up some 
> scripts for dynamic adjustments.

Maybe it would be easy on private band without noise but on public band, 
you never know how much bandwith you have. In peak hour, the noise go 
higher because wireless spectrum is use more.

Yes I could use some script to fix my 2 problems but I think it would be 
more effective to do it directly into olsr instead of doing 2 external 
script that need to communicate with olsr.

Thanks

Michel
>
> Teco
>
>>
>> If the community want to do it, we could send a donation to the 
>> project (even if I don't see any way to do it on the web page) 
>> instead of paying dev for those plug in.
>>
>> Le 2013-01-10 11:35, Ben West a écrit :
>>> OLSRd can (and has been) used in media besides adhoc 802.11 wireless 
>>> networks.  Conceivably, one could use it on wired transport layers 
>>> like a coaxial cable network, old-school "thick" Ethernet with 
>>> vampire taps, and possibly even CAN.
>>>
>>> (Meaning there may be segments of the OLSRd community who would find 
>>> the plugins useful.)
>>>
>>> Are there any details about the desired features of the plugins you 
>>> are willing to share publicly?
>>>
>>> On Thu, Jan 10, 2013 at 8:59 AM, Michel Blais 
>>> <(spam-protected) <mailto:(spam-protected)>> wrote:
>>>
>>>     Hi all,
>>>
>>>     We are looking for a dev that could make us 2 custom olsrd
>>>     plug-in for our network.
>>>
>>>     Those plug-in would be useless for olsrd community since not for
>>>     ad-hoc network.
>>>
>>>     Of course, we would pay for the work.
>>>
>>>     If somebody interessted, please contact me outside of the list.
>>>
>>>     Thanks
>>>
>>>     Michel
>>>
>>>     -- 
>>>     Olsr-users mailing list
>>>     (spam-protected) <mailto:(spam-protected)>
>>>     https://lists.olsr.org/mailman/listinfo/olsr-users
>>>
>>>
>>>
>>>
>>> -- 
>>> Ben West
>>> (spam-protected) <mailto:(spam-protected)>
>> -- 
>> Olsr-users mailing list
>> (spam-protected) <mailto:(spam-protected)>
>> https://lists.olsr.org/mailman/listinfo/olsr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20130111/bcec1c0f/attachment.html>