[p2p-hackers] NAT hole-punch keepalive/timeouts

[David Barrett]

Ok, next question: What kind of keepalive period do you used to maintain 
the holes you so meticulously punched?

I'm in the process of testing my NAT hole-punching solution, and I'm 
finding erratic behavior that I *think* is caused by my holes closing on 
me.  (Ie, I'm able to receive from a peer for a time, and then I 
cannot.)  So I'm implementing a keepalive, but I'm unsure of what period 
to use.  For now I'm just using a fixed 20-second period, but I have no 
idea if that's high or low.

Another option is to have some kind of adaptive solution that tracks 
elapsed time between sent and received data (thus estimating the last 
known 'good' window), but that's a pain I'd prefer to avoid.

Any suggestions?

The IETF BEHAVE group has discussed recommendations from anywhere 
between 30 seconds 
(http://list.sipfoundry.org/archive/ietf-behave/msg00441.html) and 15 
minutes (http://list.sipfoundry.org/archive/ietf-behave/msg00127.html). 
  But ultimately those are foward-looking discussions, and therefore not 
relevant.

In the real world, I've seen mention that even 30 seconds is 
insufficient 
(http://www.frameip.com/nntp/article-comp-protocols-tcp-ip.php?numero=20119). 
  Perhaps 20 seconds works 
(http://www.tisc2001.com/newsletters/322.html), but who knows.

Basically, I'm curious what keepalives you've found work today in your 
real applications, in the real world.

-david