60 likes | 199 Views
NAT Traversal for P2PSIP. Philip Matthews Avaya. Establishing new Peer Protocol connection. Step 2.ICE Offer/Answer exchange via Overlay Routing (or via a Peer Protocol Relay). 3. ICE connectivity checks. The result is a connection between X and Y. P2PSIP Network. 2. 3. Peer X. Peer Y.
E N D
NAT Traversal for P2PSIP Philip Matthews Avaya
Establishing new Peer Protocol connection Step 2.ICE Offer/Answer exchange via Overlay Routing (or via a Peer Protocol Relay) 3. ICE connectivity checks. The result is a connection between X and Y. P2PSIP Network 2. 3. Peer X Peer Y 4. Step 1. Gather ICE candidates Peer W Peer Protocol messages ICE connectivity check messages
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”
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.
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
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.