Subject: [P2PSIP] new draft-jiang-p2psip-relay-01

From: "Roni Even" <[email-masked]>
Date: Mon, 12 Jan 2009 09:06:54 +0200

Hi,

In Minneapolis we presented draft-jiang-p2psip-relay-00. There was a hum
that showed consensus to add support for direct route mode. On the issue of
using relay peer and discovering of NAT behavior the decision was to
continue the discussion on the list.

One of the questions in the meeting was about using TURN for getting a relay
peer service. This topic was discussed in a separate thread pointing out
that the sending peer does not know that the address of the target and
cannot tell it to the TURN server, so that TURN server will discard the
message from the target of the message. The other point was that using relay
peer is an optional mode and is not dependent on discovery of NAT behavior,
for example the relay peers can be provisioned by the service provider or be
part of the bootstrap peers.

We updated the draft and submitted draft-jiang-p2psip-relay-01. In the
updated draft we tried to separate the NAT behavior discovery, offering
options to find relay peers from the issue of how to use a relay peer.

The draft explains that the sender of the request decides if to offer direct
response or a relay peer as the recommended response method based on trying
to find if it has a publicly reachable address or looking for relay peer
service. It can have better success based on past experience.  The sender of
the request can try, for example, using a relay peer and if fails to get a
response he can switch to symmetric routing when retrying the request.

We hope that the new draft addresses the questions and people are more
comfortable with these optional modes.

Please review the new draft. You can get the draft by accessing the link
http://tools.ietf.org/id/draft-jiang-p2psip-relay-01.txt 

Thanks

Roni Even

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

---

From: [email-masked]
Date: Thu, 15 Jan 2009 03:50:19 -0500

There are at least two issues to make direct response work in RPR  
which can be more explicitly addressed in the draft:

a) TURN server permissions
b) TURN server transport address

a) TURN server creates a permission on the basis of IP/port tuples.  
When sender requests a direct response for a request sent in a  
recursive manner, the IP/port tuples become irrelevant. Rather, the  
message identifier in the RELOAD message has to be used for matching  
responses to requests. This will need a new TURN profile.

b) The request originator must specify the IP address and port on  
which the response will be received.

For DPR, the draft should clearly state that the response must not be  
encapsulated within a STUN/TURN message.

The draft should also specify that if ROUTE-QUERY is used, there is no  
need for direct or relay response routing.

-salman

---

From: jiangxingfeng <[email-masked]>
Date: Thu, 15 Jan 2009 17:19:28 +0800

Hi, Salman:

Thanks for your comments. Response in line. 

Regards
Jiang XingFeng

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, January 15, 2009 4:50 PM
> To: Roni Even
> Cc: [email-masked]
> Subject: Re: [P2PSIP] new draft-jiang-p2psip-relay-01
> 

RPR does not try to use the TURN server to relay the response. Rather it tries to use a relay peer to forward the response from the destination peer to the source peer. The relay peer should be tested as publicly reachable. 

A typical message flow for a RPR is as follows:
1. Peer A behind NAT finds one or more relay peers who are publicly reachable;
2. Peer A uses Attach methods to create direct connection between Peer A and Relay peer;
3. Peer A sends a request which indicates RPR routing modes and includes relay peer's transport address;
4. When the request reached the destination, the destination peer will try to send response back to the relay peer because of RPR by populating the destination list for entry with relay peer and peer A in sequential order.  
5. Upon receiving the response, what Relay peer does is to check the connection table to see whether it has direct connection with entry in destination list,(currently, it is peer A) A. Then relay peer forward the response as normal response. 

As you said, TURN has some trouble in relaying response because of its address-dependent filtering behavior because peer A does not who will be the target of the message. 

I hope you can understand my explanation. Maybe I should add more text to show the difference between relay peer and TURN server. 
> encapsulated within a STUN/TURN message.

As explained above, RPR will not use TURN, so that the response will not use STUN/TURN to encapsulate. 

> need for direct or relay response routing.

Ok. It is better to forbid using ROUTE-QUERY when RPR or DRR is to be used.