Subject: [P2PSIP] mobile p2p in p2psip

From: longbwe longbwe <[email-masked]>
Date: Fri, 6 Feb 2009 14:38:54 +0800

Hi all,
We want to know if mobile p2p can be discussed in this WG, or the p2psip is
also appropriate for the wireless scenarios, because we are intrested in
mobile p2p now and wish to do some communication with the ones who also
research on it.
Any feedback is appreciated!
Best Regards,
     Bin Long

---

From: "Wang, Sherry" <[email-masked]>
Date: Fri, 6 Feb 2009 11:40:53 -0500

Bin,

It's out of question that we should do it. I have seen mobile P2P researches and discussions existing for a while. Should we have a separate WG because of its technical significance and complexity, I am not sure. Important is that we need to work on it. Are you interested in mobility management only, e.g. handover, or more?

Thanks,
Sherry Wang

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of longbwe longbwe
Sent: Friday, February 06, 2009 1:39 AM
To: [email-masked]
Subject: [P2PSIP] mobile p2p in p2psip

Hi all,
We want to know if mobile p2p can be discussed in this WG, or the p2psip is also appropriate for the wireless scenarios, because we are intrested in mobile p2p now and wish to do some communication with the ones who also research on it.
Any feedback is appreciated!
Best Regards,
     Bin Long

---

From: longbwe longbwe <[email-masked]>
Date: Sat, 7 Feb 2009 16:57:07 +0800

Sheery,

Thanks very much for your reply.Maybe it is a little early to set a seperate
WG for Mobile P2P, I am  wondering whether the work of P2PSip can be
extensible to wireless scenarios, e.g. its architecture.Mobility management
is certainly one of our interested fields, which also include the network
topology, architecture, peer protocol, private issue, security and so on.We
would like to discuss one or more such related topics with you and any one
else.  The underlying fact is that with the issue of  3G lisences in China
and emergence of more and more cell phone applications, our team think we
should do some work to extend the P2P technic from PC to mobile devices.

Best wishes,
Bin Long

On Sat, Feb 7, 2009 at 12:40 AM, Wang, Sherry <[email-masked]>wrote:

>  Bin,
>
> It's out of question that we should do it. I have seen mobile P2P
> researches and discussions existing for a while. Should we have a separate
> WG because of its technical significance and complexity, I am not sure.
> Important is that we need to work on it. Are you interested in mobility
> management only, e.g. handover, or more?
>
> Thanks,
> Sherry Wang
>
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *longbwe longbwe
> *Sent:* Friday, February 06, 2009 1:39 AM
> *To:* [email-masked]
> *Subject:* [P2PSIP] mobile p2p in p2psip
>
> Hi all,

---

From: Henry Sinnreich <[email-masked]>
Date: Sun, 8 Feb 2009 12:21:03 -0800

Please help me understand the technical (not marketing) meaning of mobile p2p.
Mobility is inherent on the Internet and can be implemented in several ways.

Or are you referring to to mobile phones not connected to the Internet?
Where is the protocol capability difference between a laptop, a netbook and a smart phone?

This sounds simplistic, but wireless to me is a wire into the Internet, unless we talk about some closed network, and please tell me why would I buy it?

Henry

On 2/7/09 2:57 AM, "longbwe longbwe" <[email-masked]> wrote:

Sheery,

Thanks very much for your reply.Maybe it is a little early to set a seperate WG for Mobile P2P, I am  wondering whether the work of P2PSip can be extensible to wireless scenarios, e.g. its architecture.Mobility management is certainly one of our interested fields, which also include the network topology, architecture, peer protocol, private issue, security and so on.We would like to discuss one or more such related topics with you and any one else.  The underlying fact is that with the issue of  3G lisences in China and emergence of more and more cell phone applications, our team think we should do some work to extend the P2P technic from PC to mobile devices.

Best wishes,
Bin Long

On Sat, Feb 7, 2009 at 12:40 AM, Wang, Sherry <[email-masked]> wrote:
Bin,

Thanks,
Sherry Wang

Hi all,

---

From: Henry Sinnreich <[email-masked]>
Date: Sun, 8 Feb 2009 13:47:07 -0800

Sorry, I meant to say mobility is inherent on the Internet and in private IP networks and can be implemented in several ways over IP.

P2P can indeed be implemented on various L2 networks as well, such as the IEEE Wi-Fi or WiMAX but the mobility range without an  IP 'internetwork' layer is limited. Also, the use of SIP, as in this working group implies Internet or private IP networks.
=========================================

Henry

Sheery,

Best wishes,
Bin Long

Thanks,
Sherry Wang

Hi all,

---

From: David Artuñedo Guillén <[email-masked]>
Date: Mon, 09 Feb 2009 08:40:27 +0100

Henry,

I guess it is related to the fact that in mobility your device gets different IPs in short periods of time. Frecuent changes has to be managed in order to route messages efficiently. It is not the same as churn, but it introduces similar challenges, IMHO.

BR

Enviado desde mi iPhone

El 08/02/2009, a las 21:22, "Henry Sinnreich" <[email-masked]<mailto:[email-masked]>> escribió:

Henry

On 2/7/09 2:57 AM, "longbwe longbwe" <<[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

Sheery,

Best wishes,
Bin Long

On Sat, Feb 7, 2009 at 12:40 AM, Wang, Sherry <<[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
Bin,

Thanks,
Sherry Wang

________________________________
From: <[email-masked]> [email-masked]<mailto:[email-masked]> [<mailto:[email-masked]>mailto:[email-masked]] On Behalf Of longbwe longbwe
Sent: Friday, February 06, 2009 1:39 AM
To: <[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: [P2PSIP] mobile p2p in p2psip

Hi all,

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

---

From: Song Haibin <[email-masked]>
Date: Mon, 09 Feb 2009 16:12:29 +0800

Hi David,

I think you get to the point. The p2p layer connection continuity is
important for the mobile overlay network. I want to know if some generic
mobility techniques which are independent of the applications could be used
to solve this problem?

Best Regards,
Haibin
Email: [email-masked]
Skype: alexsonghw

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David Artu?edo Guillén
Sent: Monday, February 09, 2009 3:40 PM
To: Henry Sinnreich
Cc: longbwe longbwe; Wang, Sherry; [email-masked]
Subject: Re: [P2PSIP] mobile p2p in p2psip

Henry,

I guess it is related to the fact that in mobility your device gets
different IPs in short periods of time. Frecuent changes has to be managed
in order to route messages efficiently. It is not the same as churn, but it
introduces similar challenges, IMHO. 

BR

Enviado desde mi iPhone

El 08/02/2009, a las 21:22, "Henry Sinnreich" <[email-masked]> escribió:
Please help me understand the technical (not marketing) meaning of mobile
p2p.
Mobility is inherent on the Internet and can be implemented in several ways.

Or are you referring to to mobile phones not connected to the Internet?
Where is the protocol capability difference between a laptop, a netbook and
a smart phone?

This sounds simplistic, but wireless to me is a wire into the Internet,
unless we talk about some closed network, and please tell me why would I buy
it? 

Henry 

Best wishes,
Bin Long

On Sat, Feb 7, 2009 at 12:40 AM, Wang, Sherry <[email-masked]>
wrote:
Bin,

It's out of question that we should do it. I have seen mobile P2P researches
and discussions existing for a while. Should we have a separate WG because
of its technical significance and complexity, I am not sure. Important is
that we need to work on it. Are you interested in mobility management only,
e.g. handover, or more?

Thanks,
Sherry Wang
________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of
longbwe longbwe
Sent: Friday, February 06, 2009 1:39 AM
To: [email-masked]
Subject: [P2PSIP] mobile p2p in p2psip

Hi all,

[email-masked]

---

From: longbwe longbwe <[email-masked]>
Date: Mon, 9 Feb 2009 16:56:44 +0800

Thank all of you!
In mobile environments,peer connections become location-dependent and may be
vulnerable, disconnetions and reconnections can ouccur more frequently, you
should address these issues when a peer is registering or searching the
overlay.Also, there is mobility issue in federated overlay architectures.
As for the technical meaning of mobile p2p, we think it could include the
p2p overlay for mobile ad hoc networks(MANET) and  sensor networks, p2p
architectures for integrated MANETs and wide-area networks,Mobile P2P on
different bearer serveces: 2.5/3G(GPRS/UTMS), 802.11(WLAN), mobile P2P SIP,
and so on.
Looking for your responses.

Best regards,
Bin Long

On Mon, Feb 9, 2009 at 4:12 PM, Song Haibin <[email-masked]> wrote:

> researches

---

From: Kurt Tutschku <[email-masked]>
Date: Mon, 9 Feb 2009 17:55:40 +0100

Dear all,

as Bin explained, disconnections and reconnections will occur in  
wireless systems more frequently as in wireline system. The effect of  
"churn" is not negligible. An comprehensive analysis of the impact of  
churn is available in:

A. Binzenhoefer and K. Leibnitz: "Estimating Churn in Structured P2P  
Networks.",  20th International Teletraffic Congress (ITC20), Ottawa,  
Canada, June 2007. available at http://www3.informatik.uni-wuerzburg.de/papers/conf_261.pdf

There is already a lot of research going. Much of this will available  
soon in a special book on Mobile P2P systems:

Boon-Chong Seet (Edt.): "Mobile Peer-to-Peer Computing for Next  
Generation Distributed Environments: Advancing Conceptual and  
Algorithmic Applications", IGI Global, Hershey (USA), April 2009.

Best Regards
Kurt

Am 09.02.2009 um 09:56 schrieb longbwe longbwe:

> Thank all of you!
> In mobile environments,peer connections become location-dependent  
> and may be vulnerable, disconnetions and reconnections can ouccur  
> more frequently, you should address these issues when a peer is  
> registering or searching the overlay.Also, there is mobility issue  
> in federated overlay architectures.
> As for the technical meaning of mobile p2p, we think it could  
> include the p2p overlay for mobile ad hoc networks(MANET) and   
> sensor networks, p2p architectures for integrated MANETs and wide- 
> area networks,Mobile P2P on different bearer serveces: 2.5/3G(GPRS/ 
> UTMS), 802.11(WLAN), mobile P2P SIP, and so on.

---
Prof. Dr. Kurt Tutschku
Chair of Future Communication (Endowed by Telekom Austria)
Institute of Distributed and Multimedia Systems, Faculty of Computer  
Science
University of Vienna, Universitaetsstrasse 10/T11, 1090 Wien, Austria.

Tel: +43/1/4277-39611 Mobile: +43/664/60277-39611

http://www.cs.univie.ac.at/fc

mailto:[email-masked] or mailto:[email-masked]

---

From: Victor Pascual Ávila <[email-masked]>
Date: Mon, 9 Feb 2009 18:41:38 +0100

Hi Henry,

On Mon, Feb 9, 2009 at 5:16 PM, Henry Sinnreich <[email-masked]> wrote:
> There was an I-D (now expired) on this:
> Pascual, V., Matuszewski, M., Shim, E., Zhang, H., and S. Yongchao, "P2PSIP
> Clients",
> <draft-pascual-p2psip-clients>
>
> It was preceded and followed by many discussions on this topic, such as that
> frequent p2p protocol messages for peer nodes will quickly exhaust the
> battery.
>
> Victor: What has happened to the I-D on p2p clients?

The major motivation behind draft-pascual-p2psip-clients was to
convince the WG that the client role was desirable in some scenarios.
The client role is now discussed and included in a WG document, i.e.
draft-ietf-p2psip-base, Appendix C.

If folks consider it makes sense to continue the client's work as an
standalone document, we are very open for suggestions.

Cheers,
-- 
Victor Pascual Ávila

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 9 Feb 2009 12:46:39 -0500

Just to be clear, clients are a fully integrated component of the base
reload protocol.  Motivation for them and some discussion of related
issues is in the p2psip-base appendix (and a much more extensive
discussion in pascual-clients and others), but the actual mechanisms
to support them should already be in the base draft.

Discussion of further work identifying when a node should be a peer
and when it should be a client, or overlay algorithms optimized for
specific types of deployments, including "mobile", might be good
topics for further work in new drafts, of course.

Bruce

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 9 Feb 2009 09:47:01 -0800

Kurt,

The link that you have provided requires name and password.
http://www3.informatik.uni-wuerzburg.de/papers/conf_261.pdf

Or maybe I made a mistake?

Henry

On 2/9/09 10:55 AM, "Kurt Tutschku" <[email-masked]> wrote:

Dear all,

as Bin explained, disconnections and reconnections will occur in wireless systems more frequently as in wireline system. The effect of "churn" is not negligible. An comprehensive analysis of the impact of churn is available in:

A. Binzenhoefer and K. Leibnitz: "Estimating Churn in Structured P2P Networks.",  20th International Teletraffic Congress (ITC20), Ottawa, Canada, June 2007. available at http://www3.informatik.uni-wuerzburg.de/papers/conf_261.pdf

There is already a lot of research going. Much of this will available soon in a special book on Mobile P2P systems:

Boon-Chong Seet (Edt.): "Mobile Peer-to-Peer Computing for Next Generation Distributed Environments: Advancing Conceptual and Algorithmic Applications", IGI Global, Hershey (USA), April 2009.

Best Regards
Kurt

Thank all of you!
In mobile environments,peer connections become location-dependent and may be vulnerable, disconnetions and reconnections can ouccur more frequently, you should address these issues when a peer is registering or searching the overlay.Also, there is mobility issue in federated overlay architectures.
 As for the technical meaning of mobile p2p, we think it could include the p2p overlay for mobile ad hoc networks(MANET) and  sensor networks, p2p architectures for integrated MANETs and wide-area networks,Mobile P2P on different bearer serveces: 2.5/3G(GPRS/UTMS), 802.11(WLAN), mobile P2P SIP, and so on.
 Looking for your responses.

Best regards,
Bin Long

Hi David,

 Best Regards,
 Haibin

David Artu?edo Guillén

 Henry,

 BR

 Enviado desde mi iPhone

 Henry

 Best wishes,
 Bin Long

 Thanks,
 Sherry Wang

 Hi all,

---
Prof. Dr. Kurt Tutschku
Chair of Future Communication (Endowed by Telekom Austria)
Institute of Distributed and Multimedia Systems, Faculty of Computer Science
University of Vienna, Universitaetsstrasse 10/T11, 1090 Wien, Austria.

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 9 Feb 2009 08:16:48 -0800

>Frequent changes has to be managed in order to route messages efficiently.
>It is not the same as churn, but it introduces similar challenges, IMHO.

This makes sense and is the reason the present work in the P2P SIP WG we have peer nodes and client nodes.

There was an I-D (now expired) on this:
Pascual, V., Matuszewski, M., Shim, E., Zhang, H., and S. Yongchao, "P2PSIP Clients",
<draft-pascual-p2psip-clients>

It was preceded and followed by many discussions on this topic, such as that frequent p2p protocol messages for peer nodes will quickly exhaust the battery.

Reload Base also specifies:

   Peer:  A host that is participating in the overlay.  Peers are
      responsible for holding some portion of the data that has been
      stored in the overlay and also route messages on behalf of other
      hosts as required by the Overlay Algorithm.

   Client:  A host that is able to store data in and retrieve data from
      the overlay but which is not participating in routing or data
      storage for the overlay.

Given this protocol work to make P2P SIP work for mobile devices, I may be excused for not liking the marketing term "mobile p2p". As for other, non-SIP applications, the above protocol work also applies quite well, as the the Reload authors have said.

Please let us know if the above definitions meet your requirements or not.

Henry

On 2/9/09 1:40 AM, "David Artuñedo Guillén" <[email-masked]> wrote:

Henry,

BR

Enviado desde mi iPhone

Henry

On 2/7/09 2:57 AM, "longbwe longbwe" <[email-masked] <mailto:[email-masked]> > wrote:

Sheery,

Best wishes,
Bin Long

On Sat, Feb 7, 2009 at 12:40 AM, Wang, Sherry <[email-masked] <mailto:[email-masked]> > wrote:
Bin,

Thanks,
Sherry Wang

________________________________
From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of longbwe longbwe
Sent: Friday, February 06, 2009 1:39 AM
To: [email-masked] <mailto:[email-masked]>
Subject: [P2PSIP] mobile p2p in p2psip

Hi all,

---

From: Song Haibin <[email-masked]>
Date: Tue, 10 Feb 2009 09:53:44 +0800

Hi Henry and Bin,

>It was preceded and followed by many discussions on this topic, such as
>that frequent p2p protocol messages for peer nodes will quickly exhaust the
>battery. 

As the co-author of this I-D (use my previous name Song Yongchao), I support
that the mobile devices should be better to act as clients rather than peers
whenever possible. But I guess there are scenarios where only mobile devices
are available. In this case, more considerations need to be given to the
mobility of a "peer".

Bin, I don't know if this is what you concern about.

BR
Song Haibin

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 9 Feb 2009 20:17:23 -0800

Song,

>there are scenarios where only mobile devices are available.
>In this case, more considerations need to be given to the
>mobility of a "peer".

This is a valid scenario, for example in disasters or emergencies when access to the SIP network is not possible, but the mobile devices could still communicate on the same L2 radio network, say on the same WiFi network.
One approach is described here and it does not require p2p:

http://tools.ietf.org/html/draft-lee-sip-dns-sd-uri-00

Henry

On 2/9/09 7:53 PM, "Song Haibin" <[email-masked]> wrote:

Hi Henry and Bin,

BR
Song Haibin

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Tue, 10 Feb 2009 13:40:50 +0800

Hi Bruce and Haibin:

I totally agree with you to further consider the mobility behavior together with the status of the node (peer or client) in the overlay. 

Mobility could bring disconnection and reconnection which changes the topology structure of a P2P overlay. Different influences are given to peers and clients. Clients only need to reconnect with overlay simply, while peers need do data migration and even more before changing connection. There is no point to ask client to install a same complex protocol with peer, especially in mobility scenario. Moreover, the frequent moving of peers could be a disaster for structured overlay. Therefore, it is necessary to tell which kind of devices could perform as peer and which should work as clients. 

Besides the peer/client definition mentioned in Reload base, the mobility character should also be considered to separate them. In my opinion, there could be three kinds of node in the overlay: fixed (e.g. desktop), mobile (e.g. handset) and mixed (e.g. laptop). Fixed nodes are obviously good candidates for peers of overlay, while mobile handsets should be limited in client status considering not only their limited capability and resources but also the highly mobile characteristic. Some devices like laptop could perform either as peers or as clients depending on requirement. The peer mobility issues are mainly brought by this kind of nodes.

So, the overlay could be constructed by some relative static nodes as peers for data storage and message routing. The highly mobility nodes, which work only as clients, can not cause churn of the overlay topology structure. It seems that we'd better consider the client mobility and peer mobility separately to describe their behavior and to develop their protocols more clearly. 

Xiao Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Song Haibin
Sent: Tuesday, February 10, 2009 9:54 AM
To: 'Henry Sinnreich'; 'David Artu?edo Guillén'; 'Victor Pascual ávila'
Cc: 'longbwe longbwe'; 'Wang,Sherry'; [email-masked]
Subject: Re: [P2PSIP] mobile p2p in p2psip

Hi Henry and Bin,

>Pascual, V., Matuszewski, M., Shim, E., Zhang, H., and S. Yongchao, 
>"P2PSIP Clients", <draft-pascual-p2psip-clients>

>that frequent p2p protocol messages for peer nodes will quickly exhaust 
>the battery.

As the co-author of this I-D (use my previous name Song Yongchao), I support that the mobile devices should be better to act as clients rather than peers whenever possible. But I guess there are scenarios where only mobile devices are available. In this case, more considerations need to be given to the mobility of a "peer".

BR
Song Haibin

Just to be clear, clients are a fully integrated component of the base reload protocol.  Motivation for them and some discussion of related issues is in the p2psip-base appendix (and a much more extensive discussion in pascual-clients and others), but the actual mechanisms to support them should already be in the base draft.

Discussion of further work identifying when a node should be a peer and when it should be a client, or overlay algorithms optimized for specific types of deployments, including "mobile", might be good topics for further work in new drafts, of course.

Bruce

---

From: "Das, Saumitra" <[email-masked]>
Date: Mon, 9 Feb 2009 22:55:06 -0800

Handling mobile nodes can be done in the framework of the base draft. For example, the DHT protocol itself can be different if 
the operating conditions are such that there is a lot of moiblity. There are several proposals for DHTs to operate efficiently on highly
mobile networks such as MANETs. These should be doable under the pluggability principle of RELOAD.

The fact about who should be peer, client can be based on decisions of the overlay deployer. Some overlays make not have such choices being
made up only of mobile nodes. There are various techniques to deal with excessive churn due to mobility and the consequent need to replicate
data which can work under the framework of the base draft.

New draft could focus on best practices or results on such choices.

Best
Saumitra

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiao, Lin (NSN - CN/Beijing)
Sent: Monday, February 09, 2009 9:41 PM
To: ext Song Haibin; Henry Sinnreich; David Artu?edo Guillén; Victor Pascual ávila
Cc: longbwe longbwe; Wang, Sherry; [email-masked]
Subject: Re: [P2PSIP] mobile p2p in p2psip

Hi Bruce and Haibin:

Xiao Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Song Haibin
Sent: Tuesday, February 10, 2009 9:54 AM
To: 'Henry Sinnreich'; 'David Artu?edo Guillén'; 'Victor Pascual ávila'
Cc: 'longbwe longbwe'; 'Wang,Sherry'; [email-masked]
Subject: Re: [P2PSIP] mobile p2p in p2psip

Hi Henry and Bin,

BR
Song Haibin

Bruce

---

From: longbwe longbwe <[email-masked]>
Date: Tue, 10 Feb 2009 16:41:14 +0800

Hi Xiao,
Thanks for your thoughts! I also agree the distinctions between peer and
client, for there could be heterogeneous devices in the overlay, we cannot
assume only one role for all of them.You note that nodes may be devided into
three categories:fixed,mobile and mixed, with the preferences that fixed
nodes act peers and mobile nodes act clients.What if most nodes of the
overlay are mobile and there are not enough fixed nodes running as
peers?This is certainly becoming the case,with the emergences of more
powerful and smarter mobile devices such as iPhone and GPhone, cell phones
are functioning more like a small PC and young people will prefer their
mobile phones to laptops.
I also appreciate there could be a dynamic role transferring mechanism
between peer and client for one singal node regarding the changing
environments.

On Tue, Feb 10, 2009 at 1:40 PM, Xiao, Lin (NSN - CN/Beijing) <
[email-masked]> wrote:

>
> Hi Bruce and Haibin:
>
> I totally agree with you to further consider the mobility behavior together
> with the status of the node (peer or client) in the overlay.
>
> Mobility could bring disconnection and reconnection which changes the
> topology structure of a P2P overlay. Different influences are given to peers
> and clients. Clients only need to reconnect with overlay simply, while peers
> need do data migration and even more before changing connection. There is no
> point to ask client to install a same complex protocol with peer, especially
> in mobility scenario. Moreover, the frequent moving of peers could be a
> disaster for structured overlay. Therefore, it is necessary to tell which
> kind of devices could perform as peer and which should work as clients.
>
> Besides the peer/client definition mentioned in Reload base, the mobility
> character should also be considered to separate them. In my opinion, there
> could be three kinds of node in the overlay: fixed (e.g. desktop), mobile
> (e.g. handset) and mixed (e.g. laptop). Fixed nodes are obviously good
> candidates for peers of overlay, while mobile handsets should be limited in
> client status considering not only their limited capability and resources
> but also the highly mobile characteristic. Some devices like laptop could
> perform either as peers or as clients depending on requirement. The peer
> mobility issues are mainly brought by this kind of nodes.
>
> So, the overlay could be constructed by some relative static nodes as peers
> for data storage and message routing. The highly mobility nodes, which work
> only as clients, can not cause churn of the overlay topology structure. It
> seems that we'd better consider the client mobility and peer mobility
> separately to describe their behavior and to develop their protocols more
> clearly.
>
>
> Xiao Lin
>
>
>
> As the co-author of this I-D (use my previous name Song Yongchao), I
> support that the mobile devices should be better to act as clients rather
> than peers whenever possible. But I guess there are scenarios where only
> mobile devices are available. In this case, more considerations need to be
> given to the mobility of a "peer".
>
> reload protocol.  Motivation for them and some discussion of related issues
> is in the p2psip-base appendix (and a much more extensive discussion in
> pascual-clients and others), but the actual mechanisms to support them
> should already be in the base draft.
>
> Discussion of further work identifying when a node should be a peer and
> when it should be a client, or overlay algorithms optimized for specific
> types of deployments, including "mobile", might be good topics for further
> work in new drafts, of course.
>
> Bruce
>
>
>

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Tue, 10 Feb 2009 17:09:00 +0800

Hi Das,

In my opinion, the P2P mobility addresses the issues like disconnection of two connected nodes in the overlay structure caused by the route unreachable in the network layer when nodes move. It's a different topic with implemeting DHT on MANETs, where considers the disconnection of a route caused by unreachable of a node on link level.  IP unreachable in mobile ad hoc networks mean the destination node or source node is isolated because of the limited radio access distance.

Best Regards,
Xiao Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Das, Saumitra
Sent: Tuesday, February 10, 2009 2:55 PM
To: [email-masked]
Subject: Re: [P2PSIP] mobile p2p in p2psip

Handling mobile nodes can be done in the framework of the base draft. For example, the DHT protocol itself can be different if the operating conditions are such that there is a lot of moiblity. There are several proposals for DHTs to operate efficiently on highly mobile networks such as MANETs. These should be doable under the pluggability principle of RELOAD.

The fact about who should be peer, client can be based on decisions of the overlay deployer. Some overlays make not have such choices being made up only of mobile nodes. There are various techniques to deal with excessive churn due to mobility and the consequent need to replicate data which can work under the framework of the base draft.

Best
Saumitra

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiao, Lin (NSN - CN/Beijing)
Sent: Monday, February 09, 2009 9:41 PM
To: ext Song Haibin; Henry Sinnreich; David Artu?edo Guillén; Victor Pascual ávila
Cc: longbwe longbwe; Wang, Sherry; [email-masked]
Subject: Re: [P2PSIP] mobile p2p in p2psip

Hi Bruce and Haibin:

Xiao Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Song Haibin
Sent: Tuesday, February 10, 2009 9:54 AM
To: 'Henry Sinnreich'; 'David Artu?edo Guillén'; 'Victor Pascual ávila'
Cc: 'longbwe longbwe'; 'Wang,Sherry'; [email-masked]
Subject: Re: [P2PSIP] mobile p2p in p2psip

Hi Henry and Bin,

BR
Song Haibin

Bruce

---

From: Dan York <[email-masked]>
Date: Tue, 10 Feb 2009 06:01:43 -0500

On Feb 10, 2009, at 1:55 AM, Das, Saumitra wrote:

> Handling mobile nodes can be done in the framework of the base  
> draft. For example, the DHT protocol itself can be different if
> the operating conditions are such that there is a lot of moiblity.  
> There are several proposals for DHTs to operate efficiently on highly

DY> Perhaps this has been discussed a hundred times before and I've  
missed it... but doesn't allowing different DHTs to be used in RELOAD  
introduce an interop issue?  i.e. Phones from Vendor A and Vendor B  
both nominally support "P2PSIP" but turn out to not be able to  
interoperate because their *implementations* of P2PSIP use different  
DHT algorithms/protocols?

DY> So we wind up with actually having multiple different P2PSIP  
variations:  P2PSIP/DHT1, P2PSIP/DHT2, P2PSIP/DHT3, etc.  With the  
result being that vendors must either choose a DHT implementation to  
support or having to support several of them?  (And yes, I realize  
that Chord is mandated by default.) It's not clear to me from reading  
the draft at:

http://tools.ietf.org/html/draft-ietf-p2psip-base-01#page-25

DY> Or later in Section 5 how the "overlay algorithm" is specified or  
known.  When I do a "JoinReq" as defined in section 5.3 ( http://tools.ietf.org/html/draft-ietf-p2psip-base-01#section-5.3 
  ) how do I know that my P2PSIP implementations DHT algorithm is  
compatible with the overlay algorithm of the P2PSIP network I am  
seeking to join?  (Do we need something almost like an SDP packet here  
that specifies the DHT algorithms that a P2PSIP node can support?  Or  
would it try using one DHT and then fall back to the defined Chord  
mechanism?)

DY> I completely understand the desire to use different DHTs in  
different kinds of overlay networks.  I'm just wondering if we are  
setting ourselves up for interoperability challenges as different  
people implement things called "P2PSIP" with very different underlying  
algorithms?

DY>  Or did I miss something fundamental in the draft where the choice  
of DHT algorithm is either irrelevant or dealt with? (And should I not  
be writing messages like this before having my morning caffeine?)

Regards,
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

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

---

From: Victor Pascual Ávila <[email-masked]>
Date: Tue, 10 Feb 2009 13:18:21 +0100

On Tue, Feb 10, 2009 at 12:01 PM, Dan York <[email-masked]> wrote:
>> Handling mobile nodes can be done in the framework of the base draft. For
>> example, the DHT protocol itself can be different if
>> the operating conditions are such that there is a lot of moiblity. There
>> are several proposals for DHTs to operate efficiently on highly
> DY> Perhaps this has been discussed a hundred times before and I've missed
> it... but doesn't allowing different DHTs to be used in RELOAD introduce an
> interop issue?  i.e. Phones from Vendor A and Vendor B both nominally
> support "P2PSIP" but turn out to not be able to interoperate because their
> *implementations* of P2PSIP use different DHT algorithms/protocols?

Here I'd say: "Chord is mandated by default. If any other algorithm is
used and you don't support it, act as a client"

> DY> So we wind up with actually having multiple different P2PSIP variations:
>  P2PSIP/DHT1, P2PSIP/DHT2, P2PSIP/DHT3, etc.  With the result being that
> vendors must either choose a DHT implementation to support or having to
> support several of them?  (And yes, I realize that Chord is mandated by
> default.) It's not clear to me from reading the draft at:
>
> DY> Or later in Section 5 how the "overlay algorithm" is specified or known.
>  When I do a "JoinReq" as defined in section 5.3 (
> http://tools.ietf.org/html/draft-ietf-p2psip-base-01#section-5.3 ) how do I
> know that my P2PSIP implementations DHT algorithm is compatible with the
> overlay algorithm of the P2PSIP network I am seeking to join?  (Do we need
> something almost like an SDP packet here that specifies the DHT algorithms
> that a P2PSIP node can support?  Or would it try using one DHT and then fall
> back to the defined Chord mechanism?)

Do you mean something like draft-jiang-p2psip-sep-01, section 6.1.1

http://tools.ietf.org/html/draft-jiang-p2psip-sep-01#section-6.1.1

Cheers,
-- 
Victor Pascual Ávila

---

From: Dan York <[email-masked]>
Date: Tue, 10 Feb 2009 09:35:19 -0500

On Feb 10, 2009, at 7:18 AM, Victor Pascual Ávila wrote:

>> missed

DY> Hmmmm... so a "client" doesn't need to know the DHT algorithm to  
join the overlay network?  Perhaps I just need more caffeine this  
morning, but I guess I don't understand how any node can join the  
overlay network without understanding the underlying algorithm.  I  
understand that a "peer" would need to know this to join in the  
overlay and the underlying DHT, but wouldn't the client also?

> http://tools.ietf.org/html/draft-jiang-p2psip-sep-01#section-6.1.1

DY> Yes, exactly.

DY> It would seem to me that if RELOAD is to support "pluggability"  
and allow alternate DHT algorithms, it would need something like this  
to allow a joining node to understand what underlying algorithm to use  
(and whether it *can* join the overlay network).

Dan

---

From: Victor Pascual Ávila <[email-masked]>
Date: Tue, 10 Feb 2009 15:58:08 +0100

Hi Dan,

On Tue, Feb 10, 2009 at 3:35 PM, Dan York <[email-masked]> wrote:
> DY> Hmmmm... so a "client" doesn't need to know the DHT algorithm to join
> the overlay network?  Perhaps I just need more caffeine this morning, but I
> guess I don't understand how any node can join the overlay network without
> understanding the underlying algorithm.  I understand that a "peer" would
> need to know this to join in the overlay and the underlying DHT, but
> wouldn't the client also?

See draft-pascual-p2psip-clients, Section 4, Argument number 4

http://tools.ietf.org/html/draft-pascual-p2psip-clients-01#page-6

Please, let me know your opinion.

> DY> It would seem to me that if RELOAD is to support "pluggability" and
> allow alternate DHT algorithms, it would need something like this to allow a
> joining node to understand what underlying algorithm to use (and whether it
> *can* join the overlay network).

+1

Cheers,
-- 
Victor Pascual Ávila

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 10 Feb 2009 07:00:29 -0800

>there could be three kinds of node in the overlay: fixed (e.g. desktop), mobile (e.g. >handset) and mixed (e.g. laptop). Fixed nodes are obviously good candidates for peers of >overlay, while mobile handsets should be limited in client status considering not only their >limited capability and resources but also the highly mobile characteristic. Some devices >like laptop could perform either as peers or as clients depending on requirement.

I believe this is a key new insight brought to the WG and should be reflected in the WG documents. The laptop example is quite convincing in such scenarios as opening the netbook for a quick call at the airport and closing it it immediately afterwards.

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiao, Lin (NSN - CN/Beijing)
Sent: Monday, February 09, 2009 9:41 PM
To: ext Song Haibin; Henry Sinnreich; David Artu?edo Guillén; Victor Pascual ávila
Cc: longbwe longbwe; Wang, Sherry; [email-masked]
Subject: Re: [P2PSIP] mobile p2p in p2psip

Hi Bruce and Haibin:

Xiao Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Song Haibin
Sent: Tuesday, February 10, 2009 9:54 AM
To: 'Henry Sinnreich'; 'David Artu?edo Guillén'; 'Victor Pascual ávila'
Cc: 'longbwe longbwe'; 'Wang,Sherry'; [email-masked]
Subject: Re: [P2PSIP] mobile p2p in p2psip

Hi Henry and Bin,

BR
Song Haibin

Bruce

---

From: Dan York <[email-masked]>
Date: Tue, 10 Feb 2009 10:06:11 -0500

Victor,

> Please, let me know your opinion.

DY> Ah... so the clients communicate with the P2P overlay "peer" nodes  
by way of the "client protocol".  So if the P2P overlay supports such  
a client protocol, client nodes can connect to the overlay without any  
knowledge of the underlying DHT algorithm (or anything else in the  
underlying overlay network).

DY> Got it... thanks for explaining.

DY> This does, of course, assume that whatever P2PSIP protocol we use  
would have a client protocol.

Regards,
Dan

---

From: "Wang, Sherry" <[email-masked]>
Date: Tue, 10 Feb 2009 11:00:51 -0500

Henry,

Agree: the type of mixed can be a candidate to study mobile P2PSIP. There would be cases where capacity and resources may not be limited while keeping a RF connection is a challenge by using the model of client/server of existing SIP, especially in terms of performance. For example, high-speed flying devices or moderate-speed ground vehicles for military use, etc. Your emergency rescue is another good example of the mixed type.

Thanks,
Sherry
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henry Sinnreich
Sent: Tuesday, February 10, 2009 10:00 AM
To: [email-masked]
Subject: Re: [P2PSIP] mobile p2p in p2psip

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiao, Lin (NSN - CN/Beijing)
Sent: Monday, February 09, 2009 9:41 PM
To: ext Song Haibin; Henry Sinnreich; David Artu?edo Guillén; Victor Pascual ávila
Cc: longbwe longbwe; Wang, Sherry; [email-masked]
Subject: Re: [P2PSIP] mobile p2p in p2psip

Hi Bruce and Haibin:

Xiao Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Song Haibin
Sent: Tuesday, February 10, 2009 9:54 AM
To: 'Henry Sinnreich'; 'David Artu?edo Guillén'; 'Victor Pascual ávila'
Cc: 'longbwe longbwe'; 'Wang,Sherry'; [email-masked]
Subject: Re: [P2PSIP] mobile p2p in p2psip

Hi Henry and Bin,

BR
Song Haibin

Bruce

---

From: "David A. Bryan" <[email-masked]>
Date: Tue, 10 Feb 2009 11:08:29 -0500

If having a mechanism to negotiate the DHT isn't in there, it
definitely is something that needs to be corrected. Going all the way
back to draft-bryan-sipping-p2p-02 there were fields for specifying
which DHT should be used, and a section on negotiating it (since it
was SIP, it was very straight-forward -- we specified that you use
offer/answer...). I'm fine with falling back to a client protocol
connection, but that doesn't change the fact we need a mechanism to
negotiate the DHT if we support pluggable DHTs. Failing to find a
common one, you can fall back to client connection.

It may very well be there, or it could have somehow fallen out of the
most recent version (can one of the authors comment?) If it did fall
out somehow, it is good for people to point things like this out about
RELOAD. I think when things got merged, many of the practical parts
that were in the earlier drafts (at least those that were actually
implemented) got unintentionally lost, or at least the descriptions
became less clear as the complexity grew, and these are exactly the
sorts of things that need to be corrected as we work to move forward
the draft.

David (as individual)

On Tue, Feb 10, 2009 at 10:06 AM, Dan York <[email-masked]> wrote:
> DY> Ah... so the clients communicate with the P2P overlay "peer" nodes by
> way of the "client protocol".  So if the P2P overlay supports such a client
> protocol, client nodes can connect to the overlay without any knowledge of
> the underlying DHT algorithm (or anything else in the underlying overlay
> network).
>
> DY> This does, of course, assume that whatever P2PSIP protocol we use would
> have a client protocol.
>
> Regards,
> Dan
>
> --

---

From: "Wang, Sherry" <[email-masked]>
Date: Tue, 10 Feb 2009 11:11:17 -0500

I like the idea "I also appreciate there could be a dynamic role transferring mechanism between peer and client for one signal node regarding the changing environments." Is it similar to SIP's change a medium in the middle of a session? thanks, sherry
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of longbwe longbwe
Sent: Tuesday, February 10, 2009 3:41 AM
To: Xiao, Lin (NSN - CN/Beijing)
Cc: Wang, Sherry; [email-masked]; Henry Sinnreich
Subject: Re: [P2PSIP] mobile p2p in p2psip

Hi Xiao,
Thanks for your thoughts! I also agree the distinctions between peer and client, for there could be heterogeneous devices in the overlay, we cannot assume only one role for all of them.You note that nodes may be devided into three categories:fixed,mobile and mixed, with the preferences that fixed nodes act peers and mobile nodes act clients.What if most nodes of the overlay are mobile and there are not enough fixed nodes running as peers?This is certainly becoming the case,with the emergences of more powerful and smarter mobile devices such as iPhone and GPhone, cell phones are functioning more like a small PC and young people will prefer their mobile phones to laptops.
I also appreciate there could be a dynamic role transferring mechanism between peer and client for one singal node regarding the changing environments.

On Tue, Feb 10, 2009 at 1:40 PM, Xiao, Lin (NSN - CN/Beijing) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Bruce and Haibin:

Xiao Lin

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Song Haibin
Sent: Tuesday, February 10, 2009 9:54 AM
To: 'Henry Sinnreich'; 'David Artu?edo Guillén'; 'Victor Pascual ávila'
Cc: 'longbwe longbwe'; 'Wang,Sherry'; [email-masked]<mailto:[email-masked]>
Subject: Re: [P2PSIP] mobile p2p in p2psip

Hi Henry and Bin,

BR
Song Haibin

Bruce

---

From: "David A. Bryan" <[email-masked]>
Date: Tue, 10 Feb 2009 11:15:51 -0500

This is a very good point Henry. I have often thought that for a
scenario like this, you probably just want to be a client...which
could mean that a good behavior for a device (this wouldn't be
specified in a protocol, just something an implementor does) would be
to connect as a client and only switch to a peer after some period of
time with a fixed IP address. I realize that is a simplistic way to do
it, but it could solve the problem without extensive draft/protocol
efforts. Now this raises the question of devices never being peers as
a result (even if capable) and having no one willing to serve as a
peer, but that is a whole different issue...

David (as individual)

On Tue, Feb 10, 2009 at 10:00 AM, Henry Sinnreich <[email-masked]> wrote:
>>there could be three kinds of node in the overlay: fixed (e.g. desktop),
>> mobile (e.g. >handset) and mixed (e.g. laptop). Fixed nodes are obviously
>> good candidates for peers of >overlay, while mobile handsets should be
>> limited in client status considering not only their >limited capability and
>> resources but also the highly mobile characteristic. Some devices >like
>> laptop could perform either as peers or as clients depending on requirement.
>
> I believe this is a key new insight brought to the WG and should be
> reflected in the WG documents. The laptop example is quite convincing in
> such scenarios as opening the netbook for a quick call at the airport and
> closing it it immediately afterwards.
>
> Henry
>
> Xiao, Lin (NSN - CN/Beijing)
> ext Song Haibin
> Discussion of further work identifying when a node should be a peer and when
> it should be a client, or overlay algorithms optimized for specific types of
> deployments, including "mobile", might be good topics for further work in
> new drafts, of course.
>
> Bruce
>
>
>

---

From: Erkki Harjula <[email-masked]>
Date: Tue, 10 Feb 2009 11:42:38 -0500

I agree,

increasing percentage of Internet nodes are mobile or "mixed" nodes, and 
I cannot see anything that would stop this development. Thus, we will 
see also more and more scenarios where there is simply not enough fixed 
devices to successfully run the overlay. This makes it mandatory to 
consider also mobile and mixed nodes as peers.

Mobile node as a peer is, however, a challenging scenario due to 
following reasons:
-Most of mobile devices are behind NATs and/or restrictive firewalls 
(already discussed quite thoroughly)
-The usage of mobile devices might be very transient (=>churn), as Henry 
already pointed out
-Hardware capabilities are still restricted when compared to fixed devices
-Nodes have usually many network interfaces (3g, wifi, etc.), and 
vertical mobility is common
-Limited battery capacity

These features set challenges especially to NAT/FW traversal, dynamic 
peer selection, load balancing and energy-efficiency.

-Erkki

longbwe longbwe wrote:
> What if most nodes of the overlay are mobile and there are not enough 
> fixed nodes running as peers?This is certainly becoming the case,with 
> the emergences of more powerful and smarter mobile devices such as 
> iPhone and GPhone, cell phones are functioning more like a small PC 
> and young people will prefer their mobile phones to laptops.

---

From: Bruce Lowekamp <[email-masked]>
Date: Tue, 10 Feb 2009 11:50:37 -0500

> DY> This does, of course, assume that whatever P2PSIP protocol we use would

Clients are an integral part of the current reload protocol.  This is
already there without a need for a separate client protocol.  A client
doesn't need  to know anything about the overlay algorithm, it just
sets the destination in the via list and lets the peer it's connected
to figure out to get it there.

http://www.p2psip.org/drafts/draft-ietf-p2psip-base-01a.html#anchor11

Bruce

---

From: Bruce Lowekamp <[email-masked]>
Date: Tue, 10 Feb 2009 11:52:31 -0500

the algorithm is specified as "topology-plugin" in the overlay configuration.

http://www.p2psip.org/drafts/draft-ietf-p2psip-base-01a.html#sec-configuration

Bruce

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 10 Feb 2009 09:24:15 -0800

Thanks Sherry for the examples, especially for mentioning the distinction between P2P and CS.
Here is a use case: There is a nationwide/international event broadcast from a web site, such as a presidential election debate or an Olympic competition. The web site is voice enabled for friends to chat while watching the event. This generates a huge spike in voice traffic, roughly for the duration of the event. It would be impossible the design CS SIP  networks to cope with such traffic spiking apps IMO. Only a P2P SIP network would make sense in such a scenario to cope with fast scalability.

Maybe using cloud computing for large scale CS SIP traffic events may also work, but we would need a new WG for SIP-RTP Cloud Computing...  :-)

Henry

On 2/10/09 10:00 AM, "Wang, Sherry" <[email-masked]> wrote:

Henry,

Thanks,
Sherry

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On  Behalf Of Xiao, Lin (NSN - CN/Beijing)
Sent: Monday, February 09, 2009 9:41  PM
To: ext Song Haibin; Henry Sinnreich; David Artu?edo Guillén; Victor  Pascual ávila
Cc: longbwe longbwe; Wang, Sherry; [email-masked]
Subject: Re: [P2PSIP] mobile p2p  in p2psip

Hi Bruce and Haibin:

Xiao Lin

-----Original  Message-----
From: [email-masked] [mailto:[email-masked]] On  Behalf Of ext Song Haibin
Sent: Tuesday, February 10, 2009 9:54 AM
To:  'Henry Sinnreich'; 'David Artu?edo Guillén'; 'Victor Pascual ávila'
Cc:  'longbwe longbwe'; 'Wang,Sherry'; [email-masked]
Subject: Re: [P2PSIP] mobile p2p  in p2psip

Hi Henry and Bin,

BR
Song Haibin

Bruce

---

From: "Wang, Sherry" <[email-masked]>
Date: Tue, 10 Feb 2009 15:03:56 -0500

Henry,

An excellent use case! Should we start from there?

Sherry

________________________________
From: Henry Sinnreich [mailto:[email-masked]]
Sent: Tuesday, February 10, 2009 12:24 PM
To: Wang, Sherry; [email-masked]
Subject: Re: [P2PSIP] mobile p2p in p2psip

Henry

Henry,

Thanks,
Sherry

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On  Behalf Of Xiao, Lin (NSN - CN/Beijing)
Sent: Monday, February 09, 2009 9:41  PM
To: ext Song Haibin; Henry Sinnreich; David Artu?edo Guillén; Victor  Pascual ávila
Cc: longbwe longbwe; Wang, Sherry; [email-masked]
Subject: Re: [P2PSIP] mobile p2p  in p2psip

Hi Bruce and Haibin:

Xiao Lin

-----Original  Message-----
From: [email-masked] [mailto:[email-masked]] On  Behalf Of ext Song Haibin
Sent: Tuesday, February 10, 2009 9:54 AM
To:  'Henry Sinnreich'; 'David Artu?edo Guillén'; 'Victor Pascual ávila'
Cc:  'longbwe longbwe'; 'Wang,Sherry'; [email-masked]
Subject: Re: [P2PSIP] mobile p2p  in p2psip

Hi Henry and Bin,

BR
Song Haibin

Bruce

---

From: "Das, Saumitra" <[email-masked]>
Date: Tue, 10 Feb 2009 12:49:54 -0800

Hi Xiao,

  I just put the MANET as an example that may need a different DHT plugin. P2P mobility (nto MANET mobility) simply shows up as excessive churn and a network with a lot of mobile peers would have to deal with such churn. As long as the mobile peer can rejoin the network everything works. Dealing with a failed network connection due to mobility or the node going down from churn is similar.

Best,
Saumitra

-----Original Message-----
From: Xiao, Lin (NSN - CN/Beijing) [mailto:[email-masked]] 
Sent: Tuesday, February 10, 2009 1:09 AM
To: Das, Saumitra; [email-masked]
Subject: RE: [P2PSIP] mobile p2p in p2psip

Hi Das,

Best Regards,
Xiao Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Das, Saumitra
Sent: Tuesday, February 10, 2009 2:55 PM
To: [email-masked]
Subject: Re: [P2PSIP] mobile p2p in p2psip

Best
Saumitra

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiao, Lin (NSN - CN/Beijing)
Sent: Monday, February 09, 2009 9:41 PM
To: ext Song Haibin; Henry Sinnreich; David Artu?edo Guillén; Victor Pascual ávila
Cc: longbwe longbwe; Wang, Sherry; [email-masked]
Subject: Re: [P2PSIP] mobile p2p in p2psip

Hi Bruce and Haibin:

Xiao Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Song Haibin
Sent: Tuesday, February 10, 2009 9:54 AM
To: 'Henry Sinnreich'; 'David Artu?edo Guillén'; 'Victor Pascual ávila'
Cc: 'longbwe longbwe'; 'Wang,Sherry'; [email-masked]
Subject: Re: [P2PSIP] mobile p2p in p2psip

Hi Henry and Bin,

BR
Song Haibin

Bruce

---

From: Minh Nguyen <[email-masked]>
Date: Wed, 11 Feb 2009 00:04:13 +0100

Hi all,

I think that Henry has given a good example. In some cases, the distinction
between mixed node and mobile node could be good choice.

Mixed node performs either as peer or as client and have no high movement.
On the other hands, Mobile node such as mobile phone, PDAs could be only a
client with high mobility. This kind of network like MESH rather than MANET

We could image this network could be fixed for many scenarios such as
emergency case, exposition, airport...

This distinction also allows us the possibility to develop software client
agent with many features on mobile device in conjunction with P2PSIP.

Moreover, DHT overlay has limited performance under high mobility enviroment
which called "churn" and Mobile devices with low computing-capacity are
unsuitable to act a peer node.

Cheers,
-Minh

On Tue, Feb 10, 2009 at 4:00 PM, Henry Sinnreich <[email-masked]> wrote:

> From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf Of Xiao, Lin (NSN - CN/Beijing)
> From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf Of ext Song Haibin

-- 
  Minh Nguyen
+33 6 65764460

---

From: Victor Pascual Ávila <[email-masked]>
Date: Wed, 11 Feb 2009 00:24:27 +0100

> unsuitable to act a peer node.

In general, it is better for the overlay when more 'qualified' devices
become Peers rather than Clients.  Whether a node is 'qualified' or
not depends on the application scenario.

Regards,
-- 
Victor Pascual Ávila

---

From: Song Haibin <[email-masked]>
Date: Wed, 11 Feb 2009 11:09:44 +0800

>David A. Bryan
>Sent: Wednesday, February 11, 2009 12:08 AM

>I'm fine with falling back to a client protocol
>negotiate the DHT if we support pluggable DHTs. 

IMO, a node may support several DHTs, however in most case an overlay may
only support one DHT only (not sure). So a node only has two choices: (1) if
it supports the DHT in the overlay configuration file, it can act as either
a peer or client (2) if it does not support the DHT in the overlay
configuration file, it can only act as a client

Song Haibin

---

From: Dan York <[email-masked]>
Date: Tue, 10 Feb 2009 22:56:44 -0500

Ah, so it is...  thanks for the pointer, Bruce.  I did indeed miss  
something fundamental in the draft.

Could I suggest that in the base in section 3.5 there is a line of  
text added along the lines of:

------
The Topology Plugin is described in further detail in the section on  
"Overlay Topology".
------

Or something like that to clue other readers in about the section to  
jump ahead to?

Also, why is section 11.1 with the "Overlay Configuration" separated  
so far away from the pieces related to the overview topology in  
section 5.3?

Might it not make more sense to have section 11.1 as a subsection of  
5.3 so that it is right there with the other info about using  
alternate topology algorithms?

Thanks,
Dan

On Feb 10, 2009, at 11:52 AM, Bruce Lowekamp wrote:

>>>>> the overlay network?  Perhaps I just need more caffeine this  
>>>>> morning, but
>>>>> I

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Wed, 11 Feb 2009 15:06:13 +0800

Hi Das,

Yes. Agree with you on "Dealing with a failed network connection due to mobility or the node going down from churn is similar". 

So, in order to decrease the unexpected disconnection brought by mobility, the qualification for a node to be a peer should include the serious consideration on its mobile feature. That's why I proposed to use "mobile", "fixed" and "mixed" to classify nodes with different mobile feature in P2P communication. It makes things simpler to appoint roles for distinct nodes in the overlay. 

Using mobile nodes as peers highly increases the maintenance cost of the overlay structure. The ideal P2P communication (from the point of mobility feature) is using fixed peers to construct overlay with clients either fixed or mobile. Therefore, little churn would be given to the overlay structure and a simple client protocol can be designed to maintain the connection between clients with the overlay even in high mobility. Of course, the role transfer of mixed nodes (peers <--> clients) should also be considered in different scenarios. 

Best Regards,
Xiao Lin

-----Original Message-----
From: ext Das, Saumitra [mailto:[email-masked]] 
Sent: Wednesday, February 11, 2009 4:50 AM 
To: Xiao, Lin (NSN - CN/Beijing); [email-masked]
Subject: RE: [P2PSIP] mobile p2p in p2psip

Hi Xiao,

Best,
Saumitra

-----Original Message-----
From: Xiao, Lin (NSN - CN/Beijing) [mailto:[email-masked]]
Sent: Tuesday, February 10, 2009 1:09 AM
To: Das, Saumitra; [email-masked]
Subject: RE: [P2PSIP] mobile p2p in p2psip

Hi Das,

Best Regards,
Xiao Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Das, Saumitra
Sent: Tuesday, February 10, 2009 2:55 PM
To: [email-masked]
Subject: Re: [P2PSIP] mobile p2p in p2psip

Best
Saumitra

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiao, Lin (NSN - CN/Beijing)
Sent: Monday, February 09, 2009 9:41 PM
To: ext Song Haibin; Henry Sinnreich; David Artu?edo Guillén; Victor Pascual ávila
Cc: longbwe longbwe; Wang, Sherry; [email-masked]
Subject: Re: [P2PSIP] mobile p2p in p2psip

Hi Bruce and Haibin:

Xiao Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Song Haibin
Sent: Tuesday, February 10, 2009 9:54 AM
To: 'Henry Sinnreich'; 'David Artu?edo Guillén'; 'Victor Pascual ávila'
Cc: 'longbwe longbwe'; 'Wang,Sherry'; [email-masked]
Subject: Re: [P2PSIP] mobile p2p in p2psip

Hi Henry and Bin,

BR
Song Haibin

Bruce

---

From: Minh Nguyen <[email-masked]>
Date: Wed, 11 Feb 2009 10:17:37 +0100

Hi Xiao,

> Using mobile nodes as peers highly increases the maintenance cost of the
> overlay structure. The ideal P2P communication (from the point of mobility
> feature) is using fixed peers to construct overlay with clients either fixed
> or mobile.
>

I totally agree with you. A Peer who has high mobility should be come a
Client to reduce the maintain cost of Overlay. On the other hand, Clients
has 'qualified' and low movement can become a Peer. However, It probably
depends on different context.

Best regards,
-Minh

>  I just put the MANET as an example that may need a different DHT plugin.
> P2P mobility (nto MANET mobility) simply shows up as excessive churn and a
> network with a lot of mobile peers would have to deal with such churn. As
> long as the mobile peer can rejoin the network everything works. Dealing
> with a failed network connection due to mobility or the node going down from
> churn is similar.
>
> Best,
> Saumitra
>
>
> In my opinion, the P2P mobility addresses the issues like disconnection of
> two connected nodes in the overlay structure caused by the route unreachable
> in the network layer when nodes move. It's a different topic with
> implemeting DHT on MANETs, where considers the disconnection of a route
> caused by unreachable of a node on link level.  IP unreachable in mobile ad
> hoc networks mean the destination node or source node is isolated because of
> the limited radio access distance.
>
>
> Best Regards,
> Xiao Lin
>
> example, the DHT protocol itself can be different if the operating
> conditions are such that there is a lot of moiblity. There are several
> proposals for DHTs to operate efficiently on highly mobile networks such as
> MANETs. These should be doable under the pluggability principle of RELOAD.
>
> The fact about who should be peer, client can be based on decisions of the
> overlay deployer. Some overlays make not have such choices being made up
> only of mobile nodes. There are various techniques to deal with excessive
> churn due to mobility and the consequent need to replicate data which can
> work under the framework of the base draft.
>

-- 
  Minh Nguyen
+33 6 65764460

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Wed, 11 Feb 2009 17:23:32 +0800

Hi Bruce,

You said " A client doesn't need  to know anything about the overlay algorithm". Does it mean client node can not even run the Hash for resource ID for itself? If so, almost all the functionalities of the reload are realized by peers. Only the unified Node_ID connects the clients and peers topologically in a same overlay level. However, even this kind of topology relationship is not stable considering the unreachability of a client to its responsible peer caused by client mobility or something else (That's the reason that, I think, reload base has the second option for client routing in section 3.2.1). I totally agree to allocate Node_ID for clients to give them a status for communication with peers at overlay layer level. But besides this, I do not think there is necessary to integrate client protocol into peer protocol, considering the different behavior of them. It could make such an all-in-one protocol too complex. So, I still think separated description for peers and clients could make things more clear. : )

Best Regards,
Xiao Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Bruce Lowekamp
Sent: Wednesday, February 11, 2009 12:51 AM
To: Dan York
Cc: [email-masked]
Subject: Re: [P2PSIP] Interoperability vs Pluggability (was Re: mobile p2pin p2psip)

On Tue, Feb 10, 2009 at 10:06 AM, Dan York <[email-masked]> wrote:
>>> DY> join
> DY> by
> way of the "client protocol".  So if the P2P overlay supports such a 
> client protocol, client nodes can connect to the overlay without any 
> DY> would

Clients are an integral part of the current reload protocol.  This is already there without a need for a separate client protocol.  A client doesn't need  to know anything about the overlay algorithm, it just sets the destination in the via list and lets the peer it's connected to figure out to get it there.

Bruce

---

From: Bruce Lowekamp <[email-masked]>
Date: Wed, 11 Feb 2009 08:02:50 -0500

The minimum requirements for clients are discussed in

http://www.p2psip.org/drafts/draft-ietf-p2psip-base-01a.html#anchor13

The current protocol is already an integrated protocol, for clients
that are able to meet those requirements (which essentially mean that
the clients are capable of originating their own messages that can be
routed across the overlay).

There is also a further discussion of peers vs clients in
Bruce

---

From: Bruce Lowekamp <[email-masked]>
Date: Wed, 11 Feb 2009 08:10:26 -0500

Hmmm.  Adding a forward reference in 3.5 is trivial.

I don't know about moving it, though.  There are so many different
things that can be in the overlay configuration file, and I think that
makes a lot more sense to keep it with the rest of the
discovery/enrollment issues.  I think you could make more of an
argument to move all of 11 earlier in the draft, though I'd have to
think about that for awhile.

Bruce

On Tue, Feb 10, 2009 at 10:56 PM, Dan York <[email-masked]> wrote:
> Ah, so it is...  thanks for the pointer, Bruce.  I did indeed miss something
> fundamental in the draft.
>
> Could I suggest that in the base in section 3.5 there is a line of text
> added along the lines of:
>
> ------
> Or something like that to clue other readers in about the section to jump
> ahead to?
>
> Also, why is section 11.1 with the "Overlay Configuration" separated so far
> away from the pieces related to the overview topology in section 5.3?
>
> Might it not make more sense to have section 11.1 as a subsection of 5.3 so
> that it is right there with the other info about using alternate topology
> algorithms?
>
> Thanks,
> Dan
>
>>>>>> join
>>>>>> the overlay network?  Perhaps I just need more caffeine this morning,
>>>>>> but
>>>>>> I
>>>> by
>>>> client

---

From: "Roni Even" <[email-masked]>
Date: Wed, 11 Feb 2009 21:03:38 +0200

The IANA section also has Overlay Algorithm Types registry

Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bruce Lowekamp
Sent: Tuesday, February 10, 2009 6:53 PM
To: David A. Bryan
Cc: [email-masked]
Subject: Re: [P2PSIP] Interoperability vs Pluggability (was Re: mobile p2p in p2psip)

Bruce