Subject: [P2PSIP] question about the Attach request in the Joining Procedure for a peer who is behind symmetric NAT

From: "JeffreyHo" <[email-masked]>
Date: Thu, 4 Feb 2010 13:07:19 +0800

Dear all,

I have a question about the Joining procedure for a peer who is behind
symmetric NAT. 
Per the specification from RELOAD base (step 3 in the sec. 9.4), 
       JP SHOULD send Attach requests to initiate connections to each of the
peers in the neighbor table ...
Before sending an Attach request, it has to prepare all IP candidates via
ICE including the Relay-reflexive candidate obtained from a TURN Server. A
peer can get the TURN Server information on the P2P RELOAD Overlay through
TURN Usage. So I suppose the joining behavior in order below,
Joining Peer -> Connection to Bootstrap Peer -> Ping -> Fetch TURN Usage
(obtain TURN Server) -> ICE -> Attach Request -> ...

The problem is how an un-joining peer fetches the TURN Usage from the
overlay, it is even not part of the RELOAD chord ring. That means it can't
send the Attach request, then it can't join the overlay. It seems deadlock
here? Or I have something wrong on such understanding?

I think this question could be also addressed as "how can an un-joining peer
find the TURN Server over the overlay?"  

Any comment and answer will be appreciated.
Thanks a lot in advance.

BR,
Jeffrey

%;+H%s%i/`%]'t$u,c0|>w1K8j0T!A+D+|)w$'&,%s*L!A=P$E(O%N)N4&ES%;+H%s$:.e!A(C=P>P74&9+H%s!C
This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient.

---

From: JeffreyHo <[email-masked]>
Date: Wed, 10 Feb 2010 11:32:52 +0800

Any comment or response? Or you have solutions?

  _____ 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
JeffreyHo
Sent: Thursday, February 04, 2010 1:07 PM
To: [email-masked]
Subject: [P2PSIP] question about the Attach request in the Joining
Procedurefor a peer who is behind symmetric NAT
Importance: High

Dear all,

Joining Peer -> Connection to Bootstrap Peer -> Ping -> Fetch TURN Usage
(obtain TURN Server) -> ICE -> Attach Request -> ....

BR,
Jeffrey

本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請
銷毀此信件。
This email may contain confidential information. Please do not use or
disclose it in any way and delete it if you are not the intended recipient.

本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。
This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 17 Feb 2010 15:37:08 -0700

Good point - we probably need to clarify this in the draft. I think that implementors do one of two things when joining

1) don't include a TURN candidate in the Attaches used in the Join. This still works fine because the node they are connecting to in the ring will include an TURN server in it list of addresses if one is needed.

You will note in section 5.5.1.5, 2nd para, it tries to make it clear that you only need a host address and not a the address of a TURN server. I'll try to clarify this for the case you raised here. 

and alternative approach is 

2) route the requests to discover a TURN server though the peer being used to join the DHT by adding that peer to the destination list. This allows the TURN discovery to happen before the node joins the ring. 

I agree this looks like a deadlock problem in the current draft. I updated section 5.5.1.5. to try and make this clearer. 

On Feb 3, 2010, at 10:07 PM, JeffreyHo wrote:

> Dear all,
> 
> I have a question about the Joining procedure for a peer who is behind symmetric NAT. 
>        JP SHOULD send Attach requests to initiate connections to each of the peers in the neighbor table ... 
> Before sending an Attach request, it has to prepare all IP candidates via ICE including the Relay-reflexive candidate obtained from a TURN Server. A peer can get the TURN Server information on the P2P RELOAD Overlay through TURN Usage. So I suppose the joining behavior in order below,
> 
> Joining Peer -> Connection to Bootstrap Peer -> Ping -> Fetch TURN Usage (obtain TURN Server) -> ICE -> Attach Request -> ....
> 
> The problem is how an un-joining peer fetches the TURN Usage from the overlay, it is even not part of the RELOAD chord ring. That means it can't send the Attach request, then it can't join the overlay. It seems deadlock here? Or I have something wrong on such understanding?
> 
> I think this question could be also addressed as "how can an un-joining peer find the TURN Server over the overlay?" 
> 
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html