<div class="gmail_quote"><br><div class="gmail_quote"><div class="Ih2E3d">On Tue, Feb 10, 2009 at 3:17 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">
> > between 0 and 1 and THEN combine it with the LQ from the ETX algorithm<br>
> > with a<br>
> > weighted sum.<br>
><br>
> combine with + or with * ??<br>
for example like this:<br>
<br>
LQ = ETX-LQ * a + Bandwith-LQ * (1-a)</blockquote></div><div>ok sry, i should have read, you already said you want a weighted sum above *g </div><div class="Ih2E3d"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> somthing like this<br>
> (((ETX-1)*10)^x)/bandwidth<br>
> x>2<br>
Seems to be a little bit complicated for integer arithmetics.</blockquote></div><div>i assume you can do quite similar smoothing with integer arithmethics</div><div>imho first we have to find what may be good, than how to implement it good </div>
<div class="Ih2E3d">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<div>ic)<br>
> formula is simple<br>
> uncicast_lq = 1-(1-broadcast_lq)^retry_count<br>
> #1<br>
</div>not good... ETX metric works because it does NOT try to calculate unicast<br>
loss. This way we get bad LQs before unicast starts to degrade.</blockquote></div><div><br>but ignoring unicast loss completely brings us to much more unwanted behaviour</div><div> </div><div>and (btw. broadcast) loss degrades the netto bandwidth i used below for my complete cost function,..</div>
<div class="Ih2E3d">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
But I think we have lot's of time to experiment on linklayer aware metrics.</blockquote></div><div>ACK, this was just one option to put this in,.. </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>
> if local and neighbour values are both better multiplicated or averaged,<br>
> i`m unsure at the moment,..<br>
> if we have a default retry_count of 1 on all interfaces not detectable as<br>
> wireless, everything is fine<br>
> on wireless i would prefer getting the real retry count from driver, as i<br>
> know differtent values on different hardware/plattforms for this (i know<br>
> vlaues of 4 and 7)<br>
</div>This would be included in the "bandwith" value we can get from the rate<br>
control algorithm. Because it includes retransmissions.</blockquote></div><div>but this includes it only linear,<br><br></div><div>but unicast loss behaves for sure not linear to broadcast_loss or netto_bandwidth!!</div>
<div>of course having the number of failed retransmission would be the best, and i think this values is available from maclayer,..<br>this would imho be the only perfect solution, ...<br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Modern drivers do NOT repeat a packet x times with the same speed, so we<br>
cannot just take the retry count.</blockquote><div> </div></div><div>yes we can! *g</div><div>as this is only an assumption<br>it`s also a bad-assumption to use the bradcast-rate loss as input for calculation unicast_loss of other wireless rates,..<br>
</div><div>the point is i prefer doing some bad assumptions on it, instead of ignoring it<br></div><div>if the driver will just perform better than our expectations, this is ok for me,..<br>i just dislike it the other way round,..<br>
</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>
> if impossible to detect we should better use a lower one, and not 7<br>
> and if we offer a value in the config file to override this retry_count,<br>
> this should be flexible enough,..<br>
</div>No, that's a BAD idea... either we detect it from the maclayer or we don't use<br>
it. Making values like this (which can change from kernel to kernel !)<br>
configurable sounds like a desaster waiting to happen.</blockquote><div> </div></div><div>there will always be interfaces where you will not be able to detect it,.. <br>because they are inside a different piece of hardware for example (our beloved/hated 5ghz bridges for example)</div>
<div>the question is what is the bigger disaster:<br> ignoring it, or making it possible to configure it wrong,..</div><div>but one way out of this dilemma is just to detect unicast loss with test packets, at least when we can`t detect it from maclayer<br>
<br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<div>> and depending on the lnik cost of the links the packet came from (and go<br>
> to) a minor update coming from a high cost link, or go over high cos tlink,<br>
> is droppable, while it is not while there are low costs neighbours to<br>
> inform about<br>
</div>Hmm... I think we have to draw some graphs on a paper to see if this idea<br>
really works.</blockquote><div> </div></div><div>hmm, on an offline or an online piece of paper?</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>
> one implementation option would be to interprete ttl (below 128) as<br>
> costtolive, and every node degrades it by the cost of the link it came over<br>
> it, or a minimum value of 1<br>
??</div></blockquote></div><div>*g</div><div> </div><div>maybe we should make at least voip conf on this thread soon,.. *g<br>(maybe including an online piece of paper)<br></div><div></div><font color="#888888"><div>Markus</div>
</font></div>
</div><br><br>
<br>
<br>