Subject: [P2PSIP] Client as relay

From: "Victor Pascual Ávila" <[email-masked]>
Date: Fri, 14 Mar 2008 03:52:37 +0100

Up to now we've considered the client protocol -independently of its
functions- to be the protocol used between a client and its associated
(one, few, many) peers. What I'd like to discuss is: May clients be
able to connect each other using the p2p layer? e.g. if a client is
behind a non-friendly NAT, it could use other clients (providing
STUN/TURN services) to reach its associated peer.

Does it make sense for you?

Cheers,
-- 
Victor Pascual Ávila
Research Engineer
Tel.  +34 93 542 2906
Fax. +34 93 542 2517

Research Group on Network Technologies and Strategies (NeTS)
Universitat Pompeu Fabra (UPF)
Pg. de Circumval·lació, 8
Office 358
08003 Barcelona (Spain)
http://nets.upf.edu/
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 13 Mar 2008 23:26:13 -0400

I think that makes sense.  Thinking about it a bit, if you want to  
try to establish a direct connection using ICE, the only requirement  
for ICE to work is to have a rendezvous node to relay the connection  
request.  So if a client could identify another client (say an  
existing client behind the same bad NAT) with a connection to a peer,  
it could route the ICE request (CONNECT in reload) through that  
client to its associated peer (and around the overlay if the two  
clients don't want to associate with the same peer). If it's only one  
unfriendly NAT (the peer isn't behind one), that should be enough to  
establish a direct connection.

 From reload's perspective, this is a good example of a benefit of  
the via list---it can store the route through a client as well as  
through the peers and the response will then follow the same path  
back.  Even if a direct connection isn't achieved with the associated  
peer, the new client could continue to relay methods indirectly  
through the connected client.  I should mention that supporting this  
type of forwarding is an intended capability of the protocol, but  
actually implementing it does make the client code a bit more  
complicated than it might be otherwise since it needs a complete  
forwarding (but not DHT) layer.  There are also some implications  
that need to be fully thought out (wouldn't really want to do a long  
chain of clients or anything overly complicated).

I don't see a reason why TURN wouldn't work either, but I actually  
prefer using the peer protocol a bit here because I think the routing  
is more natural.

Bruce

---

From: Song Yongchao <[email-masked]>
Date: Fri, 14 Mar 2008 14:13:27 +0800

Yes, there are two methods if a client can't setup direct connection with
its associated peer.

1. Utilize a Turn Relay Server for the communication between the client and
its associated peer.

2. Other clients that connect to the same associated peer may act as the P2P
Relay for the trouble client

Maybe some people think that only eligible peers (e.g. peers with public
address or behind friendly NAT) can act as candidate associated peers for
clients. I think the criterion for which peers will act as associated peers
is left to the specific implementation, but here we need to solve the
problem when a client has trouble with communication with its associated
peer.

I like the idea that clients can communicate each other.

Thanks!

Best Regards,
Song Yongchao
Email: [email-masked]

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Bruce Lowekamp
>Sent: Friday, March 14, 2008 11:26 AM
>To: Victor Pascual ávila
>Cc: P2PSIP Mailing List
>Subject: Re: [P2PSIP] Client as relay
>
>

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 14 Mar 2008 02:45:01 -0700

I don't think it makes sense since one of the main reasons for having the client function is to reduce battery consumption for mobile devices. The last thing a mobile device needs is the message flow to help with NAT traversal of other devices.

Mobile devices must be egoistical beasts that go online only for their own communications IMO.

There are some exceptions such as using P2P in disasters, but I am not sure we ready to define such scenarios at this point in time in the P2PSIP WG.

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Victor Pascual Ávila
Sent: Thursday, March 13, 2008 10:53 PM
To: P2PSIP Mailing List
Subject: [P2PSIP] Client as relay

Cheers,
-- 
Victor Pascual Ávila
Research Engineer
Tel.  +34 93 542 2906
Fax. +34 93 542 2517

---

From: "Dan York" <[email-masked]>
Date: Fri, 14 Mar 2008 10:16:36 +0000

Victor,

Two thoughts:

1. If a node is a "client", why would it be offering STUN/TURN services?

The use case suggested so far for a "client" is primarily an underpowered device such as a mobile device which is not becoming a peer because it does not have the capabilities to do so. It may not have enough processing power, storage capacity or bandwidth. Given that, it is not clear to me how the client would be able to provide STUN or especially TURN services.

I guess the exception could be some overlay configuration where only a certain # of nodes are allowed to be full peers and so some perfectly capable nodes are relegated to client status... But I don't see this as a usual config.

2. If (per #1) client nodes are not running STUN/TURN services, it is not clear to me how another client behind a NAT would *find* another client node to act as a relay - but maybe I need some more caffeine to think that through....

Interesting idea, though,
Dan
-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com

-----Original Message-----
From: "Victor Pascual Ávila" <[email-masked]>

Date: Fri, 14 Mar 2008 03:52:37 
To:"P2PSIP Mailing List" <[email-masked]>
Subject: [P2PSIP] Client as relay

Cheers,
-- 
Victor Pascual Ávila
Research Engineer
Tel.  +34 93 542 2906
Fax. +34 93 542 2517

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 14 Mar 2008 04:02:47 -0700

Victor,

I fully agree with Dan.

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan York
Sent: Friday, March 14, 2008 6:17 AM
To: [email-masked]; P2PSIP Mailing List
Subject: Re: [P2PSIP] Client as relay

Victor,

Two thoughts:

-----Original Message-----

Cheers,
-- 
Victor Pascual Ávila
Research Engineer
Tel.  +34 93 542 2906
Fax. +34 93 542 2517

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 14 Mar 2008 07:45:39 -0400

Victor may answer the question in another way, but ...

we've also had discussions about overlays that support too many nodes to 
realistically include all nodes as peers, so we would provide the services 
that each node needs without having every node join the overlay as a full 
peer.

Peer protocol traffic is likely to be SOME function of the number of nodes 
in the overlay. We can talk about what function that is, but I haven't seen 
anyone arguing that peer protocol traffic was independent of the number of 
peers.

Sadly, we haven't had any discussions in a very long time about use 
cases/application scenarios, so either everything is "in scope" or we all 
just kind of know what the requirements are without discussing them.

Neither extreme excites me. IMO.

Spencer

From: "Dan York" <[email-masked]>

> The use case suggested so far for a "client" is primarily an underpowered 
> device such as a mobile device which is not becoming a peer because it 
> does not have the capabilities to do so. It may not have enough processing 
> power, storage capacity or bandwidth. Given that, it is not clear to me 
> how the client would be able to provide STUN or especially TURN services.
>
> I guess the exception could be some overlay configuration where only a 
> certain # of nodes are allowed to be full peers and so some perfectly 
> capable nodes are relegated to client status... But I don't see this as a 
> usual config.

---

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 14 Mar 2008 07:48:57 -0400

On Mar 14, 2008, at 6:16 AM, Dan York wrote:

> The use case suggested so far for a "client" is primarily an  
> underpowered device such as a mobile device which is not becoming a  
> peer because it does not have the capabilities to do so. It may not  
> have enough processing power, storage capacity or bandwidth. Given  
> that, it is not clear to me how the client would be able to provide  
> STUN or especially TURN services.
>

Obviously in such a situation, you don't want the client to do too  
much work.

> I guess the exception could be some overlay configuration where  
> only a certain # of nodes are allowed to be full peers and so some  
> perfectly capable nodes are relegated to client status... But I  
> don't see this as a usual config.
>

Actually, this is very common. In global-scale p2p overlays (like  
skype), it's typical to have a requirement that only public (at least  
non-filtered) nodes can become peers, and it is also quite common to  
limit the number of peers because if the storage requirements of the  
overlay aren't that great, allowing the number of peers to grow  
unbounded only serves to increase the average path length.

I highly recommend reading draft-pascual-p2psip-clients-01 for its  
very long list of why a node might not be a peer.

> 2. If (per #1) client nodes are not running STUN/TURN services, it  
> is not clear to me how another client behind a NAT would *find*  
> another client node to act as a relay - but maybe I need some more  
> caffeine to think that through....
>

Broadcast/multicast is probably the easiest way to find another device.

Also, STUN and TURN are very different.  Every node has to run STUN  
to support ICE.  TURN is entirely another matter....

Bruce

---

From: songyongchao 64081 <[email-masked]>
Date: Fri, 14 Mar 2008 20:38:23 +0800

----- Original Message -----
From: Bruce Lowekamp <[email-masked]>
Date: Friday, March 14, 2008 7:48 pm
Subject: Re: [P2PSIP] Client as relay

> very long list of why a node might not be a peer.

I fully agree with Bruce.

> Bruce

I think a bootstrap peer can help a client to find another client node to act as a relay when it joins the overlay.                                  

> > functions- to be the protocol used between a client and its 
> associated> (one, few, many) peers. What I'd like to discuss is: 
> May clients be

---

From: Dan York <[email-masked]>
Date: Fri, 14 Mar 2008 08:55:18 -0400

Bruce,

On Mar 14, 2008, at 7:48 AM, Bruce Lowekamp wrote:

> skype), it's typical to have a requirement that only public (at  
> least non-filtered) nodes can become peers, and

Sure. And I completely agree that for large-scale P2PSIP clouds,  
we'll have similar issues.    When I was writing this note I was  
thinking of primarily smaller environments.

> it is also quite common to limit the number of peers because if the  
> storage requirements of the overlay aren't that great, allowing the  
> number of peers to grow unbounded only serves to increase the  
> average path length.

Good point.

> very long list of why a node might not be a peer.

I did before writing this. It's a good document.

> Broadcast/multicast is probably the easiest way to find another  

But how do you broadcast/multicast through a firewall?  i.e. how does  
a node behind a FW or NAT use broadcast/multicast to find other clients?

(As Song suggests, this could be done by the bootstrap server or  
enrollment server.)

> to support ICE.  TURN is entirely another matter....

Agreed.

Regards,
Dan

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free