Re: [P2PSIP] mobile p2p in p2psip

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

<= /div>

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.
Looking for your responses.

Best = regards,
Bin Long

On Mon, Feb 9, 2009 at 4:12 PM, Song Haibin <melodysong@huawei.com> = wrote:

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: melodysong@huawei.com
= Skype: alexsonghw

________________________________________
=
From: p2psip-bounces@ietf.org = [mailto:p2psip-bounces@ietf.org] On = Behalf Of

David Artu?edo Guill=E9n
Sent: Monday, February = 09, 2009 3:40 PM
To: Henry Sinnreich
Cc: longbwe longbwe; Wang, = Sherry; p2psip@ietf.org
= 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" <hsinnrei@adobe.com> escribi=F3:
= 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" <longbwee@gmail.com> 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 <Sherry.Wang@jhuapl.edu>
= 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: p2psip-bounces@ietf.org = [mailto:p2psip-bounces@ietf.org] On = Behalf Of
longbwe longbwe
Sent: Friday, February 06, 2009 1:39 = AM
To: p2psip@ietf.org
= 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

= _______________________________________________
P2PSIP mailing = list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
=

= _______________________________________________
P2PSIP mailing = list
P2PSIP@ietf.org
https://www.ietf.or= g/mailman/listinfo/p2psip

---

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:kurt.tutschku@univie.ac.= at or mailto:kurttutschku@gmail.com

= --Apple-Mail-15-340786120-- From victor.pascual.avila@gmail.com Mon Feb 9 09:41:39 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307623A6B26 for ; Mon, 9 Feb 2009 09:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[AWL=-0.659, BAYES_00=-2.599, FRT_ADOBE2=2.455, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1-Hx1qTIufg for ; Mon, 9 Feb 2009 09:41:38 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id 3E6073A6B5E for ; Mon, 9 Feb 2009 09:41:38 -0800 (PST) Received: by ewy14 with SMTP id 14so2667066ewy.13 for ; Mon, 09 Feb 2009 09:41:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8nE4/RK7iD/cKZnGdGw+mciKwgQZU0CNLRekU2CzcEQ=; b=FmaW3yHbl4I8vT4I0BgbZMjYAoXnypV8sBa8ygcRo/8g2UhOJ6e4VPQG1eDaxUV3Vi DXhy3WqtYINuB5GkopbMtVfVodRkS6cQPJiymQyeteuXroypJVb6In4IUTUEvBPFdVM+ wjUxIeP2fG04PRYnwyP2yiCP4Ta/O1qfx/z2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aUavO/knM8z6Jmd+80gpqLplmhjf5VLG4kxZQePy8rR/apiysbbd+5A4SGRDVdvbLh rwOTJh16hJrU3DPJv8VSxJaeb0kuQfGtcRHdf4ks1oP0k2DadBLfmsnEu75hWpiNGLMK YPiGJTMEaKf+EV3qBOxEKdZpVUfDtvXWryTMQ= MIME-Version: 1.0 Received: by 10.210.52.15 with SMTP id z15mr3993198ebz.179.1234201298946; Mon, 09 Feb 2009 09:41:38 -0800 (PST) In-Reply-To: References: <792337B2-9D67-4BD7-A4A1-A052B205829B@tid.es> Date: Mon, 9 Feb 2009 18:41:38 +0100 Message-ID: <618e24240902090941u19b6440ocdb428b7b0a68f1e@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= To: Henry Sinnreich Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: longbwe longbwe , "Wang, Sherry" , "p2psip@ietf.org" Subject: Re: [P2PSIP] mobile p2p in p2psip X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:41:39 -0000 Hi Henry, On Mon, Feb 9, 2009 at 5:16 PM, Henry Sinnreich wrote: > There was an I-D (now expired) on this: > Pascual, V., Matuszewski, M., Shim, E., Zhang, H., and S. Yongchao, "P2PS= IP > Clients", > > > It was preceded and followed by many discussions on this topic, such as t= hat > 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, --=20 Victor Pascual =C3=81vila From bbl@lowekamp.net Mon Feb 9 09:47:17 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ADCB3A6B70 for ; Mon, 9 Feb 2009 09:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=-1.245, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0F12V0xShZm for ; Mon, 9 Feb 2009 09:47:16 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 7122F3A69EC for ; Mon, 9 Feb 2009 09:46:40 -0800 (PST) Received: by qyk4 with SMTP id 4so2771393qyk.13 for ; Mon, 09 Feb 2009 09:46:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.97.202 with SMTP id m10mr1409921qcn.77.1234201599896; Mon, 09 Feb 2009 09:46:39 -0800 (PST) In-Reply-To: <618e24240902090941u19b6440ocdb428b7b0a68f1e@mail.gmail.com> References: <792337B2-9D67-4BD7-A4A1-A052B205829B@tid.es> <618e24240902090941u19b6440ocdb428b7b0a68f1e@mail.gmail.com> Date: Mon, 9 Feb 2009 12:46:39 -0500 Message-ID: From: Bruce Lowekamp To: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: longbwe longbwe , Henry Sinnreich , "Wang, Sherry" , "p2psip@ietf.org" Subject: Re: [P2PSIP] mobile p2p in p2psip X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:47:17 -0000 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 On Mon, Feb 9, 2009 at 12:41 PM, Victor Pascual =C3=81vila wrote: > Hi Henry, > > On Mon, Feb 9, 2009 at 5:16 PM, Henry Sinnreich wrot= e: >> There was an I-D (now expired) on this: >> Pascual, V., Matuszewski, M., Shim, E., Zhang, H., and S. Yongchao, "P2P= SIP >> 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 =C3=81vila > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From hsinnrei@adobe.com Mon Feb 9 09:47:21 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF3A43A68B1 for ; Mon, 9 Feb 2009 09:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.071 X-Spam-Level: X-Spam-Status: No, score=-5.071 tagged_above=-999 required=5 tests=[AWL=-1.527, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjlYvYhxk3gQ for ; Mon, 9 Feb 2009 09:47:20 -0800 (PST) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by core3.amsl.com (Postfix) with ESMTP id F276D3A6B26 for ; Mon, 9 Feb 2009 09:47:09 -0800 (PST) Received: from source ([192.150.11.134]) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKSZBsHqCuWhU0LQhbVlTwp7Ys1oISOhlK@postini.com; Mon, 09 Feb 2009 09:47:22 PST Received: from inner-relay-3.eur.adobe.com ([192.150.8.236]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n19HfveM024758; Mon, 9 Feb 2009 09:41:58 -0800 (PST) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n19Hl4Y2016356; Mon, 9 Feb 2009 09:47:05 -0800 (PST) Received: from fe01.corp.adobe.com (10.8.192.82) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 9 Feb 2009 09:47:04 -0800 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by fe01.corp.adobe.com ([10.8.192.82]) with mapi; Mon, 9 Feb 2009 09:47:03 -0800 From: Henry Sinnreich To: Kurt Tutschku , longbwe longbwe Date: Mon, 9 Feb 2009 09:47:01 -0800 Thread-Topic: [P2PSIP] mobile p2p in p2psip Thread-Index: AcmK10dacZghHP6wQqy59QeJVCEYcAAByHnz Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C5B5C836B471hsinnreiadobecom_" MIME-Version: 1.0 Cc: "Wang, Sherry" , "p2psip@ietf.org" Subject: Re: [P2PSIP] mobile p2p in p2psip X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:47:22 -0000 --_000_C5B5C836B471hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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" wrote: Dear all, as Bin explained, disconnections and reconnections will occur in wireless s= ystems more frequently as in wireline system. The effect of "churn" is not = negligible. An comprehensive analysis of the impact of churn is available i= n: A. Binzenhoefer and K. Leibnitz: "Estimating Churn in Structured P2P Networ= ks.", 20th International Teletraffic Congress (ITC20), Ottawa, Canada, Jun= e 2007. available at http://www3.informatik.uni-wuerzburg.de/papers/conf_26= 1.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 b= e vulnerable, disconnetions and reconnections can ouccur more frequently, y= ou 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 arc= hitectures for integrated MANETs and wide-area networks,Mobile P2P on diffe= rent 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 wrote: 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 use= d to solve this problem? Best Regards, Haibin Email: melodysong@huawei.com Skype: alexsonghw ________________________________________ From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of David Artu?edo Guill=E9n Sent: Monday, February 09, 2009 3:40 PM To: Henry Sinnreich Cc: longbwe longbwe; Wang, Sherry; p2psip@ietf.org 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 i= t introduces similar challenges, IMHO. BR Enviado desde mi iPhone El 08/02/2009, a las 21:22, "Henry Sinnreich" escribi= =F3: Please help me understand the technical (not marketing) meaning of mobile p2p. Mobility is inherent on the Internet and can be implemented in several way= s. Or are you referring to to mobile phones not connected to the Internet? Where is the protocol capability difference between a laptop, a netbook an= d 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 b= uy it? Henry On 2/7/09 2:57 AM, "longbwe longbwe" wrote: Sheery, Thanks very much for your reply.Maybe it is a little early to set a sepera= te WG for Mobile P2P, I am wondering whether the work of P2PSip can be extensible to wireless scenarios, e.g. its architecture.Mobility managemen= t is certainly one of our interested fields, which also include the network topology, architecture, peer protocol, private issue, security and so on.W= e 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 wrote: Bin, It's out of question that we should do it. I have seen mobile P2P research= es 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: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf O= f longbwe longbwe Sent: Friday, February 06, 2009 1:39 AM To: p2psip@ietf.org Subject: [P2PSIP] mobile p2p in p2psip Hi all, We want to know if mobile p2p can be discussed in this WG, or the p2psip i= s 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 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip --- Prof. Dr. Kurt Tutschku Chair of Future Communication (Endowed by Telekom Austria) Institute of Distributed and Multimedia Systems, Faculty of Computer Scienc= e 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:kurt.tutschku@univie.ac.at or mailto:kurttutschku@gmail.com --_000_C5B5C836B471hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [P2PSIP] mobile p2p in p2psip Kurt,

The link that you have provided requires name and password.
htt= p://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" <kurt.tutschku@univie.ac.at> wrote:

Dear all,

as Bin explained, disconnections and reconnections will occur in wireless s= ystems more frequently as in wireline system. The effect of "churn&quo= t; is not negligible. An comprehensive analysis of the impact of churn is a= vailable in:

A. Binzenhoefer and K. Leibnitz: "Estimating Churn in Structured P2P N= etworks.", 20th International Teletraffic Congress (ITC20), Otta= wa, Canada, June 2007. available at http://www3.informatik.uni-wuerzburg.de/pa= pers/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 Genera= tion Distributed Environments: Advancing Conceptual and Algorithmic Applica= tions", 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 b= e vulnerable, disconnetions and reconnections can ouccur more frequently, y= ou 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 network= s, p2p architectures for integrated MANETs and wide-area networks,Mobile P2= P 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 <melodysong@huawei.com> wrote:

Hi David,

I think you get to the point. The p2p layer connection continuity is<= BR> important for the mobile overlay network. I want to know if some gene= ric
mobility techniques which are independent of the applications could b= e used
to solve this problem?

Best Regards,
Haibin
Email: melodysong@huawei.com Skype: alexsonghw

________________________________________

From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] = On Behalf Of

David Artu?edo Guillén
Sent: Monday, February 09, 2009 3:40 PM
To: Henry Sinnreich
Cc: longbwe longbwe; Wang, Sherry; p2psip= @ietf.org
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 ma= naged
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" <hsinnrei@adobe.com> escribió:
Please help me understand the technical (not marketing) meaning of mo= bile
p2p.
Mobility is inherent on the Internet and can be implemented in severa= l ways.

Or are you referring to to mobile phones not connected to the Interne= t?
Where is the protocol capability difference between a laptop, a netbo= ok and
a smart phone?

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

Henry

On 2/7/09 2:57 AM, "longbwe longbwe" <longbwee@gmail.com> wrote:
Sheery,

Thanks very much for your reply.Maybe it is a little early to set a s= eperate
WG for Mobile P2P, I am wondering whether the work of P2PSip ca= n be
extensible to wireless scenarios, e.g. its architecture.Mobility mana= gement
is certainly one of our interested fields, which also include the net= work
topology, architecture, peer protocol, private issue, security and so= on.We
would like to discuss one or more such related topics with you and an= y one
else. The underlying fact is that with the issue of 3G li= sences in China
and emergence of more and more cell phone applications, our team thin= k we
should do some work to extend the P2P technic from PC to mobile devic= es.

Best wishes,
Bin Long

On Sat, Feb 7, 2009 at 12:40 AM, Wang, Sherry <Sherry.Wang@jhuapl.edu>
wrote:
Bin,

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

Thanks,
Sherry Wang
________________________________________
From: p2psip-bounces@ietf.org= [mailto:p2psip-bounces@ietf.org= ] On Behalf Of
longbwe longbwe
Sent: Friday, February 06, 2009 1:39 AM
To: p2psip@ietf.org
Subject: [P2PSIP] mobile p2p in p2psip

Hi all,
We want to know if mobile p2p can be discussed in this WG, or the p2p= sip 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 al= so
research on it.
Any feedback is appreciated!
Best Regards,
Bin Long

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.= ietf.org/mailman/listinfo/p2psip

P2PSIP@ietf.org
https://www.ietf.o= rg/mailman/listinfo/p2psip

---
Prof. Dr. Kurt Tutschku
Chair of Future Communication (Endowed by Telekom Austria)
Institute of Distributed and Multimedia Systems, Faculty of Computer Scienc= e
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:kurt.tutschku@univie.a= c.at or mailto:kurttutschku@g= mail.com

--_000_C5B5C836B471hsinnreiadobecom_-- From hsinnrei@adobe.com Mon Feb 9 09:50:30 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19CB33A67D4 for ; Mon, 9 Feb 2009 09:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[AWL=-1.055, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2ZBnSRIhvjl for ; Mon, 9 Feb 2009 09:50:22 -0800 (PST) Received: from psmtp.com (exprod6ob113.obsmtp.com [64.18.1.30]) by core3.amsl.com (Postfix) with ESMTP id C9AEF3A6944 for ; Mon, 9 Feb 2009 09:50:21 -0800 (PST) Received: from source ([192.150.11.134]) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKSZBs4LU2h9wYgKl04tiKVcsKZmB4tPqY@postini.com; Mon, 09 Feb 2009 09:50:24 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n19GBeeM013537; Mon, 9 Feb 2009 08:11:40 -0800 (PST) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n19GGoiq008089; Mon, 9 Feb 2009 08:16:50 -0800 (PST) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Mon, 9 Feb 2009 08:16:50 -0800 From: Henry Sinnreich To: =?iso-8859-1?Q?David_Artu=F1edo_Guill=E9n?= , =?iso-8859-1?Q?Victor_Pascual_=C1vila?= Date: Mon, 9 Feb 2009 08:16:48 -0800 Thread-Topic: [P2PSIP] mobile p2p in p2psip Thread-Index: AcmKiaz2weRjgudzS9eFn+7ychuCJgASCHkR Message-ID: In-Reply-To: <792337B2-9D67-4BD7-A4A1-A052B205829B@tid.es> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C5B5B310B461hsinnreiadobecom_" MIME-Version: 1.0 Cc: longbwe longbwe , "Wang, Sherry" , "p2psip@ietf.org" Subject: Re: [P2PSIP] mobile p2p in p2psip X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:50:30 -0000 --_000_C5B5B310B461hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >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 ha= ve 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", It was preceded and followed by many discussions on this topic, such as tha= t frequent p2p protocol messages for peer nodes will quickly exhaust the ba= ttery. Victor: What has happened to the I-D on p2p clients? 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-S= IP applications, the above protocol work also applies quite well, as the th= e 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=F1edo Guill=E9n" wrote: Henry, I guess it is related to the fact that in mobility your device gets differe= nt IPs in short periods of time. Frecuent changes has to be managed in orde= r to route messages efficiently. It is not the same as churn, but it introd= uces similar challenges, IMHO. BR Enviado desde mi iPhone El 08/02/2009, a las 21:22, "Henry Sinnreich" escribi= =F3: Please help me understand the technical (not marketing) meaning of mobile p= 2p. 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, unl= ess we talk about some closed network, and please tell me why would I buy i= t? Henry On 2/7/09 2:57 AM, "longbwe longbwe" > wrote: Sheery, Thanks very much for your reply.Maybe it is a little early to set a seperat= e WG for Mobile P2P, I am wondering whether the work of P2PSip can be exte= nsible to wireless scenarios, e.g. its architecture.Mobility management is = certainly one of our interested fields, which also include the network topo= logy, architecture, peer protocol, private issue, security and so on.We wou= ld like to discuss one or more such related topics with you and any one els= e. 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 shou= ld 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 > wrote: Bin, It's out of question that we should do it. I have seen mobile P2P researche= s and discussions existing for a while. Should we have a separate WG becaus= e 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: p2psip-bounces@ietf.org [mailto:p2p= sip-bounces@ietf.org ] On Behalf Of longbw= e longbwe Sent: Friday, February 06, 2009 1:39 AM To: p2psip@ietf.org 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 m= obile p2p now and wish to do some communication with the ones who also rese= arch on it. Any feedback is appreciated! Best Regards, Bin Long _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip --_000_C5B5B310B461hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [P2PSIP] mobile p2p in p2psip >Frequent changes has to be managed in order to route messages eff= iciently.
>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 ha= ve 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, "P= 2PSIP Clients",
<draft-pascual-p2psip-clients>

It was preceded and followed by many discussions on this topic, such as tha= t frequent p2p protocol messages for peer nodes will quickly exhaust the ba= ttery.

Victor: What has happened to the I-D on p2p clients?

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 me= ssages on behalf of other
      hosts as required by the Overlay Algori= thm.

   Client: A host that is able to store data in and re= trieve data from
      the overlay but which is not participat= ing 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 wel= l, as the the Reload authors have said.

Please let us know if the above definitions meet your requirements or not.<= BR>
Henry

On 2/9/09 1:40 AM, "David Artuñedo Guillén" <dag@tid.es> wrote:

Henry,

I guess it is related to the fact that in mobility your device gets differe= nt IPs in short periods of time. Frecuent changes has to be managed in orde= r to route messages efficiently. It is not the same as churn, but it introd= uces similar challenges, IMHO.

BR

Enviado desde mi iPhone

El 08/02/2009, a las 21:22, "Henry Sinnreich" <hsinnrei@adobe.com> escribió:

Please help me understand the technical (no= t 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, unl= ess we talk about some closed network, and please tell me why would I buy i= t?

Henry

On 2/7/09 2:57 AM, "longbwe longbwe" <longbwee@gmail.com <mai= lto:longbwee@gmail.com> > wrote:

Sheery,

Thanks very much for your reply.Maybe it is a little early to set a seperat= e WG for Mobile P2P, I am wondering whether the work of P2PSip can be= extensible to wireless scenarios, e.g. its architecture.Mobility managemen= t is certainly one of our interested fields, which also include the network= topology, architecture, peer protocol, private issue, security and so on.W= e would like to discuss one or more such related topics with you and any on= e else. The underlying fact is that with the issue of 3G lisenc= es in China and emergence of more and more cell phone applications, our tea= m 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 <Sherry.Wang@jhuapl.edu <mailto:Sherry.Wang@jhuapl.edu> > wrote:

Bin,

It's out of question th= at we should do it. I have seen mobile P2P researches and discussions exist= ing for a while. Should we have a separate WG because of its technical sign= ificance and complexity, I am not sure. Important is that we need to work o= n it. Are you interested in mobility management only, e.g. handover, or mor= e?

Thanks,
Sherry Wang

From: = p2psip-bounces@ietf.org <= mailto:p2psip-bounces@ietf.org> [mailto:p2psip-bounces@ietf.org <mailto:p2psip-bounces@ietf.org> ] On Behalf = Of longbwe longbwe
Sent: Friday, February 06, 2009 1:39 AM
To: p2psip@ietf.org <mailto:p2psip@ietf.org>
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 m= obile p2p now and wish to do some communication with the ones who also rese= arch on it.
Any feedback is appreciated!
Best Regards,
Bin Long

__________________________________________= _____
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.o= rg/mailman/listinfo/p2psip

--_000_C5B5B310B461hsinnreiadobecom_-- From melodysong@huawei.com Mon Feb 9 17:53:46 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 820973A67A1 for ; Mon, 9 Feb 2009 17:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sonD5wHyJfSe for ; Mon, 9 Feb 2009 17:53:45 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id ABD123A6D56 for ; Mon, 9 Feb 2009 17:53:45 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KET003JLULM3W@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 10 Feb 2009 09:53:46 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KET00IRHULMZS@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 10 Feb 2009 09:53:46 +0800 (CST) Received: from s64081 ([10.164.12.16]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KET00AJTULLJB@szxml05-in.huawei.com> for p2psip@ietf.org; Tue, 10 Feb 2009 09:53:46 +0800 (CST) Date: Tue, 10 Feb 2009 09:53:44 +0800 From: Song Haibin In-reply-to: To: 'Henry Sinnreich' , =?ISO-8859-1?Q?'David_Artu=3Fedo_Guill=E9n'?= , =?ISO-8859-1?Q?'Victor_Pascual_=E1vila'?= Message-id: <009401c98b22$687903c0$100ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Thread-index: AcmKiaz2weRjgudzS9eFn+7ychuCJgASCHkRABNHV1A= Cc: 'longbwe longbwe' , "'Wang, Sherry'" , p2psip@ietf.org Subject: Re: [P2PSIP] mobile p2p in p2psip X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 01:53:46 -0000 Hi Henry and Bin, >>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", > >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 hsinnrei@adobe.com Mon Feb 9 20:18:07 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3FF73A67DD for ; Mon, 9 Feb 2009 20:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.939 X-Spam-Level: X-Spam-Status: No, score=-5.939 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9a6T7d6oBbfF for ; Mon, 9 Feb 2009 20:18:06 -0800 (PST) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by core3.amsl.com (Postfix) with ESMTP id F09C93A68EB for ; Mon, 9 Feb 2009 20:17:51 -0800 (PST) Received: from source ([192.150.8.22]) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKSZD/4uOJTYv+XcUryNGqEUJOHzHtDd0h@postini.com; Mon, 09 Feb 2009 20:18:09 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n1A4HXE0011637; Mon, 9 Feb 2009 20:17:33 -0800 (PST) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n1A4HPY4000571; Mon, 9 Feb 2009 20:17:30 -0800 (PST) Received: from fe01.corp.adobe.com (10.8.192.82) by nacas01.corp.adobe.com (10.8.189.99) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 9 Feb 2009 20:17:26 -0800 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by fe01.corp.adobe.com ([10.8.192.82]) with mapi; Mon, 9 Feb 2009 20:17:26 -0800 From: Henry Sinnreich To: Song Haibin , =?iso-8859-1?Q?David_Artu=3Fedo_Guill=E9n?= , =?iso-8859-1?Q?Victor_Pascual_=E1vila?= Date: Mon, 9 Feb 2009 20:17:23 -0800 Thread-Topic: [P2PSIP] mobile p2p in p2psip Thread-Index: AcmKiaz2weRjgudzS9eFn+7ychuCJgASCHkRABNHV1AABeMtSA== Message-ID: In-Reply-To: <009401c98b22$687903c0$100ca40a@china.huawei.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C5B65BF3B4BChsinnreiadobecom_" MIME-Version: 1.0 Cc: longbwe longbwe , "Wang, Sherry" , "p2psip@ietf.org" Subject: Re: [P2PSIP] mobile p2p in p2psip X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 04:18:08 -0000 --_000_C5B65BF3B4BChsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 acce= ss to the SIP network is not possible, but the mobile devices could still c= ommunicate 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" wrote: Hi Henry and Bin, >>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, "P2PSI= P >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 th= e >battery. As the co-author of this I-D (use my previous name Song Yongchao), I suppor= t that the mobile devices should be better to act as clients rather than peer= s whenever possible. But I guess there are scenarios where only mobile device= s 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 --_000_C5B65BF3B4BChsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [P2PSIP] mobile p2p in p2psip 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 acce= ss to the SIP network is not possible, but the mobile devices could still c= ommunicate on the same L2 radio network, say on the same WiFi network.
One approach is described here and it does not require p2p:

http://t= ools.ietf.org/html/draft-lee-sip-dns-sd-uri-00

Henry

On 2/9/09 7:53 PM, "Song Haibin" <melodysong@huawei.com> wrote:

Hi Henry and Bin,
>>Frequent changes has to be managed in order to route messages effic= iently.

>>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, &qu= ot;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.

As the co-author of this I-D (use my previous name Song Yongchao), I suppor= t
that the mobile devices should be better to act as clients rather than peer= s
whenever possible. But I guess there are scenarios where only mobile device= s
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

--_000_C5B65BF3B4BChsinnreiadobecom_-- From lin.xiao@nsn.com Mon Feb 9 21:41:19 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4D33A6C2E for ; Mon, 9 Feb 2009 21:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.815 X-Spam-Level: X-Spam-Status: No, score=-4.815 tagged_above=-999 required=5 tests=[AWL=0.884, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6xp7fAB3l+g for ; Mon, 9 Feb 2009 21:41:18 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 314DF3A6897 for ; Mon, 9 Feb 2009 21:41:18 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1A5etk4002703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Feb 2009 06:40:55 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1A5es5A023014; Tue, 10 Feb 2009 06:40:55 +0100 Received: from CNBEEXC006.nsn-intra.net ([10.159.192.11]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Feb 2009 06:40:54 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Feb 2009 13:40:50 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <19E513F61FD3DB47A847097F8AD7128A8EF68A@CNBEEXC006.nsn-intra.net> In-Reply-To: <009401c98b22$687903c0$100ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] mobile p2p in p2psip Thread-Index: AcmKiaz2weRjgudzS9eFn+7ychuCJgASCHkRABNHV1AABCIoEA== References: <009401c98b22$687903c0$100ca40a@china.huawei.com> From: "Xiao, Lin (NSN - CN/Beijing)" To: "ext Song Haibin" , "Henry Sinnreich" , =?iso-8859-1?Q?David_Artu=3Fedo_Guill=E9n?= , =?iso-8859-1?Q?Victor_Pascual_=E1vila?= X-OriginalArrivalTime: 10 Feb 2009 05:40:54.0336 (UTC) FILETIME=[23E93C00:01C98B42] Cc: longbwe longbwe , "Wang, Sherry" , p2psip@ietf.org Subject: Re: [P2PSIP] mobile p2p in p2psip X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 05:41:19 -0000 =20 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.=20 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.=20 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.=20 Xiao Lin -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf = Of ext Song Haibin Sent: Tuesday, February 10, 2009 9:54 AM To: 'Henry Sinnreich'; 'David Artu?edo Guill=E9n'; 'Victor Pascual = =E1vila' Cc: 'longbwe longbwe'; 'Wang,Sherry'; p2psip@ietf.org Subject: Re: [P2PSIP] mobile p2p in p2psip Hi Henry and Bin, >>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.=20 >>This makes sense and is the reason the present work in the P2P SIP WG=20 >>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,=20 >"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. 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 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 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From saumitra@qualcomm.com Mon Feb 9 22:55:07 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ED2F3A6BEC for ; Mon, 9 Feb 2009 22:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.235 X-Spam-Level: X-Spam-Status: No, score=-105.235 tagged_above=-999 required=5 tests=[AWL=0.764, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oh9tcq2itnQG for ; Mon, 9 Feb 2009 22:55:06 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id D50D03A6BCF for ; Mon, 9 Feb 2009 22:55:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1234248909; x=1265784909; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20"p2psip@ietf.org"=20|Date:=20Mon,=209 =20Feb=202009=2022:55:06=20-0800|Subject:=20RE:=20[P2PSIP ]=20mobile=20p2p=20in=20p2psip|Thread-Topic:=20[P2PSIP] =20mobile=20p2p=20in=20p2psip|Thread-Index:=20AcmKiaz2weR jgudzS9eFn+7ychuCJgASCHkRABNHV1AABCIoEAAHHwmA|Message-ID: =20<2D06DE445C2ADE44890118C3F449B9633FED23A8@NASANEXMB12. na.qualcomm.com>|References:=20=0D=0A=09<009401c98b22$687903c0$100ca40a@china.hu awei.com>=0D=0A=20<19E513F61FD3DB47A847097F8AD7128A8EF68A @CNBEEXC006.nsn-intra.net>|In-Reply-To:=20<19E513F61FD3DB 47A847097F8AD7128A8EF68A@CNBEEXC006.nsn-intra.net> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5521"=3B=20a=3D"15370961"; bh=c7lFfc1O6mEM9Dgy/fvcMUFdSL/ferdXicko3kl10Ss=; b=ru3AgEM+rUdaY6pluXxnSE/PlJ0d7opPHEAdKD0uK54zvisCmTysnwCC WIygeqjymutxZj9vHNJ82ZY9ivI4+WAULHLXvTi0TLM4gsv9SbHq4NBU4 kDf4XFKq8zZjPxwic+lspLGidilGN0B9njFvD6TbOPD1s9+gA2eys4LB/ U=; X-IronPort-AV: E=McAfee;i="5300,2777,5521"; a="15370961" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2009 22:55:08 -0800 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1A6t8kZ022653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 9 Feb 2009 22:55:08 -0800 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1A6t7aY000150 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 9 Feb 2009 22:55:08 -0800 (PST) Received: from NASANEXMB12.na.qualcomm.com ([10.45.78.34]) by nasanexhub06.na.qualcomm.com ([129.46.134.254]) with mapi; Mon, 9 Feb 2009 22:55:07 -0800 From: "Das, Saumitra" To: "p2psip@ietf.org" Date: Mon, 9 Feb 2009 22:55:06 -0800 Thread-Topic: [P2PSIP] mobile p2p in p2psip Thread-Index: AcmKiaz2weRjgudzS9eFn+7ychuCJgASCHkRABNHV1AABCIoEAAHHwmA Message-ID: <2D06DE445C2ADE44890118C3F449B9633FED23A8@NASANEXMB12.na.qualcomm.com> References: <009401c98b22$687903c0$100ca40a@china.huawei.com> <19E513F61FD3DB47A847097F8AD7128A8EF68A@CNBEEXC006.nsn-intra.net> In-Reply-To: <19E513F61FD3DB47A847097F8AD7128A8EF68A@CNBEEXC006.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [P2PSIP] mobile p2p in p2psip X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 06:55:07 -0000 Handling mobile nodes can be done in the framework of the base draft. For e= xample, the DHT protocol itself can be different if=20 the operating conditions are such that there is a lot of moiblity. There ar= e several proposals for DHTs to operate efficiently on highly mobile networks such as MANETs. These should be doable under the pluggabili= ty 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 exc= essive 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: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] 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=E9n; Victor Pasc= ual =E1vila Cc: longbwe longbwe; Wang, Sherry; p2psip@ietf.org Subject: Re: [P2PSIP] mobile p2p in p2psip =20 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.=20 Mobility could bring disconnection and reconnection which changes the topol= ogy structure of a P2P overlay. Different influences are given to peers and= clients. Clients only need to reconnect with overlay simply, while peers n= eed do data migration and even more before changing connection. There is no= point to ask client to install a same complex protocol with peer, especial= ly in mobility scenario. Moreover, the frequent moving of peers could be a = disaster for structured overlay. Therefore, it is necessary to tell which k= ind of devices could perform as peer and which should work as clients.=20 Besides the peer/client definition mentioned in Reload base, the mobility c= haracter should also be considered to separate them. In my opinion, there c= ould 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 candid= ates for peers of overlay, while mobile handsets should be limited in clien= t status considering not only their limited capability and resources but al= so 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 wor= k only as clients, can not cause churn of the overlay topology structure. I= t seems that we'd better consider the client mobility and peer mobility sep= arately to describe their behavior and to develop their protocols more clea= rly.=20 Xiao Lin -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of= ext Song Haibin Sent: Tuesday, February 10, 2009 9:54 AM To: 'Henry Sinnreich'; 'David Artu?edo Guill=E9n'; 'Victor Pascual =E1vila' Cc: 'longbwe longbwe'; 'Wang,Sherry'; p2psip@ietf.org Subject: Re: [P2PSIP] mobile p2p in p2psip Hi Henry and Bin, >>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.= =20 >>This makes sense and is the reason the present work in the P2P SIP WG=20 >>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,=20 >"P2PSIP Clients", >It was preceded and followed by many discussions on this topic, such as=20 >that frequent p2p protocol messages for peer nodes will quickly exhaust=20 >the battery. As the co-author of this I-D (use my previous name Song Yongchao), I suppor= t that the mobile devices should be better to act as clients rather than pe= ers whenever possible. But I guess there are scenarios where only mobile de= vices 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 Just to be clear, clients are a fully integrated component of the base relo= ad protocol. Motivation for them and some discussion of related issues is = in the p2psip-base appendix (and a much more extensive discussion in pascua= l-clients and others), but the actual mechanisms to support them should alr= eady be in the base draft. Discussion of further work identifying when a node should be a peer and whe= n 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 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From saumitra@qualcomm.com Mon Feb 9 22:57:02 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B990B3A67E1 for ; Mon, 9 Feb 2009 22:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.611 X-Spam-Level: X-Spam-Status: No, score=-103.611 tagged_above=-999 required=5 tests=[AWL=-1.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2zgjhypDw0Z for ; Mon, 9 Feb 2009 22:57:02 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 07F963A67C0 for ; Mon, 9 Feb 2009 22:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1234249025; x=1265785025; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20jiangxingfeng=20,=20"p2psip@ietf .org"=20|Date:=20Mon,=209=20Feb=202009 =2022:57:03=20-0800|Subject:=20RE:=20[P2PSIP]=20FIND=20re quest|Thread-Topic:=20[P2PSIP]=20FIND=20request |Thread-Index:=20AcmDC7DNUPSKFaWVTw6Jr+EPpkbyYQHVlz5QADqe BzA=3D|Message-ID:=20<2D06DE445C2ADE44890118C3F449B9633FE D23A9@NASANEXMB12.na.qualcomm.com>|References:=20<2D06DE4 45C2ADE44890118C3F449B9633FED1DAA@NASANEXMB12.na.qualcomm .com>=0D=0A=20<00c901c98a62$73461290$170ca40a@china.huawe i.com>|In-Reply-To:=20<00c901c98a62$73461290$170ca40a@chi na.huawei.com>|Accept-Language:=20en-US|Content-Language: =20en-US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"utf-8"|Content-Transfer-Encoding:=20base64 |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5521"=3B=20a=3D"15351854"; bh=XBzwuYWRq90KVZTJWM9iRs5GKCzV9982xdDDMYRgC/4=; b=ktfIBSgStSM+jiRS2rWzRjLsDkR2an96fijfD8PdCA/GqoPti6GNH3eK 9f21rXoiTCFmIRPL3cws+dwn7abDInJPcTxNYS5FbXrVb/tWTuDGexA/t hXV1eSbvD42zmlIXL4kjQ37emQnpt7OB03W9iRJ8XV1FaP7uI2m0v/53L I=; X-IronPort-AV: E=McAfee;i="5100,188,5521"; a="15351854" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2009 22:57:04 -0800 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1A6v41e024142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Feb 2009 22:57:04 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1A6v4QT000742 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Feb 2009 22:57:04 -0800 (PST) Received: from NASANEXMB12.na.qualcomm.com ([10.45.78.34]) by nasanexhub01.na.qualcomm.com ([10.46.93.121]) with mapi; Mon, 9 Feb 2009 22:57:03 -0800 From: "Das, Saumitra" To: jiangxingfeng , "p2psip@ietf.org" Date: Mon, 9 Feb 2009 22:57:03 -0800 Thread-Topic: [P2PSIP] FIND request Thread-Index: AcmDC7DNUPSKFaWVTw6Jr+EPpkbyYQHVlz5QADqeBzA= Message-ID: <2D06DE445C2ADE44890118C3F449B9633FED23A9@NASANEXMB12.na.qualcomm.com> References: <2D06DE445C2ADE44890118C3F449B9633FED1DAA@NASANEXMB12.na.qualcomm.com> <00c901c98a62$73461290$170ca40a@china.huawei.com> In-Reply-To: <00c901c98a62$73461290$170ca40a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [P2PSIP] FIND request X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 06:57:02 -0000 SXQgc2VlbXMgdG9vIHNwZWNpZmljIHRvIGJlIGluIHRoZXJlIGp1c3QgZm9yIHRoZSBUVVJOIHNl cnZlciBkaXNjb3ZlcnkgaW4gdGhhdCBjYXNlLiBUaGVyZSBzaG91bGQgYmUgYSBnZW5lcmFsIA0K a2V5LWxvb2t1cCBiYXNlZCBzY2hlbWUgdGhhdCB0aGUgYmFzZSBkcmFmdCBwcm92aWRlcy4NCg0K T3RoZXIgZW5oYW5jZW1lbnRzIHByb2JhYmx5IGJlbG9uZyBpbiBhIGRpZmZlcmVudCBkcmFmdCB0 aGF0IGxvb2tzIGF0IGVuaGFuY2VkIHNlcnZpY2UgZGlzY292ZXJ5IGJ1aWxkaW5nIG9uIHRoZSBr ZXkgbG9va3VwLg0KDQpCZXN0DQpTYXVtaXRyYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogamlhbmd4aW5nZmVuZyBbbWFpbHRvOmppYW5nLnguZkBodWF3ZWkuY29tXSANClNl bnQ6IFN1bmRheSwgRmVicnVhcnkgMDgsIDIwMDkgNzowMCBQTQ0KVG86IERhcywgU2F1bWl0cmE7 IHAycHNpcEBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtQMlBTSVBdIEZJTkQgcmVxdWVzdA0KDQo+ IA0KPiBJIHdhcyB3b25kZXJpbmcgaWYgc29tZW9uZSBjb3VsZCBlbGFib3JhdGUgb24gdGhlIHVz ZSBjYXNlIGZvciB0aGUgRklORCByZXF1ZXN0Lg0KPiBJIGFtIG5vdCBzdXJlIHdoYXQgaXQgaXMg YmVpbmcgdXNlZCBmb3IgZXhhY3RseS4NCg0KSSB0aGluayBpdCdzIHJlbGF0ZWQgdG8gVFVSTiBz ZXJ2ZXIgZGlzY292ZXJ5IHByb2NlZHVyZS4gDQo+IA0KPiBBIGdlbmVyaWMgc2VhcmNoIG1lY2hh bmlzbSBtYXkgYmUgaW1wbGVtZW50ZWQgb24gdG9wIG9mIHRoZSBESFQgd2hpY2ggbWF5IGhhdmUN Cj4gc3VjaCBpbmRleGluZyBjYXBhYmlsaXRpZXMNCj4gYW5kIGRvZXNuJ3QgbmVlZCB0byBiZSBz cGVjaWZpZWQgaW4gdGhlIGRyYWZ0Lg0KDQpJIGFncmVlLiBJIHRoaW5rIHNlcnZpY2UgZGlzY292 ZXJ5IHNob3VsZCBiZSBleHRyYWN0ZWQgZnJvbSB0aGUgYmFzZSBkcmFmdC4gV2UgbmVlZCBhIGdl bmVyaWMgc2VydmljZSBkaXNjb3ZlcnkgbWVjaGFuaXNtIGJlY2F1c2UgcDJwIHN5c3RlbSBpcyBh IGNvbGxhYm9yYXRpbmcgc3lzdGVtLiANCg0KLS0NCkppYW5nIFhpbmdGZW5nDQoNCg0K From longbwee@gmail.com Tue Feb 10 00:41:13 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5D373A6A2D for ; Tue, 10 Feb 2009 00:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.934 X-Spam-Level: X-Spam-Status: No, score=-0.934 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPQAIiYGuuKs for ; Tue, 10 Feb 2009 00:41:12 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by core3.amsl.com (Postfix) with ESMTP id 6F89F3A68DF for ; Tue, 10 Feb 2009 00:41:12 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id m33so1380976wag.5 for ; Tue, 10 Feb 2009 00:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=kRzjyYt7ML6qfW5Pg4pT+RdAx7WKYE91Y33rk3SJOtg=; b=rvVi3oe5XMCDgmVBRQaPIIip7O3684/jD5sRmzxUVwYh2jOMnAvBFmrs11FQ1EytIc C0RuLtyv5ToPY9OiL458p9iHeQ4+Sq32wtjcvD5NGRkPLhA5nU20+yXynDiZSExGhzxY z+4eoRcKGuGK5+R64Zos+tW6uZMADSb2ZGgho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ROqBklh+DQXKr+5CPcq7tVycRWO4Z6L+joCs1v4BllPWTq+PBL3FgoLyKwcN1lHpaN AJJye5Q2LY6K2txeo1NNxnW72NU2eOhMX8+iHSjMueZN5KfA2w3+tDIIopzVmiYSqBZl wjYtYtw0J/hSYlqtANzBZnjZa9yrkw7xkX2/Q= MIME-Version: 1.0 Received: by 10.114.148.19 with SMTP id v19mr4310767wad.71.1234255274823; Tue, 10 Feb 2009 00:41:14 -0800 (PST) In-Reply-To: <19E513F61FD3DB47A847097F8AD7128A8EF68A@CNBEEXC006.nsn-intra.net> References: <009401c98b22$687903c0$100ca40a@china.huawei.com> <19E513F61FD3DB47A847097F8AD7128A8EF68A@CNBEEXC006.nsn-intra.net> Date: Tue, 10 Feb 2009 16:41:14 +0800 Message-ID: From: longbwe longbwe To: "Xiao, Lin (NSN - CN/Beijing)" Content-Type: multipart/alternative; boundary=00163645884037cfed04628c7355 Cc: "Wang, Sherry" , p2psip@ietf.org, Henry Sinnreich Subject: Re: [P2PSIP] mobile p2p in p2psip X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 08:41:13 -0000 --00163645884037cfed04628c7355 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 int= o 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) < lin.xiao@nsn.com> wrote: > > Hi Bruce and Haibin: > > I totally agree with you to further consider the mobility behavior togeth= er > 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 pe= ers > and clients. Clients only need to reconnect with overlay simply, while pe= ers > 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, especia= lly > 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, ther= e > 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 pee= rs > for data storage and message routing. The highly mobility nodes, which wo= rk > only as clients, can not cause churn of the overlay topology structure. I= t > 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: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf > Of ext Song Haibin > Sent: Tuesday, February 10, 2009 9:54 AM > To: 'Henry Sinnreich'; 'David Artu?edo Guill=E9n'; 'Victor Pascual =E1vil= a' > Cc: 'longbwe longbwe'; 'Wang,Sherry'; p2psip@ietf.org > Subject: Re: [P2PSIP] mobile p2p in p2psip > > Hi Henry and Bin, > >>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", > > >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 b= e > given to the mobility of a "peer". > > Bin, I don't know if this is what you concern about. > > 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 issu= es > 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 furthe= r > work in new drafts, of course. > > Bruce > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > --00163645884037cfed04628c7355 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 d= evided into three categories:fixed,mobile and mixed, with the preferences t= hat fixed nodes act peers and mobile nodes act clients.What if most nodes o= f the overlay are mobile and there are not enough fixed nodes running as pe= ers?This is certainly becoming the case,with the emergences of more powerfu= l and smarter mobile devices such as iPhone and GPhone, cell phones are fun= ctioning more like a small PC and young people will prefer their mobile pho= nes to laptops.
I also appreciate there could be a dynamic role transferring mechanism betw= een 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) <lin.xiao@nsn.com> 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 topol= ogy structure of a P2P overlay. Different influences are given to peers and= clients. Clients only need to reconnect with overlay simply, while peers n= eed do data migration and even more before changing connection. There is no= point to ask client to install a same complex protocol with peer, especial= ly in mobility scenario. Moreover, the frequent moving of peers could be a = disaster for structured overlay. Therefore, it is necessary to tell which k= ind of devices could perform as peer and which should work as clients.

Besides the peer/client definition mentioned in Reload base, the mobility c= haracter should also be considered to separate them. In my opinion, there c= ould 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 candid= ates for peers of overlay, while mobile handsets should be limited in clien= t status considering not only their limited capability and resources but al= so 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 wor= k only as clients, can not cause churn of the overlay topology structure. I= t 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: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.or= g] On Behalf Of ext Song Haibin
Sent: Tuesday, February 10, 2009 9:54 AM
To: 'Henry Sinnreich'; 'David Artu?edo Guill=E9n'; 'Vic= tor Pascual =E1vila'
Cc: 'longbwe longbwe'; 'Wang,Sherry'; p2psip@ietf.org

Subject: Re: [P2PSIP] mobile p2= p in p2psip

Hi Henry and Bin,
>>Frequent changes has to be managed in order to route messages effic= iently.

>>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.

As the co-author of this I-D (use my previous name Song Yongchao), I suppor= t that the mobile devices should be better to act as clients rather than pe= ers whenever possible. But I guess there are scenarios where only mobile de= vices 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

Just to be clear, clients are a fully int= egrated component of the base reload protocol. Motivation for them an= d some discussion of related issues is in the p2psip-base appendix (and a m= uch more extensive discussion in pascual-clients and others), but the actua= l mechanisms to support them should already be in the base draft.

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

Bruce

_______________________________= ________________
P2PSIP mailing list
P2PSIP@ietf.org
= https://www.ietf.org/mailman/listinfo/p2psip

--00163645884037cfed04628c7355-- From lin.xiao@nsn.com Tue Feb 10 01:09:05 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CFDD28C104 for ; Tue, 10 Feb 2009 01:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=-1.187, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U5tCK4xY2t8 for ; Tue, 10 Feb 2009 01:09:04 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id F2A963A6BCF for ; Tue, 10 Feb 2009 01:09:03 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1A9946Q008027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Feb 2009 10:09:04 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1A994rH020068; Tue, 10 Feb 2009 10:09:04 +0100 Received: from CNBEEXC006.nsn-intra.net ([10.159.192.11]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Feb 2009 10:09:03 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 10 Feb 2009 17:09:00 +0800 Message-ID: <19E513F61FD3DB47A847097F8AD7128A91C7E4@CNBEEXC006.nsn-intra.net> In-Reply-To: <2D06DE445C2ADE44890118C3F449B9633FED23A8@NASANEXMB12.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] mobile p2p in p2psip Thread-Index: AcmKiaz2weRjgudzS9eFn+7ychuCJgASCHkRABNHV1AABCIoEAAHHwmAAAO80pA= References: <009401c98b22$687903c0$100ca40a@china.huawei.com><19E513F61FD3DB47A847097F8AD7128A8EF68A@CNBEEXC006.nsn-intra.net> <2D06DE445C2ADE44890118C3F449B9633FED23A8@NASANEXMB12.na.qualcomm.com> From: "Xiao, Lin (NSN - CN/Beijing)" To: "ext Das, Saumitra" , X-OriginalArrivalTime: 10 Feb 2009 09:09:03.0187 (UTC) FILETIME=[37D8AA30:01C98B5F] Subject: Re: [P2PSIP] mobile p2p in p2psip X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 09:09:05 -0000 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: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf = Of ext Das, Saumitra Sent: Tuesday, February 10, 2009 2:55 PM To: p2psip@ietf.org 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. New draft could focus on best practices or results on such choices. Best Saumitra -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] 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=E9n; Victor = Pascual =E1vila Cc: longbwe longbwe; Wang, Sherry; p2psip@ietf.org Subject: Re: [P2PSIP] mobile p2p in p2psip =20 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.=20 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.=20 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.=20 Xiao Lin -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf = Of ext Song Haibin Sent: Tuesday, February 10, 2009 9:54 AM To: 'Henry Sinnreich'; 'David Artu?edo Guill=E9n'; 'Victor Pascual = =E1vila' Cc: 'longbwe longbwe'; 'Wang,Sherry'; p2psip@ietf.org Subject: Re: [P2PSIP] mobile p2p in p2psip Hi Henry and Bin, >>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.=20 >>This makes sense and is the reason the present work in the P2P SIP WG=20 >>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,=20 >"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. 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 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 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From dyork@voxeo.com Tue Feb 10 03:01:47 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5593A68C4 for ; Tue, 10 Feb 2009 03:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBSR4-OclsKE for ; Tue, 10 Feb 2009 03:01:46 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id 150A33A689E for ; Tue, 10 Feb 2009 03:01:45 -0800 (PST) Received: from 160.sub-72-127-246.myvzw.com (account dyork [72.127.246.160] verified) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 38967499; Tue, 10 Feb 2009 11:01:46 +0000 Message-Id: From: Dan York To: "Das, Saumitra" In-Reply-To: <2D06DE445C2ADE44890118C3F449B9633FED23A8@NASANEXMB12.na.qualcomm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Feb 2009 06:01:43 -0500 References: <009401c98b22$687903c0$100ca40a@china.huawei.com> <19E513F61FD3DB47A847097F8AD7128A8EF68A@CNBEEXC006.nsn-intra.net> <2D06DE445C2ADE44890118C3F449B9633FED23A8@NASANEXMB12.na.qualcomm.com> X-Mailer: Apple Mail (2.930.3) Cc: "p2psip@ietf.org" Subject: [P2PSIP] Interoperability vs Pluggability (was Re: mobile p2p in p2psip) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 11:01:47 -0000 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 > mobile networks such as MANETs. These should be doable under the > pluggability principle of RELOAD. 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 dyork@voxeo.com 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.avila@gmail.com Tue Feb 10 04:18:21 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73FF328C16A for ; Tue, 10 Feb 2009 04:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeBGbwvkprXb for ; Tue, 10 Feb 2009 04:18:20 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id 1C9F328C0F7 for ; Tue, 10 Feb 2009 04:18:19 -0800 (PST) Received: by ewy14 with SMTP id 14so3042957ewy.13 for ; Tue, 10 Feb 2009 04:18:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FS2u1zaGUbInLf9gVUZ+ydKSirFKmY8Vu33/erfh+8U=; b=GppzlEg5YEj6mO1obFnULGHwtbDG+3874PwWBveZXmmFHWwFRhHfPLSGGETb/efkTG tkPU3nv6vpstHEfIFgtSfTJ0y0I/xMPIWm93H+a1R6JZ663tnnOoFK1m/CNCySUm44VU Cb8L1BG+xQrxMeiGpzmj2YBYKJkV8zoIF6L/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aAhCKhnWpinm4hcG59BDiafOxigzgTIFjKIi7E914tuJtM11mLQZ0Wg22XiKnlZ4xX 3ZSB9nmq2TDDL4a63Z1G553I5TdoNvttH200iAd0g09KadrPima50ZGeha7nweeK9xaq y08TvbYhifCc+ijdI8VsyYHWwA7fJcUwymnsw= MIME-Version: 1.0 Received: by 10.210.111.17 with SMTP id j17mr1925846ebc.9.1234268301522; Tue, 10 Feb 2009 04:18:21 -0800 (PST) In-Reply-To: References: <009401c98b22$687903c0$100ca40a@china.huawei.com> <19E513F61FD3DB47A847097F8AD7128A8EF68A@CNBEEXC006.nsn-intra.net> <2D06DE445C2ADE44890118C3F449B9633FED23A8@NASANEXMB12.na.qualcomm.com> Date: Tue, 10 Feb 2009 13:18:21 +0100 Message-ID: <618e24240902100418g3e01d221td27217c350c529d5@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= To: Dan York Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Interoperability vs Pluggability (was Re: mobile p2p in p2psip) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 12:18:21 -0000 On Tue, Feb 10, 2009 at 12:01 PM, Dan York wrote: > > On Feb 10, 2009, at 1:55 AM, Das, Saumitra wrote: > >> Handling mobile nodes can be done in the framework of the base draft. Fo= r >> 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. > > DY> Perhaps this has been discussed a hundred times before and I've misse= d > 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 thei= r > *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 variatio= ns: > 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 kno= wn. > 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 nee= d > something almost like an SDP packet here that specifies the DHT algorithm= s > that a P2PSIP node can support? Or would it try using one DHT and then f= all > 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, --=20 Victor Pascual =C3=81vila From dyork@voxeo.com Tue Feb 10 06:35:32 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2465928C211 for ; Tue, 10 Feb 2009 06:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmb9KKRxHRGd for ; Tue, 10 Feb 2009 06:35:31 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id 0456C28C1F7 for ; Tue, 10 Feb 2009 06:35:30 -0800 (PST) Received: from [172.16.99.36] (account dyork [172.16.99.36] verified) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 38969221; Tue, 10 Feb 2009 14:35:30 +0000 Message-Id: <6FCC00D7-045E-4800-B2F0-4A624A890492@voxeo.com> From: Dan York To: =?ISO-8859-1?Q?Victor_Pascual_=C1vila?= In-Reply-To: <618e24240902100418g3e01d221td27217c350c529d5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Feb 2009 09:35:19 -0500 References: <009401c98b22$687903c0$100ca40a@china.huawei.com> <19E513F61FD3DB47A847097F8AD7128A8EF68A@CNBEEXC006.nsn-intra.net> <2D06DE445C2ADE44890118C3F449B9633FED23A8@NASANEXMB12.na.qualcomm.com> <618e24240902100418g3e01d221td27217c350c529d5@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Interoperability vs Pluggability (was Re: mobile p2p in p2psip) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 14:35:32 -0000 On Feb 10, 2009, at 7:18 AM, Victor Pascual =C1vila wrote: >> DY> Perhaps this has been discussed a hundred times before and I've =20= >> missed >> it... but doesn't allowing different DHTs to be used in RELOAD =20 >> 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 =20 >> 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> Hmmmm... so a "client" doesn't need to know the DHT algorithm to =20 join the overlay network? Perhaps I just need more caffeine this =20 morning, but I guess I don't understand how any node can join the =20 overlay network without understanding the underlying algorithm. I =20 understand that a "peer" would need to know this to join in the =20 overlay and the underlying DHT, but wouldn't the client also? > 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 DY> Yes, exactly. DY> It would seem to me that if RELOAD is to support "pluggability" =20 and allow alternate DHT algorithms, it would need something like this =20= to allow a joining node to understand what underlying algorithm to use =20= (and whether it *can* join the overlay network). Dan --=20 Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com 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.avila@gmail.com Tue Feb 10 06:58:08 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF3343A67F5 for ; Tue, 10 Feb 2009 06:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3ahjPQUeoUg for ; Tue, 10 Feb 2009 06:58:08 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 8AFDC3A6A0F for ; Tue, 10 Feb 2009 06:58:07 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so426499eya.31 for ; Tue, 10 Feb 2009 06:58:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ROGSXESu0AdP47TysqQ+i1fJe1NkpwpTM3BvKDXdJXM=; b=VjvPgmDw26juqhebp4RtkcEkdo647KzZcaIyOx/QuTW4ZqBQiDXeXypRb6ePpyeC8/ uP+nHjhQc+w8p8qDVhp8Ypkp4niJfLy+h22GSnUP126UPlOY67qJtbs/BMDsu21HyPbC LIylW1fSP2V14+utcZRC2PZBLsS8KYU2m/58s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xr6DcnOruElmgElOB9YkjT+VvWh1fnwnXaE8xaeOvhSmlybGVbdiTGj7uhPlHSSyWK mQ2rUyQf3n8iRkLLzSHEmg4BfBrN3WKwUH5pXBhcBRVV6528zES10TCzCp/Cpf2P6zjb 8JGGiI7gBVy6qLUYRdmBsWFU+HUpy4CmARqQk= MIME-Version: 1.0 Received: by 10.210.57.5 with SMTP id f5mr4872064eba.14.1234277888984; Tue, 10 Feb 2009 06:58:08 -0800 (PST) In-Reply-To: <6FCC00D7-045E-4800-B2F0-4A624A890492@voxeo.com> References: <009401c98b22$687903c0$100ca40a@china.huawei.com> <19E513F61FD3DB47A847097F8AD7128A8EF68A@CNBEEXC006.nsn-intra.net> <2D06DE445C2ADE44890118C3F449B9633FED23A8@NASANEXMB12.na.qualcomm.com> <618e24240902100418g3e01d221td27217c350c529d5@mail.gmail.com> <6FCC00D7-045E-4800-B2F0-4A624A890492@voxeo.com> Date: Tue, 10 Feb 2009 15:58:08 +0100 Message-ID: <618e24240902100658n5a48328ua9142b21c93ee3ee@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= To: Dan York Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Interoperability vs Pluggability (was Re: mobile p2p in p2psip) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 14:58:08 -0000 Hi Dan, On Tue, Feb 10, 2009 at 3:35 PM, Dan York wrote: > > On Feb 10, 2009, at 7:18 AM, Victor Pascual =C3=81vila wrote: > >>> 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 introduc= e >>> 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> 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 withou= t > 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. > >> 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 > > > 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 allo= w a > joining node to understand what underlying algorithm to use (and whether = it > *can* join the overlay network). +1 Cheers, --=20 Victor Pascual =C3=81vila From hsinnrei@adobe.com Tue Feb 10 07:00:33 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0BE83A6CA1 for ; Tue, 10 Feb 2009 07:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.87 X-Spam-Level: X-Spam-Status: No, score=-5.87 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-t5chzgnqUT for ; Tue, 10 Feb 2009 07:00:32 -0800 (PST) Received: from psmtp.com (exprod6ob109.obsmtp.com [64.18.1.22]) by core3.amsl.com (Postfix) with ESMTP id C298828C110 for ; Tue, 10 Feb 2009 07:00:31 -0800 (PST) Received: from source ([192.150.11.134]) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKSZGWkhPaAi5iG9p9FtJ/Npaq/aFzwdlB@postini.com; Tue, 10 Feb 2009 07:00:35 PST Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n1AEtJeM029492 for ; Tue, 10 Feb 2009 06:55:21 -0800 (PST) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n1AF0Wl7008425 for ; Tue, 10 Feb 2009 07:00:32 -0800 (PST) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Tue, 10 Feb 2009 07:00:32 -0800 From: Henry Sinnreich To: "p2psip@ietf.org" Date: Tue, 10 Feb 2009 07:00:29 -0800 Thread-Topic: [P2PSIP] mobile p2p in p2psip Thread-Index: AcmKiaz2weRjgudzS9eFn+7ychuCJgASCHkRABNHV1AABCIoEAAHHwmAABEXvxI= Message-ID: In-Reply-To: <2D06DE445C2ADE44890118C3F449B9633FED23A8@NASANEXMB12.na.qualcomm.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C5B6F2ADB4E1hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [P2PSIP] mobile p2p in p2psip X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 15:00:33 -0000 --_000_C5B6F2ADB4E1hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >there could be three kinds of node in the overlay: fixed (e.g. desktop), m= obile (e.g. >handset) and mixed (e.g. laptop). Fixed nodes are obviously go= od candidates for peers of >overlay, while mobile handsets should be limite= d in client status considering not only their >limited capability and resou= rces but also the highly mobile characteristic. Some devices >like laptop c= ould 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 reflect= ed in the WG documents. The laptop example is quite convincing in such scen= arios as opening the netbook for a quick call at the airport and closing it= it immediately afterwards. Henry -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] 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=E9n; Victor Pasc= ual =E1vila Cc: longbwe longbwe; Wang, Sherry; p2psip@ietf.org Subject: Re: [P2PSIP] mobile p2p in p2psip 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 topol= ogy structure of a P2P overlay. Different influences are given to peers and= clients. Clients only need to reconnect with overlay simply, while peers n= eed do data migration and even more before changing connection. There is no= point to ask client to install a same complex protocol with peer, especial= ly in mobility scenario. Moreover, the frequent moving of peers could be a = disaster for structured overlay. Therefore, it is necessary to tell which k= ind of devices could perform as peer and which should work as clients. Besides the peer/client definition mentioned in Reload base, the mobility c= haracter should also be considered to separate them. In my opinion, there c= ould 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 candid= ates for peers of overlay, while mobile handsets should be limited in clien= t status considering not only their limited capability and resources but al= so 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 wor= k only as clients, can not cause churn of the overlay topology structure. I= t seems that we'd better consider the client mobility and peer mobility sep= arately to describe their behavior and to develop their protocols more clea= rly. Xiao Lin -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of= ext Song Haibin Sent: Tuesday, February 10, 2009 9:54 AM To: 'Henry Sinnreich'; 'David Artu?edo Guill=E9n'; 'Victor Pascual =E1vila' Cc: 'longbwe longbwe'; 'Wang,Sherry'; p2psip@ietf.org Subject: Re: [P2PSIP] mobile p2p in p2psip Hi Henry and Bin, >>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", >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 suppor= t that the mobile devices should be better to act as clients rather than pe= ers whenever possible. But I guess there are scenarios where only mobile de= vices 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 Just to be clear, clients are a fully integrated component of the base relo= ad protocol. Motivation for them and some discussion of related issues is = in the p2psip-base appendix (and a much more extensive discussion in pascua= l-clients and others), but the actual mechanisms to support them should alr= eady be in the base draft. Discussion of further work identifying when a node should be a peer and whe= n 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 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip --_000_C5B6F2ADB4E1hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [P2PSIP] mobile p2p in p2psip

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

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

Henry

-----Original Message-----
From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] = 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; p2psip@ietf.= org
Subject: Re: [P2PSIP] mobile p2p in p2psip

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 topol= ogy structure of a P2P overlay. Different influences are given to peers and= clients. Clients only need to reconnect with overlay simply, while peers n= eed do data migration and even more before changing connection. There is no= point to ask client to install a same complex protocol with peer, especial= ly in mobility scenario. Moreover, the frequent moving of peers could be a = disaster for structured overlay. Therefore, it is necessary to tell which k= ind of devices could perform as peer and which should work as clients.

Besides the peer/client definition mentioned in Reload base, the mobility c= haracter should also be considered to separate them. In my opinion, there c= ould 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 candid= ates for peers of overlay, while mobile handsets should be limited in clien= t status considering not only their limited capability and resources but al= so 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 wor= k only as clients, can not cause churn of the overlay topology structure. I= t seems that we'd better consider the client mobility and peer mobility sep= arately to describe their behavior and to develop their protocols more clea= rly.

Xiao Lin

-----Original Message-----
From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] = On Behalf Of ext Song Haibin
Sent: Tuesday, February 10, 2009 9:54 AM
To: 'Henry Sinnreich'; 'David Artu?edo Guillén'; 'Victor Pascual &aa= cute;vila'
Cc: 'longbwe longbwe'; 'Wang,Sherry'; p2psip@ie= tf.org
Subject: Re: [P2PSIP] mobile p2p in p2psip

Hi Henry and Bin,
>>Frequent changes has to be managed in order to route messages effic= iently.

>>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.

As the co-author of this I-D (use my previous name Song Yongchao), I suppor= t that the mobile devices should be better to act as clients rather than pe= ers whenever possible. But I guess there are scenarios where only mobile de= vices 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

Just to be clear, clients are a fully integrated component of the base relo= ad protocol. Motivation for them and some discussion of related issue= s is in the p2psip-base appendix (and a much more extensive discussion in p= ascual-clients and others), but the actual mechanisms to support them shoul= d already be in the base draft.

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

Bruce

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.o= rg/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.o= rg/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.o= rg/mailman/listinfo/p2psip

--_000_C5B6F2ADB4E1hsinnreiadobecom_-- From sa2086@columbia.edu Tue Feb 10 07:03:45 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40CB128C21B for ; Tue, 10 Feb 2009 07:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.966 X-Spam-Level: X-Spam-Status: No, score=-2.966 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECk61mhI+Gme for ; Tue, 10 Feb 2009 07:03:44 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id A1EC53A6C83 for ; Tue, 10 Feb 2009 07:03:42 -0800 (PST) Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n1AF3Qwf025037; Tue, 10 Feb 2009 10:03:26 -0500 (EST) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n1AF3QmV005833; Tue, 10 Feb 2009 10:03:26 -0500 (EST) Received: from localhost (sa2086@localhost) by banana.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n1AF3PqC005830; Tue, 10 Feb 2009 10:03:25 -0500 (EST) X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing -bs Date: Tue, 10 Feb 2009 10:03:25 -0500 (EST) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: "Das, Saumitra" In-Reply-To: <2D06DE445C2ADE44890118C3F449B9633FED23A9@NASANEXMB12.na.qualcomm.com> Message-ID: References: <2D06DE445C2ADE44890118C3F449B9633FED1DAA@NASANEXMB12.na.qualcomm.com> <00c901c98a62$73461290$170ca40a@china.huawei.com> <2D06DE445C2ADE44890118C3F449B9633FED23A9@NASANEXMB12.na.qualcomm.com> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] FIND request X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 15:03:45 -0000 FIND can be used to explore the overlay instance. It is particular useful when updating successor list/neighbor table. However, there are other techniques of exploring the overlay such as obtaining the routing table of a node. FIND may not be very useful in unstructured overlays. -s On Mon, 9 Feb 2009, Das, Saumitra wrote: > It seems too specific to be in there just for the TURN server discovery in that case. There should be a general > key-lookup based scheme that the base draft provides. > > Other enhancements probably belong in a different draft that looks at enhanced service discovery building on the key lookup. > > Best > Saumitra > > -----Original Message----- > From: jiangxingfeng [mailto:jiang.x.f@huawei.com] > Sent: Sunday, February 08, 2009 7:00 PM > To: Das, Saumitra; p2psip@ietf.org > Subject: RE: [P2PSIP] FIND request > >> >> I was wondering if someone could elaborate on the use case for the FIND request. >> I am not sure what it is being used for exactly. > > I think it's related to TURN server discovery procedure. >> >> A generic search mechanism may be implemented on top of the DHT which may have >> such indexing capabilities >> and doesn't need to be specified in the draft. > > I agree. I think service discovery should be extracted from the base draft. We need a generic service discovery mechanism because p2p system is a collaborating system. > > -- > Jiang XingFeng > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > From dyork@voxeo.com Tue Feb 10 07:06:15 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F73C3A694F for ; Tue, 10 Feb 2009 07:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hCnksFadKxm for ; Tue, 10 Feb 2009 07:06:08 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id AD0BF28C161 for ; Tue, 10 Feb 2009 07:06:08 -0800 (PST) Received: from [172.16.99.36] (account dyork [172.16.99.36] verified) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 38969700; Tue, 10 Feb 2009 15:06:11 +0000 Message-Id: <1E952ADC-6099-4096-9DB8-CE5A129362F7@voxeo.com> From: Dan York To: =?ISO-8859-1?Q?Victor_Pascual_=C1vila?= In-Reply-To: <618e24240902100658n5a48328ua9142b21c93ee3ee@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Feb 2009 10:06:11 -0500 References: <009401c98b22$687903c0$100ca40a@china.huawei.com> <19E513F61FD3DB47A847097F8AD7128A8EF68A@CNBEEXC006.nsn-intra.net> <2D06DE445C2ADE44890118C3F449B9633FED23A8@NASANEXMB12.na.qualcomm.com> <618e24240902100418g3e01d221td27217c350c529d5@mail.gmail.com> <6FCC00D7-045E-4800-B2F0-4A624A890492@voxeo.com> <618e24240902100658n5a48328ua9142b21c93ee3ee@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Interoperability vs Pluggability (was Re: mobile p2p in p2psip) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 15:06:15 -0000 Victor, On Feb 10, 2009, at 9:58 AM, Victor Pascual =C1vila wrote: > >> DY> Hmmmm... so a "client" doesn't need to know the DHT algorithm =20 >> to join >> the overlay network? Perhaps I just need more caffeine this =20 >> morning, but I >> guess I don't understand how any node can join the overlay network =20= >> without >> understanding the underlying algorithm. I understand that a "peer" =20= >> 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> Ah... so the clients communicate with the P2P overlay "peer" nodes =20= by way of the "client protocol". So if the P2P overlay supports such =20= a client protocol, client nodes can connect to the overlay without any =20= knowledge of the underlying DHT algorithm (or anything else in the =20 underlying overlay network). DY> Got it... thanks for explaining. DY> This does, of course, assume that whatever P2PSIP protocol we use =20= would have a client protocol. Regards, Dan --=20 Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com 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 sherry.wang@jhuapl.edu Tue Feb 10 08:01:16 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20D773A6C5D for ; Tue, 10 Feb 2009 08:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gC0o5xp6i5LW for ; Tue, 10 Feb 2009 08:01:11 -0800 (PST) Received: from jhuapl.edu (piper.jhuapl.edu [128.244.26.33]) by core3.amsl.com (Postfix) with ESMTP id 776A43A6C44 for ; Tue, 10 Feb 2009 08:01:06 -0800 (PST) Received: from ([128.244.198.90]) by piper.jhuapl.edu with ESMTP with TLS id 5503081.52649983; Tue, 10 Feb 2009 11:00:52 -0500 Received: from aplesstripe.dom1.jhuapl.edu ([128.244.198.211]) by aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Tue, 10 Feb 2009 11:00:52 -0500 From: "Wang, Sherry" To: Henry Sinnreich , "p2psip@ietf.org" Date: Tue, 10 Feb 2009 11:00:51 -0500 Thread-Topic: [P2PSIP] mobile p2p in p2psip Thread-Index: AcmKiaz2weRjgudzS9eFn+7ychuCJgASCHkRABNHV1AABCIoEAAHHwmAABEXvxIAARW9UA== Message-ID: References: <2D06DE445C2ADE44890118C3F449B9633FED23A8@NASANEXMB12.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AC78983C72177B4D9D1C14F7F4AEBA21375E5ACB8Eaplesstripedo_" MIME-Version: 1.0 Subject: Re: [P2PSIP] mobile p2p in p2psip X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 16:01:16 -0000 --_000_AC78983C72177B4D9D1C14F7F4AEBA21375E5ACB8Eaplesstripedo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Henry, Agree: the type of mixed can be a candidate to study mobile P2PSIP. There w= ould 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 exis= ting SIP, especially in terms of performance. For example, high-speed flyin= g devices or moderate-speed ground vehicles for military use, etc. Your eme= rgency rescue is another good example of the mixed type. Thanks, Sherry ________________________________ From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of= Henry Sinnreich Sent: Tuesday, February 10, 2009 10:00 AM To: p2psip@ietf.org Subject: Re: [P2PSIP] mobile p2p in p2psip >there could be three kinds of node in the overlay: fixed (e.g. desktop), m= obile (e.g. >handset) and mixed (e.g. laptop). Fixed nodes are obviously go= od candidates for peers of >overlay, while mobile handsets should be limite= d in client status considering not only their >limited capability and resou= rces but also the highly mobile characteristic. Some devices >like laptop c= ould 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 reflect= ed in the WG documents. The laptop example is quite convincing in such scen= arios as opening the netbook for a quick call at the airport and closing it= it immediately afterwards. Henry -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] 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=E9n; Victor Pasc= ual =E1vila Cc: longbwe longbwe; Wang, Sherry; p2psip@ietf.org Subject: Re: [P2PSIP] mobile p2p in p2psip 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 topol= ogy structure of a P2P overlay. Different influences are given to peers and= clients. Clients only need to reconnect with overlay simply, while peers n= eed do data migration and even more before changing connection. There is no= point to ask client to install a same complex protocol with peer, especial= ly in mobility scenario. Moreover, the frequent moving of peers could be a = disaster for structured overlay. Therefore, it is necessary to tell which k= ind of devices could perform as peer and which should work as clients. Besides the peer/client definition mentioned in Reload base, the mobility c= haracter should also be considered to separate them. In my opinion, there c= ould 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 candid= ates for peers of overlay, while mobile handsets should be limited in clien= t status considering not only their limited capability and resources but al= so 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 wor= k only as clients, can not cause churn of the overlay topology structure. I= t seems that we'd better consider the client mobility and peer mobility sep= arately to describe their behavior and to develop their protocols more clea= rly. Xiao Lin -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of= ext Song Haibin Sent: Tuesday, February 10, 2009 9:54 AM To: 'Henry Sinnreich'; 'David Artu?edo Guill=E9n'; 'Victor Pascual =E1vila' Cc: 'longbwe longbwe'; 'Wang,Sherry'; p2psip@ietf.org Subject: Re: [P2PSIP] mobile p2p in p2psip Hi Henry and Bin, >>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", >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 suppor= t that the mobile devices should be better to act as clients rather than pe= ers whenever possible. But I guess there are scenarios where only mobile de= vices 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 Just to be clear, clients are a fully integrated component of the base relo= ad protocol. Motivation for them and some discussion of related issues is = in the p2psip-base appendix (and a much more extensive discussion in pascua= l-clients and others), but the actual mechanisms to support them should alr= eady be in the base draft. Discussion of further work identifying when a node should be a peer and whe= n 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 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip --_000_AC78983C72177B4D9D1C14F7F4AEBA21375E5ACB8Eaplesstripedo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [P2PSIP] mobile p2p in p2psip

Henry,

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

<= /DIV>

Thanks,

Sherry

From: p2psip-bounces@ietf.org=20 [mailto:p2psip-bounces@ietf.org] On Behalf Of Henry=20 Sinnreich
Sent: Tuesday, February 10, 2009 10:00 AM
To:= =20 p2psip@ietf.org
Subject: Re: [P2PSIP] mobile p2p in=20 p2psip

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

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

Henry

-----Original Message-----
From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On=20 Behalf Of Xiao, Lin (NSN - CN/Beijing)
Sent: Monday, February 09, 2009= 9:41=20 PM
To: ext Song Haibin; Henry Sinnreich; David Artu?edo Guill=E9n; Vic= tor=20 Pascual =E1vila
Cc: longbwe longbwe; Wang, Sherry; p2psip@ietf.org
Subject: Re: [P2PSIP] mob= ile p2p=20 in p2psip

Hi Bruce and Haibin:

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

Mobility could bring disconnectio= n and=20 reconnection which changes the topology structure of a P2P overlay. Diffe= rent=20 influences are given to peers and clients. Clients only need to reconnect= with=20 overlay simply, while peers need do data migration and even more before=20 changing connection. There is no point to ask client to install a same co= mplex=20 protocol with peer, especially in mobility scenario. Moreover, the freque= nt=20 moving of peers could be a disaster for structured overlay. Therefore, it= is=20 necessary to tell which kind of devices could perform as peer and which s= hould=20 work as clients.

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

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

Xiao Lin

-----Original=20 Message-----
From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On=20 Behalf Of ext Song Haibin
Sent: Tuesday, February 10, 2009 9:54 AM
= To:=20 'Henry Sinnreich'; 'David Artu?edo Guill=E9n'; 'Victor Pascual =E1vila'Cc:=20 'longbwe longbwe'; 'Wang,Sherry'; p2psip@ietf.org
Subject: Re: [P2PSIP] mob= ile p2p=20 in p2psip

Hi Henry and Bin,
>>Frequent changes has to be= =20 managed in order to route messages efficiently.

>>It is not = the=20 same as churn, but it introduces similar challenges, IMHO.

>>= ;This=20 makes sense and is the reason the present work in the P2P SIP WG
>&= gt;we=20 have peer nodes and client nodes.

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

>It was preceded and follo= wed=20 by many discussions on this topic, such as
>that frequent p2p proto= col=20 messages for peer nodes will quickly exhaust
>the battery.

A= s the=20 co-author of this I-D (use my previous name Song Yongchao), I support tha= t the=20 mobile devices should be better to act as clients rather than peers whene= ver=20 possible. But I guess there are scenarios where only mobile devices are=20 available. In this case, more considerations need to be given to the mobi= lity=20 of a "peer".

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

BR
Song Haibin

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

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

Bruce

_____________________________________= __________
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www.ietf.or= g/mailman/listinfo/p2psip
__________________________________________= _____
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www.ietf.or= g/mailman/listinfo/p2psip
__________________________________________= _____
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www.ietf.or= g/mailman/listinfo/p2psip

--_000_AC78983C72177B4D9D1C14F7F4AEBA21375E5ACB8Eaplesstripedo_-- From davidbryan@gmail.com Tue Feb 10 08:08:29 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A89F3A6C64 for ; Tue, 10 Feb 2009 08:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzAT2lKlZgKC for ; Tue, 10 Feb 2009 08:08:28 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.183]) by core3.amsl.com (Postfix) with ESMTP id 022DC3A6C55 for ; Tue, 10 Feb 2009 08:08:27 -0800 (PST) Received: by el-out-1112.google.com with SMTP id r27so1785294ele.13 for ; Tue, 10 Feb 2009 08:08:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=TTrC6nDsgHpp5OYDBRDHYPDwyt7EHMF9wvhwdlFq/kA=; b=EIIoanZX7FMZF3GV2TMeQWP8rgdYRAqbtzedDKTiIYDG6s87iKAAiNdnE8pFg+3ApH jGvfppBoKAM8G/L3WftKCoNbGd2ozEHX/+vQ+P0znPY2EOOHLUwUoStCvQzKDWhXKeeg hNjNJEqJGCobmkjAsmt3g70H8uVwq8zOmyTa4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ExEophXtqBuWWH/0fFoqjH67kmt6GZ2SaFjHBA9pcYxb8gRs5Nkinacv7E0isA7R1h 5O/KUunvU/DMq3souvZe+bCuGuOUbG8eVcz0vuH0/bCR+OXNywPbmFqlYtV2MQBSzW5I nkJCRS7JvalN3Bu11OgMRfYmwFvvvPJ3ORgG4= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.142.239.11 with SMTP id m11mr3620021wfh.174.1234282110028; Tue, 10 Feb 2009 08:08:30 -0800 (PST) In-Reply-To: <1E952ADC-6099-4096-9DB8-CE5A129362F7@voxeo.com> References: <009401c98b22$687903c0$100ca40a@china.huawei.com> <19E513F61FD3DB47A847097F8AD7128A8EF68A@CNBEEXC006.nsn-intra.net> <2D06DE445C2ADE44890118C3F449B9633FED23A8@NASANEXMB12.na.qualcomm.com> <618e24240902100418g3e01d221td27217c350c529d5@mail.gmail.com> <6FCC00D7-045E-4800-B2F0-4A624A890492@voxeo.com> <618e24240902100658n5a48328ua9142b21c93ee3ee@mail.gmail.com> <1E952ADC-6099-4096-9DB8-CE5A129362F7@voxeo.com> Date: Tue, 10 Feb 2009 11:08:29 -0500 X-Google-Sender-Auth: fbd6dfba38c75c28 Message-ID: <8b2769930902100808n3e298113sae229df4ce5b292a@mail.gmail.com> From: "David A. Bryan" To: Dan York Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Interoperability vs Pluggability (was Re: mobile p2p in p2psip) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: ,

--
Best Regard= s,
Bin Long
--0016364580d49046500463036ac8-- From saumitra@qualcomm.com Mon Feb 16 22:11:35 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13D43A69CE for ; Mon, 16 Feb 2009 22:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdCzUuAkAejR for ; Mon, 16 Feb 2009 22:11:34 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 75F843A68F7 for ; Mon, 16 Feb 2009 22:11:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1234851105; x=1266387105; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20"p2psip@ietf.org"=20|Date:=20Mon,=201 6=20Feb=202009=2022:11:42=20-0800|Subject:=20direct=20rou ting=20support=20in=20RELOAD|Thread-Topic:=20direct=20rou ting=20support=20in=20RELOAD|Thread-Index:=20AcmQxpplheCk qYACS4+MQNCu0UttqQ=3D=3D|Message-ID:=20<2D06DE445C2ADE448 90118C3F449B9634009959D@NASANEXMB12.na.qualcomm.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5528"=3B=20a=3D"15536250"; bh=azIn3kt7mxKx3bHESol32oYZapTBHoShJXSRhCWrplI=; b=AS2R7URzINGQK2M7lt7uAMnUmhGRZeERDx5//fMUYIZn71X9UBHyqkdj Q/PB7L19eobEtH9/pSdwkTn6dLsC7JIowQwP0tqeJu+6u8bvJeDmKyHrR vsEyAThxOal2yoAN9mXQd67eIHib6RMUlAqgh4z3dXP+DIMBvseUPL3Qc g=; X-IronPort-AV: E=McAfee;i="5100,188,5528"; a="15536250" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Feb 2009 22:11:44 -0800 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1H6BiMf016095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 16 Feb 2009 22:11:44 -0800 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1H6Bi80011676 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 16 Feb 2009 22:11:44 -0800 (PST) Received: from NASANEXMB12.na.qualcomm.com ([10.45.78.34]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Mon, 16 Feb 2009 22:11:43 -0800 From: "Das, Saumitra" To: "p2psip@ietf.org" Date: Mon, 16 Feb 2009 22:11:42 -0800 Thread-Topic: direct routing support in RELOAD Thread-Index: AcmQxpplheCkqYACS4+MQNCu0UttqQ== Message-ID: <2D06DE445C2ADE44890118C3F449B9634009959D@NASANEXMB12.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [P2PSIP] direct routing support in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 06:11:36 -0000 Hi all, In the last meeting there was a discussion on direct routing and the conc= lusions were (if I recall correctly) that this should not be something that= complicates the protocol and that we could have support for indicating th= e use of direct routing if the deployment is amenable to such a scenario. I would like to propose we add a flag bit in the forwarding/common header = that indicates that a direct routing response to a message be used by the r= esponding node. As a policy, implementations in certain scenarios would ena= ble the flag as necessary. We can indicate that the responding node need not keep state to minimize co= mplications. The sending node can simply resend a request (e.g STORE) with = the flag turned off if does not receive a response to the initial STORE req= uest with the flag turned on. This allows direct routing support in scenarios where the deployer or the i= mplementation knows it is dealing with reachable IP addresses. This is also= possible without any complications to the base protocol. Best Saumitra From jouni.maenpaa@ericsson.com Mon Feb 16 23:28:23 2009 Return-Path: