<br><br><div class="gmail_quote">On Tue, Feb 10, 2009 at 1:04 PM, Markus Kittenberger <span dir="ltr"><<a href="mailto:Markus.Kittenberger@gmx.at">Markus.Kittenberger@gmx.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">> Yes, I agree this is a good idea. But to trigger the issue I'm discussing<br>
> you don't need fluctuating links. Just two alternativ high cost links<br><p>
> that are both changing at low relativ rate in the same direction.</p></div><p>hmm changes at a low rate, should not be announced, until they get relevant i think,..<br>so we need less TCs</p><p>and are u really sure that a change in a high cost link, will make troubles? if there is no fisheye, and no packetloss on the low-cost links, and no bugs?</p>

<p>sample</p><p>A-B cost 1000<br>A-C cost 998<br>B-C cost 1</p><p>i think you are frightened, that if A-C changes to 1002 (a very small change compared to costs of 100 but a</p></blockquote><div>i meant 1000 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<p> huge one compared to cost of 1)</p><p>and due to packetloss only C gets informed about,..</p>
<p>if now C want to send somethin to A it will send to B csot of 1001 (1+1000)<br>but B will send it back to C as B thinks this means costs of 999 (1+998)</p><p>but: if there`s no fishey and no packetloss, C would have told B of the cost-change between A-C, and everything is fine</p>

<p>of course above assumptions about no fisheye (causing packetloss at arbitray positions) and no packetloss on low-cost links MUST hold true, to have only very short lived loops, </p></blockquote><div>and of course there has to be something done to make them extremely short lived,..<br>
that means forwarding speed of topology, and spf intervals!! have to be lowered (currently 10 seconds in fff)<br>(imho (to repeat maysel also *g) we need a incremental spf-algo) </div><div></div><div>because such minor cost changes between 998 and 1001 as in aobe sample, well happen all the time, and may cause a route flap</div>
<div></div><div>while currently now with ETX values mostly between 1 and 5 very seldomly cost_changes occure which are big enough to cause routing to change,..</div><div></div><div>but with large metrics, this may happen regulary</div>
<div></div><div>of couse as already proposed in this discussion, only significant (e.g. 10%) changes to costs shoudl be announced, to lower number of tcs in the network</div><div></div><div>cause only with not-so-much tcs an incremental spf will work efficient, and we have less bandwidth-consumption, and cpu for parsing packets, an we can even sign/encrypt remaining packets, and so on,..</div>
<div></div><div>(@Harald) </div><div>while i think it`s possible to use wide-range metrics with olsr very well (after several changes!!)</div><div>is still expect, if one would throw in ETT into a big mesh, with enough hops with current olsr with typical freifunk-settings, the network would reduce itself to proper connectivity only over fast&stable links, "hiding" users on low speed links behind always changing loops,.. (as long as they have multiple alternatives to reach the low-cost part of network)</div>
<div></div><div>in fact if you sit around and wait after you thowed into a mesh, olsr +ett would kill the mesh approach, as people not having fast links, would have to make sure they have only one link, as having multiple ones, will kick them offline all the time,... and so on ....</div>
<div></div><div>but as we already have this discussion here, and many approaches in it to solve this issues, i expect that when everything is done, and we "throw" the result into a mesh, everyone would be very happy getting rid of ETX+olsr, and no catastrophes will happen with wide-range metrics (only some usual implementation bugs *g, but no "logical" ones)</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><p><br><br></p><div class="Ih2E3d">
> Sorry, I have been (too) short: What I wanted to write was: "funkfeuer tends<br>
> to have long *default* routes compared to freifunk". I don't have any<br>
> actual data about freifunk networks but I would be very surprised if this<br><p>
> was wrong. And loops in the default route is, what people usually notice ...<br></p></div><p>Yes but actually (see my previous mail) we have the peak at 3 hops from main gateway (viviroof) to a node<br><br>and the return path is about 0,5 hops shorter in average, as more than halve of 0xff nodes reach a secondary (outgoing only) gateway (kryptaroof, tunnelserver) one hop earlier than they would reach viviroof, <br>

</p>
<div><div>so we have mostly very short routes here in vienna</div><div>but i think with multiple uplinks a freifunk-mesh should behave even shorter, regarding default routes<br>
of course routes from one node to all others nodes in a freifunk-mesh would tend to be longer as in veinna, as there is no usually no centralistic (backbone) aproach in them,..<br></div><div>
so i want some useful data to compare, but it not so important, there should be NO LOOPs <br>and then whether the route has usually about 3 hops or 5 hops is quite unimportant,.. *g</div></div><br>
</blockquote></div><br>