Subject: [p2p-sip] Comments on draft-willis-p2psip-concepts-03

From: eric_d_cooper at sympatico.ca (Eric Cooper)
Date: Wed, 1 Nov 2006 15:04:34 -0500

> 
> I actually envision an "outbound peer" that has the same kind of  
> relationship to a client (or to another peer) as an "outbound proxy"  
> does to a UA. It acts as the NAT-traversal anchor for requests from  
> outside the NAT to reach the peer or client behind a NAT.
> 
> Dean
> 

I understand why an 'outbound peer' would be a useful notion for a client, but I  don't understand why a peer would need one.  
I thought that NAT traversal was going to be included as part of the peer protocol.  Is there a special distinction between peers with public IP addresses and peers that are behind NATs?

Eric Cooper.

_______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 1 Nov 2006 21:28:05 -0600

On Nov 1, 2006, at 2:04 PM, Eric Cooper wrote:

> I understand why an 'outbound peer' would be a useful notion for a  
> client, but I  don't understand why a peer would need one.
> I thought that NAT traversal was going to be included as part of  
> the peer protocol.  Is there a special distinction between peers  
> with public IP addresses and peers that are behind NATs?
>

Well, what part of the peer protocol is it that allows peers behind  
NATs to function?

It's not like we can just turn on a magic "NAT Traversal Bit" in the  
protocol.

The only way I know of to reliably talk to anything behind a NAT is  
to enlist the help of somebody that is already talking to the node- 
behind-the-nat via a connection established from behind-the-nat.

So for something "outside" to talk to a peer that is behind a NAT, we  
need to find another peer (or some other helper function) that is  
outside the NAT and already has a connection to the peer-behind the  
NAT. If this helper thing is a peer, then I'd say that there's an  
"outbound peer" relationship between the peer-beind-the-nat and the  
peer-outside-the-nat-that-is-helping.

--
Dean

---

From: eric_d_cooper at sympatico.ca (Eric Cooper)
Date: Thu, 2 Nov 2006 09:32:08 -0500

> Well, what part of the peer protocol is it that allows peers behind  

As an example, there could be some messaging involving a bootstrap server that would request that a bootstrap peer initiate UDP hole punching with a new peer (one that was performing it's insertion into the overlay).

> behind-the-nat via a connection established from behind-the-nat.

In the scenario I'm thinking of, this would be a connection from a (new) peer, talking to a bootstrap server.
Suppose there's also a separate connection between a bootstrap peer that has already joined the overlay and that same bootstrap server.  The existing peer might even be behind a NAT.  The bootstrap server could coordinate UDP hole punching between the existing peer and the new peer.

> peer-outside-the-nat-that-is-helping.

If the UDP hole punching succeeds, then a 'link' between the two peers (both behind NATs) is established.  Would they both be 'outbound peers'?

I was just wondering if you thought the 'outbound peer' behaviour was optional, or just part of the regular responsibilities of a peer, like storage and routing.

Best Regards,

Eric.

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Sun, 5 Nov 2006 10:27:58 -0600

On Nov 2, 2006, at 8:32 AM, Eric Cooper wrote:

> As an example, there could be some messaging involving a bootstrap  
> server that would request that a bootstrap peer initiate UDP hole  
> punching with a new peer (one that was performing it's insertion  
> into the overlay).
>
> In the scenario I'm thinking of, this would be a connection from a  
> (new) peer, talking to a bootstrap server.
> Suppose there's also a separate connection between a bootstrap peer  
> that has already joined the overlay and that same bootstrap  
> server.  The existing peer might even be behind a NAT.  The  
> bootstrap server could coordinate UDP hole punching between the  
> existing peer and the new peer.
>

ok, now you have an "outbound" connection between the peer and the  
"bootstrap server", which I presume is some sort of centralized non- 
peer.  And you might have a new bootstrap protocol. No reason this  
couldn't work, and it's exact analog of the model I was explaining,  
just based on a centralized server doing the heavy lifting instead of  
having a peer do it.

> If the UDP hole punching succeeds, then a 'link' between the two  
> peers (both behind NATs) is established.  Would they both be  
> 'outbound peers'?
>

Possibly.

> I was just wondering if you thought the 'outbound peer' behaviour  
> was optional, or just part of the regular responsibilities of a  
> peer, like storage and routing.

Good question. Possibly something that needs to be tracked as an open  
question for the WG. Personally, I think it is mandatory behavior for  
a "peer" but I suspect some of my co-authors might disagree. If it  
isn't mandatory, we'll need a locator mechanism to help us find a  
peer (or other helper function, like your bootsrap server) that  
provides the needed service.

This gets back to a fundamental "design pattern" question that I  
don't think most people are getting.

Either every peer is "full function" and supports every aspect of  
being a peer, OR we need to define a locator mechanism for finding  
peers that support specific aspects (or features).

--
Dean