Agreed, those would be good ways of getting a more accurate read. As for how they change, I saw that mappings would increase their timeout with age. I distinctly remember at least one mapping that would start at just a couple seconds, but then gradually ramp up to 256 seconds (I stuck with powers of two). I also recall some mappings that would stay constant for a long time and then suddenly decrease, but I had no indication as to what triggered the change.
-david Richard Price wrote: > Thanks David, > > Yes it makes sense but the algorithm by doubling and halving the > intervals may never get close to the actual timeout value. > > You could slowly increase the interval and then rapidly decrease it upon > a timeout. Like in the TCP congestion control algorithm. > > But I do see the benefit of using a test port and only allowing the live > traffic port to use the last "safe"estimate discovered. > > Does anyone know of any any studies on how NAT timeouts tend to change? > There is a very interesting study by Cornell (below) which discusses the > distribution of NAT timeouts for TCP but not how they evolve over time. > > http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf > > I'm currently doing some research on keepalives in a P2P setting, and > adapting to NAT timeouts hasn't really been addressed as far as I know. > > Thanks again, > > Richard. > > > David Barrett wrote: >> Hi Richard, sorry for the slow response. It works like this: >> >> I use two UDP ports: one for testing, one for live traffic. >> >> With the test port I send a single UDP packet to a central server, >> containing a timeout value. I think the message was something like: >> >> PING >> Delay: 1000 >> >> The server just holds onto this message as long as requested, and then >> sends it back to the apparent host from which the packet was sent. If >> the delay is less than the NAT timeout, then it'll get through and the >> client will know "ok, 1000ms is fine", at which time it doubles the >> timeout and tries again. If the client doesn't get the response on >> time, it concludes that the delay is longer than the NAT timeout, and >> then halves the delay and tries again. This continues indefinitely, >> which is important because NAT timeouts have a nasty habit of changing >> spontaneously (such as with NAT load). >> >> The whole purpose of this test port is to estimate the NAT timeout by >> gradually ramping up a "safe" estimate until it is no longer safe. >> >> With that in hand, you can use this safe estimate for setting your >> keepalive period with peers: just make sure you send and receive a >> response (either natural through real traffic, or artificial through a >> PING) within that safe window and you're good to go. To be extra >> safe, I actually have both sides perform this calculation, which is >> perhaps a bit wasteful, but works well enough. >> >> Does that make sense? What are you using this for? >> >> Good luck! >> >> -david >> Follow me at http://twitter.com/quinthar >> >> Richard Price wrote: >>> Hello David >>> >>> I'm interested in the adaptive algorithm you used to determine >>> keep-alive frequency in iGlide. Unfortunately, I couldn't find any >>> documentation directly about it. >>> >>> Here's a little snip-it you posted on the P2P hackers mailing-list a >>> while back which caught my eye. If you've any further information I'd >>> be really interested to read it. >>> >>> Kind regards, >>> >>> Richard Price. >>>> But another entirely separate (and more valuable?) use of keepalives >>>> is to >>>> keep NAT mappings alive in a hole-punching scenario. With iGlance >>>> (which is >>>> being presented at CodeCon on Saturday) I use an adaptive approach >>>> where I >>>> look for the slowest keepalive frequency that works. Adaptiveness is >>>> critical, as I've seen some NATs that start with 5-second windows, >>>> but grow >>>> up to 256-second windows over time. >>> >> > > _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
