Transcript PPT Version
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) P2PSIP Network 3. ICE connectivity checks. The result is a connection between X and Y. 2. 3. Peer X 4. Peer Y 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.