Subject: [P2PSIP] The difference between relay peer and the turn server(peer)

From: jiangxingfeng 36340 <[email-masked]>
Date: Wed, 19 Nov 2008 21:43:14 -0600

Hi:

In today P2PSIP WG meeting, Eric showed his concerns about the difference between relay peer and turn server(peer). Let me give some explanations here. 

As mentioned in the relay draft, the relay peer forwards the response from the destination peer towards the sending peer. Turn server(peer) works in the similar way. 

But the only difference is: if the client A of turn server B wants to accept message from peer C, client A should set permission in turn server B for peer C before the the message is sent by peer C. Otherwise, it would be dropped silently. 

In P2PSIP request/response transaction, before a peer sends a request, it does not know which peer is the destination peer exactly beforehand. It depends on the overlay topology. And the destination peer also changes according to the overlay topology. It is impossible for the sending peer to set the permission for the destination peer in turn server case. So if turn server is used instead of relay peer, the response will be filtered and dis
carded. 

On the other hand, for a peer, there might be several relay peers. The relay peer is on per-transaction basis. That means that the peer can use different relay peer in different transactions. So the peer has no strong reliance on the stablility of the relay peer. If a relay peer failed, it may only influence one. Other relay peer can be used in the next transactions. 

Any comments are appreciated. 

Regards

Jiang XingFeng

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

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 20 Nov 2008 10:42:06 -0600

> In P2PSIP request/response transaction, before a peer sends a request, it does not know which peer is the destination peer exactly beforehand. It depends on the overlay topology. And the destinatio…

exactly.  The underlying problem is that TURN resolved many of its
security issues by essentially acting as an address-restricted filter.
 TURN can be used as the final resolution of an Attach, but it doesn't
provide any facility for an unsolicited message.  And since reload has
a built-in authentication and routing mechanism that helps resolve
some of the concerns that led to the restrictions in TURN, I don't
think it makes any sense to attempt to modify TURN to accomplish this.

The other aspect of this question that I think was unclear during the
session is that the relay peer concept doesn't depend on
nat-behavior-discovery to be useful.  A service provider operating an
overlay could choose to deploy a set of relay peers for use by
customers running behind NATs.

Bruce

---

From: jiangxingfeng <[email-masked]>
Date: Fri, 28 Nov 2008 17:03:32 +0800

> > In today P2PSIP WG meeting, Eric showed his concerns about the difference
> between relay peer and turn server(peer). Let me give some explanations here.
> >
> > As mentioned in the relay draft, the relay peer forwards the response from
> the destination peer towards the sending peer. Turn server(peer) works in the
> similar way.
> >
> > But the only difference is: if the client A of turn server B wants to accept
> message from peer C, client A should set permission in turn server B for peer
> C before the the message is sent by peer C. Otherwise, it would be dropped
> silently.
> >
> > In P2PSIP request/response transaction, before a peer sends a request, it
> does not know which peer is the destination peer exactly beforehand. It depends
> on the overlay topology. And the destination peer also changes according to
> the overlay topology. It is impossible for the sending peer to set the
> permission for the destination peer in turn server case. So if turn server is
> used instead of relay peer, the response will be filtered and dis
> > carded.
> 
> 

> customers running behind NATs.
Good point. The proposed modified NAT behavior discovery mechanism in the draft is used to show that publicly reachable peers can be found if there is any. Maybe the presentation and the description in the draft are not very clear. The only requirement for relay is to find some publicly reachable transport addresses. These addresses can be got through several mechanisms, such as relay peers provided by service providers (as Bruce suggested and service providers choose peers with publicly reachable addresses intentionally), transport addresses got by using NAT-PMP or Upnp-IGD, etc.

With these addresses, the peer can use RM_TEST to check whether it is publicly reachable or not. If the test shows it is publicly reachable, the peer can use direct response later and be a relay for other peers. 

I hope the above text can make communities more clear about the idea. I will revise the draft in these two weeks. 

Regards

Jiang XingFeng