On Tue, Feb 10, 2009 at 12:41 PM, Henning Rogge <span dir="ltr"><<a href="mailto:rogge@fgan.de" target="_blank">rogge@fgan.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

It's a matter of mapping. We could map the raw transmission speed to a value<br>
between 0 and 1 and THEN combine it with the LQ from the ETX algorithm with a<br>
weighted sum.</blockquote><div class="gmail_quote"><div>combine with + or with * ??</div><div class="Ih2E3d"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Or we only use bandwith as a tie-breaker if the ETX value is smaller than 1.1<br>
(or something like this).</blockquote></div><div>way better i think, but of course this shoud be smoothed</div><div>somthing like this<br>(((ETX-1)*10)^x)/bandwidth<br></div><div>x>2</div><div>but i still want something else, which reflects layer 2 retries as well (see below)</div>
<div class="Ih2E3d">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<div><br>
> See above, why this isn't enough.<br>
</div>Markus Kittenberg told me about a 10 gbit/s fibre link in Vienna with 20%<br>
packet loss because of the bad fibre... I was a little bit shocked, but I<br>
understand the problem now.</blockquote></div><div>in fact we have no 10gbit at the moment in vienna* it was jsut a samnple<br><br>but we had packetloss on fibre links, and strange packetloss due to incompatible switches/gbit interfaces, an packetloss due to bad media-converters, and i have my own stories about packetloss due to bad copper wires</div>

<div>my point is only you can not trust ethernet, <br>and if ethernet has the speed to get really low costs (an we want it to have low costs!!!) we have to make sure there is no packetloss, and if we detect one, raise the cost to values similar too bad wireless links<br>

</div><div>cause we have no layer 2 error correction on ethernet,..</div><div>in fact a link with ETX of 20 has same amount of unicast packetloss than a ethernet link with ETX of 1.1<br></div>
<div>or to repeat it once again, i insist (*g) on layer 2 retry count to be used in the metric!! <br>(as usually we route 99,x% unicast traffic)<br>formula is simple<br></div><div>uncicast_lq = 1-(1-broadcast_lq)^retry_count</div>

<div>#1</div><div><br>if local and neighbour values are both better multiplicated or averaged, i`m unsure at the moment,..</div><div>if we have a default retry_count of 1 on all interfaces not detectable as wireless, everything is fine<br>

on wireless i would prefer getting the real retry count from driver, as i know differtent values on different hardware/plattforms for this (i know vlaues of 4 and 7)<br><br>if impossible to detect we should better use a lower one, and not 7<br>

</div><div>and if we offer a value in the config file to override this retry_count, this should be flexible enough,..</div><div>btw. 5ghz ptp bridges should usually also get retry_value of 1, as they usually have layer 2 corrections also on broadcasts!! </div>
<div class="Ih2E3d">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p><br>
> > If the link metric cost will have a higher range than ETX we might be<br>
> > forced to drop fisheye and develop some cost-change based link interval<br>
> > system.<br>
><br>
> ACK. fisheye is one of those nasty things, that don't make all this easier.<br>
</p>Markus had the idea to use something like fisheye in the forwarding function.<br>
If the LQ change is not higher than some function depending on the TTL, you<br>
don't forward the packet.</blockquote></div><div>and depending on the lnik cost of the links the packet came from (and go to)<br>a minor update coming from a high cost link, or go over high cos tlink, is droppable, while it is not while there are low costs neighbours to inform about</div>

<div>one implementation option would be to interprete ttl (below 128) as costtolive, and every node degrades it by the cost of the link it came over it, or a minimum value of 1</div><div><br>maybe a translation function between link_cost and "ttl_cost" is needed of course</div>

<div>this aproach may be somewhat compatible to existing fisheys, as packet with ttl 8 or 16 would still be somewhat meaningful, while ttl 255 would still travel more than 128 hops,..<br></div><div>but still interoperability would be very limited, and is not very desireable to mix this interpretations of ttl,.. *g</div>

<div>Markus</div><div>#1<div>based onthis ETTlike metric than could be </div><div>cost=(1/(unicast_nlq*unicast_lq))/(netto_bandwidth+neightbour_netto_bandwidth)</div><div>netto_bandwith is either reporting by the hardware or calculated by <br>

netto_bandwith=brutto_bandwidth*lq</div><div><br></div> </div></div><br>
<br>