Subject: Re: [P2PSIP] RE: plan B for NAT traversal for P2PSIP

From: Salman Abdul Baset <[email-masked]>
Date: Sat, 1 Dec 2007 19:17:17 -0500 (EST)

> Are you suggesting that plan B is "don't attempt direct connections between
> NAT'd peers" and instead just to relay everything via the DHT?  I think
> that's a good fallback plan if a direct connection can't be established.

This especially makes a lot of sense for iterative routing.

Consider this: A peer gathers its address candidates and advertises them 
to its routing (finger) and neighbor (successor) peers. A node is likely 
to have three types of address candidates, namely, host, server-reflexive, 
and relay. In iterative routing, when a peer receives a request and it is 
not the responsible peer, it replies with the IP address of the next hop. 
It can also reply with all the address candidates of the next hop. The 
node can then try all the address candidates in a sequential or a parallel 
manner.

I have used the parallel approach in my iterative implementation. Clearly, 
it has the overhead of number of parallel messages. However, the number 
of address candidates are typically no more than three. This overhead 
might be an acceptable compromise for successfuly communication.

Note that relay addresses may also be needed in non-NAT scenarios. Think 
of two non-NAT machines which cannot communicate directly due to some 
firewall policy. Skype successfully performs communication between two 
non-NAT machines that cannot communicate directly.

For media Skype allows relay connection (over TCP or UDP) in one 
direction and direct connections in other. Any connectivity scheme must 
address non-transitivity of communication that arises due to NAT or 
firewall policies.

One can say that any NAT traversal scheme should perform as well as 
Skype's NAT traversal scheme. Can we say that ICE NAT traversal mechanism 
is as good as Skype?

> Incidentally, also I'd toss out plan C: create a new NAT penetration
> protocol that is "ICE-lite".
>
>
> Basically, refine the best elements of ICE/STUN/TURN into a new protocol
> that is simpler to implement and iteratively built in conjunction with
> real-world testing (rather than designed first, tested later).

I think ICE is well suited towards establishing long-lived connections 
such as media sessions or connections with routing or neighbor peers. 
However, when a peer needs to communicate only once with a peer behind a 
NAT, and this happens in iterative routing or when there is significant 
churn in the overlay, then we need to evaluate the ICE overhead in terms 
of connection setup delay and number of messages. The ease of 
implementation can also not be ignored.

regards,
Salman

>
>
>
>  _____
>
> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Friday, November 30, 2007 6:43 AM
> To: Greger V. Teigre; David Barrett
> Cc: Philip Matthews; P2PSIP Mailing List; [email-masked]
> Subject: plan B for NAT traversal for P2PSIP
>
>
>
> (I changed the Subject header)
>
>
>
> Greger,
>
>
>
> You have given us a valuable pointer to ICE NAT traversal at
>
> http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source-ice-stun-and
> -turn/ where the implementer says:
>
> So Does It Work?
>
> Yes! (or, erm.. I think so!)
>
> The point is that if ICE does not work satisfactory, there must be a plan B
> for NAT traversal for P2PSIP.
>
> Remember the WG assumption that most endpoints will be behind several levels
> of NAT.
>
> We also want 100% success ratio as well as low call setup delay.
>
>
>
> One plan B is the model to just use an "openDHT-like overlay" as a service.
>
> Endpoints behind NAT may just work using one of several pre-provisioned or
> discovered STUN/TURN servers, after which all the p2p happens as in the
> openDHT. I believe ICE has a much better chance as well when two endpoints
> have to just connect to the DHT.
>
> http://www.sigcomm.org/sigcomm2005/paper-RheGod.pdf
>
>
>
> Incidentally, the paper also shows the excellent security properties of this
> approach when using the overlay in data mode. Look at Table1.
>
>
>
> I understand there are P2P SIP demos working exactly this way.
>
>
>
> There is no time to discuss plan B next week in the WG meeting, but don't
> exclude the possibility it may happen sometimes later.
>
>
>
> Henry
>
>
>
>  _____
>
> From: Greger V. Teigre [mailto:[email-masked]]
> Sent: Friday, November 30, 2007 2:46 AM
> To: David Barrett
> Cc: 'Philip Matthews'; 'P2PSIP Mailing List'
> Subject: Re: [P2PSIP] NAT Traversal Discussion in Vancouver
>
>
>
> To ICE testing, the only data I have seen are from pjsip and only anecdotal.
>
> Cut from blog entry:
> http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source-ice-stun-and
> -turn/
>
> "I've tried with running two pjsua's behind the same NAT that doesn't do
> hairpin, and the local address pair is used. And trying two pjsua's behind
> different NATs, the public address pair is used. So it looks like it's
> working!
> More over, I've been testing it since last week, and quite few bugs have
> been found and fixed. And negotiation is pretty quick, around 100 ms with
> two endpoints on different ADSL line, even though the SDP answer was delayed
> in the proxy (ICE is able to start the checks early even when SDP answer
> hasn't been received by caller).
> But one of the major difficulties with testing ICE these days is practically
> there is no other freely available ICE implementation out there (I mean,
> ICE-14/15 compliant ones), so although ICE implementation in PJNATH does
> seem to work, and it follows ICE-15 closely, we couldn't be sure that it is
> compliant until it talks with other implementation. So if any of you know
> one, please do let me know!"
>
> The implementation is documented here:
> http://www.pjsip.org/pjnath/docs/html/index.htm
>
> The library was recently updated to the latest updates. I haven't seen any
> larger scale testing yet.
> g-)
>
> David Barrett wrote:
>
> -----Original Message-----
> From: Philip Matthews [mailto:[email-masked]]
> Subject: [P2PSIP] NAT Traversal Discussion in Vancouver
>
> 2) The very-low-level NAT Traversal approach is ICE, and I don't see
> anyone questioning that. I don't think a discussion of this is worth
> precious meeting time.
>
>
>
> Though it needn't be a topic of discussion, can you ask the attendees if
> anybody has some real-world performance and reliability data on ICE that
> they can share?  I don't think any has been published to date, but perhaps
> new data has come out since our last requests.
>
> Indeed, if anybody has this data (or can get it), this would be an excellent
> time to share it.  Specifically, I'm curious to know how long it typically
> takes to set up a particular connection, and with what probability it can
> establish a direct connection between two arbitrary peers on the internet.
> ("Connection setup" and "peer connectivity")
>
> Thanks!
>
> -david
>
>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/p2psip
>
>
>
>

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Sun, 02 Dec 2007 12:03:00 +0800

> might be an acceptable compromise for successfuly communication.

I have a question here: if my understanding is right, most of the NATs have a property of address dependent filtering.
How could you contact with the peer by using its candidate without using any hole-punching technique first?

> implementation can also not be ignored.

yes, i agree. In SEP, we also use relaying peer to get the response directly back to the source peer without ICE negotiation. 

> > openDHT. I believe ICE has a much better chance as well when two 
> endpoints> have to just connect to the DHT.
> >
> > But one of the major difficulties with testing ICE these days is 
> practically> there is no other freely available ICE implementation 
> out there (I mean,
> > time to share it.  Specifically, I'm curious to know how long it 
> typically> takes to set up a particular connection, and with what 
> probability it can
> > establish a direct connection between two arbitrary peers on the 
> internet.> ("Connection setup" and "peer connectivity")
> >
> > Thanks!
> >
> > -david
> >
> >

---

From: Song Yongchao <[email-masked]>
Date: Mon, 03 Dec 2007 12:20:32 +0800

Hi, Philip!

I think there is another question to be discussed.

If a joining peer can't setup a direct connection with its neighbor, it can
use a relay to relay messages to its neighbor, but at the same time, this
adds another "hop" in the overlay routing. If a lot of peers communicate
with those peers in their neighbor table through relays, the overlay routing
may be very low efficient because the requests must route through some
additional relays in the routing path.

Then, a joining peer that can't setup enough direct connections to its
neighbors should not be admitted as a Peer?

Best Regards!
Song Yongchao

> From: jiangxingfeng 36340 [mailto:[email-masked]]
> Sent: Sunday, December 02, 2007 12:03 PM
> To: Salman Abdul Baset
> Cc: 'Henry Sinnreich'; 'Philip Matthews'; 'P2PSIP Mailing List'
> Subject: »Ø¸´:Re: [P2PSIP] RE: plan B for NAT traversal forP2PSIP
> 
> I have a question here: if my understanding is right, most of the NATs
have
> a property of address dependent filtering.
> How could you contact with the peer by using its candidate without using
any
> hole-punching technique first?
> 
> 
> 
> yes, i agree. In SEP, we also use relaying peer to get the response
directly
> back to the source peer without ICE negotiation.
> 
> 
> > >  _____
> > >