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

[Alex Pankratov]

I am aware of at least one fairly big firewall vendor whose devices
default to 20 sec UDP rule lifetime. It is even less if the traffic
is unidirectional (ie 'unconfirmed' by the recepient). We are using
20 sec and seems to work fine for our purposes.

Alex

David Barrett wrote:

> 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
> _______________________________________________
> p2p-hackers mailing list
> p2p-hackers at zgp.org
> http://zgp.org/mailman/listinfo/p2p-hackers
> _______________________________________________
> Here is a web page listing P2P Conferences:
> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
> 
>