1. NAT Traversal for P2PSIP Philip Matthews Avaya

2. Peer X Peer Y Peer W 2. P2PSIP Network Establishing new Peer Protocol connection Peer Protocol messages ICE connectivity check messages 3. ICE connectivity checks. The result is a connection between X and Y. 4. Step 2.ICE Offer/Answer exchange via Overlay Routing (or via a Peer Protocol Relay) Step 1. Gather ICE candidates 3.

3. Issue: Finding STUN/TURN servers Naive solution: –Define a “STUN” and a “TURN” service –A peer W that is willing to act as a STUN / TURN server inserts a record into the distributed database under the key “STUN” or “TURN” –Peers looking for such a peer retrieve the list of peers offering the service and select one. Problem: Node W responsible for holding these records will probably melt down under all the Put and Get traffic. This is the “Popular Services Problem”

4. Issue: Finding STUN/TURN servers (2) Two solns proposed so far: Draft-jiang-p2psip-sep –A peer T advertizes its STUN/TURN server through Overlay Maint msgs. Peers receiving this info remember it for later use. Draft-bryan-p2psip-reload –A peer X looking for a STUN/TURN server picks a spot in the hash space at random, and asks the peer nearest to that location if it supports STUN/TURN. If not, peer X picks another spot and tries again. Con: As the number of peers offering the service decreases, the work to find such a peer increases.

5. Issue: Large msgs over UDP How to send large Peer Protocol msgs over UDP? Option 1: Rely on IP fragmentation –Con: Some NATs cannot handle receiving out-of-order fragments How big a problem is this really Option 2: Fragment at Peer Protocol layer –Con: Extra complexity –Con: Must limit to 576 bytes unless we do PMTUD. –Con: Are we just re-inventing IP fragmentation? Option 3: Only run over TCP –Con: Today, success rate of direct connection (without TURN server) slightly lower for TCP than UDP

6. Issue: NAT Traversal for Apps Option 1: Each app implements its own NAT traversal scheme –Con: Lots of per-app work; scheme must take Overlay into account. Option 2: An app explicitly asks Peer Protocol to set up a direct connection for its use. –Con: App must be modified to call Peer Protocol in appropriate spots. Option 3: App uses special IP address to identify remote peer; packet intercepted below transport layer and sent over dynamically established connection to remote peer. –Con: Not transparent for apps that imbed addresses in protocol message.