<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Le 2013-01-10 15:21, Teco Boot a
écrit :<br>
</div>
<blockquote
cite="mid:889FE019-714D-4443-9FD6-910CB439F8A8@inf-net.nl"
type="cite"><br>
<div>
<div>Op 10 jan. 2013, om 18:27 heeft Michel Blais het volgende
geschreven:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">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.<br>
</div>
</div>
</blockquote>
<div>Sure, OLSR runs over whatever link, as long as it supports
IP.</div>
<br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"> <br>
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.</div>
</div>
</blockquote>
<div>Would the link be overloaded? Why is the link metric
influenced by user traffic? I assume you use ETX.</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:889FE019-714D-4443-9FD6-910CB439F8A8@inf-net.nl"
type="cite">
<div><br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"> 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).<br>
</div>
</div>
</blockquote>
<div>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.</div>
<div><br>
</div>
<div>I'm pretty sure Henning would point to DLEP. Not available
today. But yet, this is definitely the long term direction.</div>
<div><br>
</div>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"> <br>
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.<br>
</div>
</div>
</blockquote>
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.</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:889FE019-714D-4443-9FD6-910CB439F8A8@inf-net.nl"
type="cite">
<div><br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"> <br>
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.<br>
</div>
</div>
</blockquote>
<div>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.</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks<br>
<br>
Michel<br>
<blockquote
cite="mid:889FE019-714D-4443-9FD6-910CB439F8A8@inf-net.nl"
type="cite">
<div>
<div><br>
</div>
Teco</div>
<div><br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"> <br>
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.<br>
<br>
Le 2013-01-10 11:35, Ben West a écrit :<br>
</div>
<blockquote
cite="mid:CADSh-SP6njowanaqXfrbtXXABw4RtScjhbH98D09WvY74eq8fw@mail.gmail.com"
type="cite">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.<br>
<br>
(Meaning there may be segments of the OLSRd community who
would find the plugins useful.)<br>
<br>
Are there any details about the desired features of the
plugins you are willing to share publicly?<br>
<br>
<div class="gmail_quote"> On Thu, Jan 10, 2013 at 8:59 AM,
Michel Blais <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:michel@targointernet.com"
target="_blank">michel@targointernet.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi
all,<br>
<br>
We are looking for a dev that could make us 2 custom
olsrd plug-in for our network.<br>
<br>
Those plug-in would be useless for olsrd community
since not for ad-hoc network.<br>
<br>
Of course, we would pay for the work.<br>
<br>
If somebody interessted, please contact me outside of
the list.<br>
<br>
Thanks<span class="HOEnZb"><font color="#888888"><br>
<br>
Michel<br>
<br>
-- <br>
Olsr-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:Olsr-users@lists.olsr.org"
target="_blank">Olsr-users@lists.olsr.org</a><br>
<a moz-do-not-send="true"
href="https://lists.olsr.org/mailman/listinfo/olsr-users"
target="_blank">https://lists.olsr.org/mailman/listinfo/olsr-users</a><br>
</font></span></blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div>Ben West</div>
<div><a moz-do-not-send="true"
href="mailto:me@benwest.name" target="_blank">me@benwest.name</a></div>
</blockquote>
</div>
-- <br>
Olsr-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:Olsr-users@lists.olsr.org">Olsr-users@lists.olsr.org</a><br>
<a class="moz-txt-link-freetext" href="https://lists.olsr.org/mailman/listinfo/olsr-users">https://lists.olsr.org/mailman/listinfo/olsr-users</a></blockquote>
</div>
<br>
</blockquote>
</body>
</html>