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

[David Barrett]

Ah, thanks for the breakdown -- I hadn't considered the need for a 
return packet.  Do you have any stats on what fraction of NATs are 
outbound/inbound/both refresh, and per session/mapping?  Does it 
correlate with the overall NAT type (full cone, etc), or is it 
unrelated?

Also, thanks for confirming the 20-second keepalive.

-david

On Mon, 6 Jun 2005 2:26 am, Gaballo Luca wrote:
> A NAT can be:
> - "Outbound refresh": keep the mapping active when a packet goes from 
> the internal side of the NAT to external side
> - "Inbound Refresh": keep the mapping active when a packet goes from 
> the external side of the NAT to internal side
> or both!
>
> Moreover the NAT Mapping Refresh Scope can be:
> - "Per Mapping": refresh for all session on that mapping by any 
> outbound traffic
> - "Per Session": refresh on a specific session on that particular 
> mapping by any outbound traffic
>
> So, when you refresh with a 20-second period (a good delay) you must 
> consider also this.
>
> Have fun,
> -- Luca
>
>
> ______________________________________________
> Luca Gaballo - France Telecom - R&D Division
> Email: luca.gaballo at rd.francetelecom.com
> Peer networks - Solipsis Project
> http://solipsis.netofpeers.net/ [http://solipsis.netofpeers.net/]
>
> Personal web: http://perso.enst.fr/~gaballo 
> [http://perso.enst.fr/%7Egaballo]
>
>
> 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 
>> [http://list.sipfoundry.org/archive/ietf-behave/msg00441.html]) and 15 
>> minutes (http://list.sipfoundry.org/archive/ietf-behave/msg00127.html 
>> [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 
>> [http://www.frameip.com/nntp/article-comp-protocols-tcp-ip.php?numero=20119]). 
>> Perhaps 20 seconds works (http://www.tisc2001.com/newsletters/322.html 
>> [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 [mailto:p2p-hackers at zgp.org]
>> http://zgp.org/mailman/listinfo/p2p-hackers 
>> [http://zgp.org/mailman/listinfo/p2p-hackers]
>> _______________________________________________
>> Here is a web page listing P2P Conferences:
>> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences 
>> [http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences]
>