<br><br><div class="gmail_quote">On Wed, Dec 14, 2011 at 8:28 PM, Teco Boot <span dir="ltr"><<a href="mailto:teco@inf-net.nl">teco@inf-net.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div class="im"><blockquote type="cite"><div class="gmail_quote"><div>i asume trying to have a default value that really suits highly mobile and static city-meshes is impossible,..</div>
</div></blockquote></div><div>What about trying to be smart: when candidate is far better than current, change fast (but not to fast). So we count the elections of a better candidate, and switch based on better path and duration it is the best.</div>
</div></div></blockquote><div><br></div><div>no bad idea (if i got it right), but might need more parameters to define this smartness,..</div><div><br></div><div>e.g. a slow and a (lower) fast-SGW-Threshold <br>and a slow-SGW-Threshold-duration value,..</div>
<div><br></div><div>and if a new gateway is fast-SGW-thresh better olsrd should switch "instantly"<br>but if new gateway is only by slow-SGW-thresh better, olsrd shoudl switch only after it is/was always better for a full slow-SGW-Threshold-duration,..</div>
<div><br></div><div>but such smart/configuration/code "heavy" stuff, should imho really be a plugin!!</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">
<div><div class="im"><br><blockquote type="cite"><div class="gmail_quote"><div>e.g. to seperate between stable gateways for long lasting connections that should no change gateway, and other traffic classes where it does not hurt much to change gateways, and additinoal maybe even use no tunnel (and always the nearest gateway) for some traffic for example  dns or ntp requests</div>

<div><br></div><div>(and this needs no conntrack support to realize, just some simple traffic classification, and anhancements to olsrd to maintain/configure multiple SGW tunnels)</div></div></blockquote></div><div>So new long lifetime connections take 2nd best path, or worse?</div>
</div></div></blockquote><div>yes, but at least they can live long,.. (-;</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">
<div><div>I didn't try conntrack for this, but what is wrong with it? (other than make it happen...) </div></div></div></blockquote><div>olsrd currently does not need a patched kernel, for any of its features (which is great!)<br>
<br>but having conntrack and SGW (and routing) work seemless together would!<br>(or at least i have no idea to make it happen without kernel modifications)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><br></div><div>With IPv6</div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">
<div><div>, traffic classification could be based on source address prefix mapping to corresponding exit link. IETF Homenet workgroup is looking for such. Having it, SmartGateway would get deprecated, as all routers forward to right border and no NAT is in use. And no connection state at all in routers. No encap, no MTU problems. And my favorite: multi-path.</div>
</div></div></blockquote><div>yes, </div><div><br></div><div>btw some if not all of this could already be done with ipv4 too (-;<br> (if one happen to have enough adresses) </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><br></div><div>Teco </div><br><blockquote type="cite"><div class="gmail_quote"><div><br></div><div>Markus</div></div>
</blockquote></div><br></div></blockquote></div><br>