<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Op 14 dec. 2011, om 12:53 heeft Markus Kittenberger het volgende geschreven:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Wed, Dec 14, 2011 at 11:52 AM, 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">
A default of 1.0 is bad: flapping NAPT and broken connections.<br>
A default of 0.0 is bad: stick to SGW with bad path: lousy<br>
(thus broken) connectivity.<br>
So we have to pick something in between.<br></blockquote><div>ACK</div><div><br></div><div>i guess i am fine with anything in the 0.25 to 0.5 range (-;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I used NATthreshold 0.9. This was already loopy.</blockquote><div>yep nat-theshold is nearly worthless,..</div><div><br></div><div>btw what about "deprecating" it?</div><div><br></div><div>@Ferry</div><div><br>
</div><div>i asume trying to have a default value that really suits highly mobile and static city-meshes is impossible,..</div></div></blockquote><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><br><blockquote type="cite"><div class="gmail_quote"><div><br></div><div>(but ACK 0 id definitely not the answer, as its an extreme, that i guess only very seldomly will be used (if its not the default anymmore))<br>
but it s a configuration parameter, i.e. changeable (-;<br><br></div><div>and smartgateway allows it to be changed on a per user/node basis without negative side effects for others,..</div><div><br></div><div>so the default just needs to be somewhat sane, .. (even for mobile users)</div>
<div>therefore i prefer to keep leaning towards the original (nearly change ever) behaviour, and set e.g. 0.33 as default,..</div><div><br></div><div>btw. in theory on node could in future also have multiple (differently configured/used) tunnels, ..<br>
<br></div><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>So new long lifetime connections take 2nd best path, or worse?</div><div>I didn't try conntrack for this, but what is wrong with it? (other than make it happen...) </div><div><br></div><div>With IPv6, 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><br></div><div>Teco </div><br><blockquote type="cite"><div class="gmail_quote"><div><br></div><div>Markus</div></div>
</blockquote></div><br></body></html>