Subject: [P2PSIP] STUN/TURN role in P2PSIP

From: JiangXingFeng <[email-masked]>
Date: Tue, 05 Jun 2007 15:12:20 +0800

Hi, all:

NAT traversal is a big problem for P2PSIP. From the statistics from
http://illuminati.coralcdn.org/stats/, it shows that 73.81% of PCs are
behind NAT. 

These NATed PCs have to find some STUN/TURN servers to help them communicate
with other peers or clients in the overlay. Apparently it violates the
advantages from the P2P technology, if some central STUN/TURN servers are to
be used.

One feasible method is to use peers with public address to play the
STUN/TURN role for NATed peers or clients. But which type of peers or
clients will contribute themselves to be STUN/TURN server?
IMHO, the requirement for a Peer to be the STUN/TURN peers should be as low
as possible because there are huge amounts of NATed PC need to be served.
Maybe public address is enough. Could you please share your views on this
topic? 

Another issue is: must all Peers and clients support STUN/TURN/ICE? 

Comments?

--
Jiang XingFeng

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

---

From: <[email-masked]>
Date: Tue, 5 Jun 2007 15:17:42 +0300

Hi Jiang,

Everything depends on the case scenario and the type of NATs. Case
scenarios:
1. The P2PSIP overlay may be operated by a service provider. In this
case the service provider makes sure that there is enough peers with a
public address and TURN/STUN server functionality in the overlay. Not
all of the peers implement a TURN/STUn server. 
2. In other scenario the service provider may outsource maintenance of
TURN/STUN servers to other entity. In this scenario TURN/STUN servers
are external to P2PSIP overlay. TURN/STUN server's IP/port is registered
in DHT.
3. The last option assumes that P2PSIP software is only run in the end
devices. In this case we may have problems with increased load on some
peers due to media relaying.

Concerning NATs I checked the statistics you sent us very quickly and I
did not notice any information about what types of nats are we speaking
about. We may have a problem if most of connections require media
relaying. Besides, we may have different nats in enterprise and
residential networks. Many residential wifi routers support UPnP IGD.

Marcin

>-----Original Message-----
>From: ext JiangXingFeng [mailto:[email-masked]] 
>Sent: 05 June, 2007 10:12
>To: [email-masked]
>Subject: [P2PSIP] STUN/TURN role in P2PSIP
>
>Hi, all:
>
>NAT traversal is a big problem for P2PSIP. From the statistics 
>from http://illuminati.coralcdn.org/stats/, it shows that 
>73.81% of PCs are behind NAT. 
>
>These NATed PCs have to find some STUN/TURN servers to help 
>them communicate with other peers or clients in the overlay. 
>Apparently it violates the advantages from the P2P technology, 
>if some central STUN/TURN servers are to be used.
>
>One feasible method is to use peers with public address to 
>play the STUN/TURN role for NATed peers or clients. But which 
>type of peers or clients will contribute themselves to be 
>STUN/TURN server?
>IMHO, the requirement for a Peer to be the STUN/TURN peers 
>should be as low as possible because there are huge amounts of 
>NATed PC need to be served.
>Maybe public address is enough. Could you please share your 
>views on this topic? 
>

---

From: "Wei Gengyu" <[email-masked]>
Date: Tue, 5 Jun 2007 23:48:29 +0800

Hi, 

What you said is right,  "Everything depends on the case scenario and the type of NATs. "
To make it concrete, we see the two widely deployed applications, Skype and BT.
Skype is operated by a service provider and needs centralized registation.
BT support any user to deliver torrent file while giving the seed and tracker addresses. 

Currently, you can use these two p2p applicatios by downloading different softwares,
each software would have its own mechanism to process NAT.

Bur , the problems are: 
(1) Is it necessary to make P2PSIP define any mechanisms to facilitate processing NAT?
(2) Shall we rely on application softwares just as now. 

Regards, 

Gengyu

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 05, 2007 8:17 PM
Subject: RE: [P2PSIP] STUN/TURN role in P2PSIP

Hi Jiang,

Marcin

---

From: JiangXingFeng <[email-masked]>
Date: Wed, 06 Jun 2007 17:06:55 +0800

Hi, Gengyu:
> Bur , the problems are:
> (1) Is it necessary to make P2PSIP define any mechanisms to facilitate
processing
> NAT?
It seems that rough consensus has been achieved in P2PSIP community that
some methods defined in STUN/TURN/ICE specifications will be reused to
address NAT traversal issues in P2PSIP. 

But personally I think P2PSIP should solve some issues to facilitate
STUN/TURN/ICE's use. There are some concerns listed as follows:
1) How to discover STUN/TURN server in P2PSIP case
2) How to exchange candidates for ICE process between Peers

Regards

JiangXingfeng

---

From: JiangXingFeng <[email-masked]>
Date: Wed, 06 Jun 2007 17:39:14 +0800

> peers due to media relaying.

I agree that different scenarios will choose how to deploy STUN/TURN server
in their own environment. But equipping a peer or client having a public
address with STUN/TURN functionalities and choosing them to serve for other
peers will make full use of distributed processing power in the overlay. As
for increased load on these peers due to media relaying, I think peers could
accept or reject the service requests from other peers or clients according
to their own processing capability. It will guarantee the communication
quality as much as possible. 

Clients may be more appropriate being a STUN/TURN server than Peers. Peers
should maintain overlay topology and route message what clients would not do
this kind of work. 

> residential networks. Many residential wifi routers support UPnP IGD.
Some peers behind NAT do not need other peer's help, for example in the case
of NATs supporting UPnP IGD. But most of the existing NATs do not support
similar functionality, so I think STUN/TURN/ICE is required when address NAT
traversal issue at present. 

Regards!
JiangXingFeng

---

From: Michael Chen <[email-masked]>
Date: Fri, 08 Jun 2007 07:30:16 -0800

Hi,

I agree that STUN/TURN/ICE should be left to the p2psip application 
instead of the standard for p2psip. What the standard body can do is to 
produce a recommendation for common practices in regarding NAT traversal.

For example, you can recommend using the OpenDHT project to serve as a 
"centralized" location for UAs to communicate resources such as who can 
serve as a STUN server.

--Michael

---

From: "David A. Bryan" <[email-masked]>
Date: Fri, 8 Jun 2007 10:42:48 -0400

The problem with this approach is that it essentially means there is
no way defined that two different implementers can both code to and be
assured their systems would work together. Having a "common practice"
(particularly the one proposed below that relies on a non-standardized
service) isn't something that an implementer can use to guarantee
their software will interoperate with another through NATs.

So in my personal opinion, we should definitely be standardizing the
mechanism for NAT traversal. We want to be able to have a P2PSIP cloud
of devices from vendors X, Y, and Z, all of which together, and I
don't see how we do that without explicitly standardizing the NAT
traversal aspects.

My 2 cents...

David

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 08 Jun 2007 13:26:09 -0500

Just so the chair doesn't have to judge WG consensus based on his own 
postings - I agree with David and was preparing to send almost the same text 
verbatim.

In addition, I would have added a reference to ad hoc P2PSIP DHTs, where 
your client simply joins whatever DHT is available - it's hard to know how 
that would work, if the application had all the NAT traversal intelligence.

Thanks,

Spencer

---

From: "Michael Slavitch" <[email-masked]>
Date: Fri, 8 Jun 2007 14:37:32 -0400

I'm in full agreement with Spencer.

308 Legget Dr. 
Ottawa Ontario 
K2K 1Y6 Canada

Michael Slavitch              
Lead, Technology Initiatives
[email-masked]

PSTN:  
+1.888.398.9698
x225
Fax:
+1.613.599.7457

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Friday, June 08, 2007 2:26 PM
To: David A. Bryan; Michael Chen
Cc: [email-masked]
Subject: Re: [P2PSIP] STUN/TURN role in P2PSIP

Thanks,

Spencer

-- 

-----------------------------------------------

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. 

Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp.

---

From: <[email-masked]>
Date: Sat, 9 Jun 2007 23:42:02 +0300

Jiang,

Comments inline.. 

>Sent: 06 June, 2007 12:39
>To: Matuszewski Marcin (Nokia-NRC/Helsinki); [email-masked]
>> are external to P2PSIP overlay. TURN/STUN server's IP/port is 
>> registered in DHT.
>I agree that different scenarios will choose how to deploy 
>STUN/TURN server in their own environment. But equipping a 
>peer or client having a public address with STUN/TURN 
>functionalities and choosing them to serve for other peers 
>will make full use of distributed processing power in the 
>overlay. As for increased load on these peers due to media 
>relaying, I think peers could accept or reject the service 
>requests from other peers or clients according to their own 
>processing capability. It will guarantee the communication 

Agree, I just want to make sure that we do not require all peers/clients
having a public address to support STUN/TURN server functionality. It is
up to a developer to decide what a particular client/peer supports.

>Clients may be more appropriate being a STUN/TURN server than 
>Peers. Peers should maintain overlay topology and route 
>message what clients would not do this kind of work. 

We may also have dedicated STUN/TURN servers that use the client
protocol to put their contact information to a DHT so other nodes
(peers/clients) can locate them and use their services. This can be
realized using a generic XML over HTTP client protocol that supports
PUT/GET operations or/and we can create a new event package for SIP.  

>
>> Concerning NATs I checked the statistics you sent us very 
>quickly and 
>> I did not notice any information about what types of nats are we 
>> speaking about. We may have a problem if most of connections require 
>> media relaying. Besides, we may have different nats in 
>enterprise and 
>Some peers behind NAT do not need other peer's help, for 
>example in the case of NATs supporting UPnP IGD. But most of 
>the existing NATs do not support similar functionality, so I 
>think STUN/TURN/ICE is required when address NAT traversal 
>issue at present. 

Agree, but we should not forget about UPnP IGD. It is supported by many
wifi routers. 

Marcin

---

From: JiangXingFeng <[email-masked]>
Date: Mon, 11 Jun 2007 09:48:33 +0800

> don't see how we do that without explicitly standardizing the NAT

In this respect, I can't agree with you any more. Because P2P overlay is a
network whose underlying links are TCP/UDP or other connections in the IP
network, NAT problem should be solved in order to make these connections
active. Other than overlay connectivity, media connections should also
address NAT problem in P2PSIP case. 

Regards!
--
Jiang XingFeng

---

From: JiangXingFeng <[email-masked]>
Date: Mon, 11 Jun 2007 10:00:31 +0800

Hi, Marcin:
See inline.
Regards!
--
Jiang XingFeng

> up to a developer to decide what a particular client/peer supports.
Yes, Should we make it an option that Peers/clients having a public address
supports STUN/TURN server in case NATed Peers/Clients really needs their
help? 

> PUT/GET operations or/and we can create a new event package for SIP.
Yes, I like this style. But what key is their contact information under? A
general mechanism is to encode the NAT traversal service and get a key by
applying hash function to the encoded service. The resulting key K is an
associated key with the service. By using this key, NATed Peers/Clients
could get their contact information. But this will make the admitting peer
for K overwhelmed with huge amounts of lookup requests and easily fail.
Could you have any proposal for this issue in minde?
> Agree, but we should not forget about UPnP IGD. It is supported by many

Yes, we should take it into consideration. If there are some others, we
should consider them as well.

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Sun, 10 Jun 2007 22:43:31 -0400

I would agree. The nat traversal mechanism is actually part of the control
protocol which the p2p protocol rides on (or over). It is impossible to
implement an open p2p network w/o having an open standard nat traversal
method.

(BTW, there is a short article of interest (non promotional :) on
http://www.3clogic.com/p2p-deploy.html).

On 6/8/07, David A. Bryan <[email-masked]> wrote:
> processing NAT?

---

From: "Wei Gengyu" <[email-masked]>
Date: Mon, 11 Jun 2007 11:30:21 +0800

Hi, 

P2PSIP should define standard NAT tranversing architecture and mechanism. 

I 'd like to mention "The Effect of NATs on P2P SIP Overlay Architecture -- draft-matthews-p2psip-nats-and-overlays-00"
I think it should be a good start fot P2PSIP to define mechanisms of NAT traversing.

In that draft-rfc, it was recommended that ICE can be used for the exchange of media messages, 
and  the problem needs to solve is to finding a way for peers to exchange signaling messages.

I also would like to know if there is new version of the draft-rfc as it was expired on August 28, 2006.

Regards,

Gengyu

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 11 Jun 2007 00:02:54 -0700

This is an excellent article and should be promoted and also discussed,
for example for these three items of interest for P2P SIP:

-          Is Chord really the preferred solution for the DHT?

-          Why muddle the waters with SBCs? This is a design decision
for CS VoIP networks.

-          CALEA for VoIP has not yet been voted on by Congress or
accepted in the IETF for valid reasons.  Is CALEA for VoIP just another
attempt to create a market for more equipment?

Let the flames come :-)

Thanks, Henry

________________________________

From: Medhavi Bhatia [mailto:[email-masked]] 
Sent: Monday, June 11, 2007 4:44 AM
To: David A. Bryan
Cc: [email-masked]
Subject: Re: [P2PSIP] STUN/TURN role in P2PSIP

I would agree. The nat traversal mechanism is actually part of the
control protocol which the p2p protocol rides on (or over). It is
impossible to implement an open p2p network w/o having an open standard
nat traversal method. 

My 2 cents...

David

--
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: Philip Matthews <[email-masked]>
Date: Mon, 11 Jun 2007 12:08:24 -0400

On 10-Jun-07, at 23:30 , Wei Gengyu wrote:

> I 'd like to mention "The Effect of NATs on P2P SIP Overlay  
> Architecture -- draft-matthews-p2psip-nats-and-overlays-00"

A new version of the document mentioned above was published just  
before the last IETF meeting in March:
	http://tools.ietf.org/html/draft-matthews-p2psip-nats-and-overlays-01

Also, two documents that together provide one way to realize this  
architecture using SIP were published
at the same time:
	http://tools.ietf.org/html/draft-matthews-p2psip-bootstrap- 
mechanisms-00
	http://tools.ietf.org/html/draft-matthews-p2psip-dsip-nat-traversal-00

We are doing some further work in this area which we hope to publish  
soon.

- Philip