Subject: [ppsp] Choices of NAT traversal solutions

From: [email-masked]
Date: Wed, 27 Oct 2010 15:52:37 +0800

Dear all,
Below are my thoughts on the choices of NAT traversal solutions. Comments 
are welcome.

[I-D.gu-ppsp-peer-protocol] uses RELOAD for NAT traversal. However, there 
are some shortcomings of using RELOAD for PPSP NAT traversal. First, 
RELOAD is a heavy protocol. Introducing RELOAD complicates the 
implementation of PPSP peer, and requires deploying RELOAD's 
configuration/enrollment server. Second, exchanging ICE parameters with 
RELOAD APPATTACH requires O(log N) overlay hops, which causes high 
latency. Third, using RELOAD to discover TURN service node also requires 
O(log N) overlay hops.

I proposed another NAT traversal solution, which can overcome above 
shortcomings. This solution doesn't complicate the implementation of PPSP 
peer or tracker. The latencies of NAT traversal and TURN service discovery 
are also low. This draft can be accessed at 
https://www3.tools.ietf.org/id/draft-li-ppsp-nat-traversal-00.txt

I summarize my NAT traversal solution as below.
        Capable PPSP peers function as STUN or relay servers, and PPSP 
protocol is used to discover them. Tracker is used to maintain and 
discover STUN/relay peer list.
        Every peer gathers its candidate addresses and reports them to 
tracker, and candidate addresses are contained in peer list. So peer can 
obtain remote peer's candidate addresses and do PPSP layer connectivity 
checks or modified ICE connectivity checks. The modified ICE connectivity 
checks don't require exchanging ICE parameters.
        Standard ICE connectivity checks are still required for media 
traversal, and may be used to find a better communication path for PPSP 
signal. So this solution defines new PPSP messages for exchanging ICE 
parameters.
 +------------+
 |relay peer E| report TURN ability
 |(TURN peer) |-------------------+                   +------+
 +------------+                    \                  |peer C|
                                    \                 +------+
                                     \                get |
                                      \              peer |
         +------+report candidates     \             list |
         |peer A|---------------->+-----+--------+<-------+
         +------+                 |              |  report STUN 
ability+-----------+
                                  |   tracker |<--------------------|STUN 
peer D|
                                  |              | ` +-----------+
 +------+get STUN/relay peer list |              |
 |peer B|------------------------>+-----+--------+
 +---+--+                               |
      \establish                        |
       \asociation                      |
        \                               |
     +---+--------+                     |
     |relay peer F| report proxy ability|
     |(proxy peer)|---------------------+
     +------------+

BR
Lichun
--=_alterna

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.