RE: [P2PSIP] do we need a client protocol?
Zheng Hewen <hwzheng@huawei.com> Fri, 13 July 2007 01:38 UTC
Return-path: <p2psip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9A7L-0001mu-Sj; Thu, 12 Jul 2007 21:38:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9A7K-0001mo-VG for p2psip@ietf.org; Thu, 12 Jul 2007 21:38:46 -0400
Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9A7D-0004H9-Dm for p2psip@ietf.org; Thu, 12 Jul 2007 21:38:46 -0400
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 <0JL300AZ4GIW9C@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 13 Jul 2007 09:37:45 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL300CY2GIRLE@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 13 Jul 2007 09:37:44 +0800 (CST)
Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL300AR7GIMOF@szxml04-in.huawei.com> for p2psip@ietf.org; Fri, 13 Jul 2007 09:37:39 +0800 (CST)
Date: Fri, 13 Jul 2007 09:37:35 +0800
From: Zheng Hewen <hwzheng@huawei.com>
Subject: RE: [P2PSIP] do we need a client protocol?
In-reply-to: <1DB91DF937A4544C81E636468B91C21C863E5F@CNSHGSMBS03.ad4.ad.alcatel.com>
To: 'HUANG Ping B' <Ping.b.Huang@alcatel-sbell.com.cn>, 'Michal Giermasinski' <michal.giermasinski@gmail.com>, p2psip@ietf.org, marcin.matuszewski@nokia.com
Message-id: <039301c7c4ee$6397ecf0$5105a40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook 11
Thread-index: AcfEArudCMm2duX/SymVkGs47R709QAH5t6AAAHCSMAAB5ky4AAFqQhQAAIh/DAACaerMAAXkVEg
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e8ea636ec013593313c7b28da6453598
Cc:
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1385927368=="
Errors-To: p2psip-bounces@ietf.org
Hi Huang Your reply puzzled me. Our discussion focus is whether all peers in P2PSIP overlay must recognize SIP. You think that all peers must recognize SIP messages, but I think that some peers may not recognize SIP messages, do I misunderstand? By the way, in detail, there are three modes compatible with the P2PSIP WG charter. As you said, the first is SIP over P2P, P2P provides transport service such as tunneling SIP; the second is P2P over SIP, SIP is extended so that P2P is embedded in SIP messages; the last is that P2P is independent of SIP and SIP is independent of P2P at the same time, P2P only provides the service determining the correct destination for SIP requests to SIP terminals, it is the simplest and clearest. I suggest that you might read these drafts as Marcin's advice. http://www.p2psip.org/drafts/draft-bryan-p2psip-requirements-00.txt http://www.ietf.org/internet-drafts/draft-baset-p2psip-p2pp-00.txt http://www.p2psip.org/drafts/draft-jennings-p2psip-asp-00.txt _____ From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn] Sent: 2007年7月12日 22:27 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org; marcin.matuszewski@nokia.com Subject: RE: [P2PSIP] do we need a client protocol? Hi Zheng and marcin I have never said that P2PSIP is IP or use SIP. as we know, there are two mode in P2PSIP, one is SIP over P2P and the other is P2P over SIP.SIP is just in application layer and P2P or P2PSIP are more like transport layer. in SIP over P2P, SIP is just one of the protocols interacting with P2P or P2PSIP overlay. in P2P over SIP, SIP is made some extension. I have never said that P2PSIP peer protocol shall use SIP, SIP is over P2PSIP! And as I said, peers "SHOULD" not "SHALL" recognize SIP. maybe you "SHALL" read RFC2119 _____ From: Zheng Hewen [mailto:hwzheng@huawei.com] Sent: Thursday, July 12, 2007 5:33 PM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, One supplement, FYI. In the future P2PSIP deployment, one device that can provide DHT service but not recognize SIP messages should be admitted as one member/peer of P2PSIP overlay, we do not have to update the device to support SIP and then provide DHT service, the cost introduced due to the update is unnecessary. _____ From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn] Sent: 2007年7月12日 16:57 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? I have never said that P2PSIP is equal to SIP, P2PSIP is just an overlay as an alternative to the SIP discovery process of RFC 3263, P2PSIP offers an alternative mechanism for determining the correct destination for SIP requests. SIP is session layer protocol, P2PSIP is under SIP. of cause, is you use another protocol, P2PSIP may be called another name, such as P2PXXX. Peers in P2PSIP overlay are responsible not just for location (done by P2PSIP protocol). Why we called P2PSIP as "P2PSIP"? this name means that there is a relationship between P2PSIP and SIP, maybe SIP over P2P or P2P over SIP. but any way, SIP should be used. then Peers in P2PSIP overlay( not P2PXXX overlay) should recognize SIP message. Ok, you can say that a tunnel protocol could be used to deliver SIP protocol, this is a choice, but not good choice. if a tunnel protocol is used, then SIP has nothing with P2P overlay, this tunnel protocol could deliver any protocols besides SIP, then name "P2PSIP" does not make sense. when peers in P2PSIP overlay do not recognize SIP message, then let them out of overlay. _____ From: Zheng Hewen [mailto:hwzheng@huawei.com] Sent: Thursday, July 12, 2007 2:01 PM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, If I do not misunderstand, P2PSIP is not equal to SIP. Essentially in P2PSIP overlay, P2PSIP peers have nothing with SIP. Why must we bind SIP to P2PSIP peers? Here is the description about P2PSIP peers in WG charter, FYI. "The work focuses on collections of nodes called "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which overlay users are identified and provides mechanisms for locating users or resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers primarily in that they do not store information in the overlay, but only use it to locate users and resources. P2PSIP clients and peers use the resolution services of the peers as an alternative to the SIP discovery process of RFC 3263. In this way, P2PSIP offers an alternative mechanism for determining the correct destination for SIP requests. The working group's initial charter scope will be to produce protocols to enable this alternate mechanism for RFC 3263 functionality." Nothing says that P2PSIP peers must support SIP or have anything with SIP. From the charter, functionality of P2PSIP peers is so clear and simple, why do we make it complicated? I think we can do it simpler, SIP is SIP, P2PSIP peer is P2PSIP peer, let them be. Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com ---------------------------------------------------------------------------------------------------------------------------- --------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn] Sent: 2007年7月12日 10:22 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi all P2P is great topic, but P2PSIP is the subset or certain instance of P2P. when we discuss P2PSIP, we shall not involve all nodes which could be peers in P2PSIP overlay. peers in P2PSIP overlay are not equal to peers in P2P overlay. when we discuss IMS, although legacy equipments does not support SIP, but some AGWs do translation or agent for those equipments. then, when we discuss P2PSIP, shall we involve all peers who know SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and vice versa. and I think that Peers in P2PSIP overlay should have some common base functionalitis such as SIP recognition. I think we shall make P2PSIP more simple but not more complex. _____ From: Zheng Hewen [mailto:hwzheng@huawei.com] Sent: Thursday, July 12, 2007 9:34 AM To: 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, Please let me describe the case in detail. In the case, all clients support SIP, but some peers in the overlay network do not support SIP and some support SIP. For those peers which do not support SIP, such as some PCs, they can provide all required DHT services, but there is only a pity that they can not recognize any SIP message, maybe they think that the capability is unnecessary. In this case, some client protocol is desirable. Certainly this protocol may be the subset of general Peer Protocol if we regard those clients as Lame Peers and regard those peers as Pure Peers who only provide required DHT services. IMHO, this case does not care those clients not supporting SIP. Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com ---------------------------------------------------------------------------------------------------------------------------- --------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: Michal Giermasinski [mailto:michal.giermasinski@gmail.com] Sent: 2007年7月12日 5:31 To: Zheng Hewen; p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? Hi! Well, in my oppinion it is not a good for creating a new protocol. If a client application is not able to use SIP protocol that is well known for years it obviously will not be able to use a new one that will be designed especially for cooperation with p2psip overlay. If we follow this understanding we can assume that the better thing is to use SIP on this interface (between client outstanding the overlay and the peer in the overlay). The only issue is to create a proxy-like peer that will be able to help client to get benefits of the overlay. What we should consider is how to filter the traffic unwanted by regular client that do not want to take part in the routing decision. best regards Michal Giermasinski 2007/7/11, Zheng Hewen <hwzheng@huawei.com>: Hi, A client protocol will be useful when some peers in the overlay do not support SIP, those peers are only responsible to provide distributed storage, location and transport services for information about SIP, but those peers do not recognize any SIP messages at all. In this case, how to maintain the relation between clients (UA) and the hosting peer(s)? One client protocol is desirable at this time. Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com ---------------------------------------------------------------------------------------------------------------------------- --------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: 2007?6?26? 1:39 To: Dean Willis; David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: [P2PSIP] do we need a client protocol? Folks, Given the length of the discussion on "do we need a client protocol?" let me repeat the simple imperatives for the client: - Limited battery in mobile devices, and - Other uses besides SIP. Business planning folks may not care about the WG charter, but about the return on the investment. Thanks, Henry -----Original Message----- From: Dean Willis [mailto: <mailto:dean.willis@softarmor.com> dean.willis@softarmor.com] Sent: Thursday, June 14, 2007 11:23 PM To: David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peerterminology David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so, for > most > DHTs, how do we allow you to be in the overlay and not store resources (not > typical for most current DHT algorithms) Well, that certainly depends on the DHT algorithm involved. It certainly seems that a peer that moves between contributing and non-contributing might HAVE a peer ID, but whether it chooses to insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. > My concern all along has been that I don't understand why something is > a peer if it isn't doing anything other than talking to someone and > making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and > instead talks to a peer to get resources, is in any way a peer. It > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other > terminology for over a year now. Just looks like a souce of confusion. A node might sometimes have a high-bandwidth connection and wish to contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. Does this modality make it two different nodes? > If we do go this way, there is one subtle point. If I join the overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services That's "offer no other services", since routing is itself a service. > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) I think there's a range of "contributing" in play. For most DHT models, a minimally contributing node will route a request it receives. It might ask nicely (perhaps a q-value mechanism) to not have to route requests, but would probably mathematically still have to route something it gets. I think we distinguish based on the service advertisements from the peer. > If we are so opposed to client for confusion with SIP UAs, lets pick a new > name, but why some flavor of peer when it does nothing remotely peer like? Because in 15 minutes it might roam onto a WiFi net and therefore change it service offering. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip <https://www1.ietf.org/mailman/listinfo/p2psip> _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip <https://www1.ietf.org/mailman/listinfo/p2psip> _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip <https://www1.ietf.org/mailman/listinfo/p2psip>
_______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip
- [P2PSIP] Concepts document: proposal for active/p… Dean Willis
- Fwd: Re: [P2PSIP] Concepts document: proposal for… Ted Hardie
- Re: [P2PSIP] Concepts document: proposal for acti… Avshalom Houri
- Re: [P2PSIP] Concepts document: proposal for acti… David A. Bryan
- Re: [P2PSIP] Concepts document: proposal for acti… Bill Mccormick
- Re: [P2PSIP] Concepts document: proposal for acti… Philip Matthews
- RE: [P2PSIP] Concepts document: proposal for acti… Gustavo García
- Re: [P2PSIP] Concepts document: proposal for acti… Philip Matthews
- Re: [P2PSIP] Concepts document: proposal for acti… Spencer Dawkins
- RE: [P2PSIP] Concepts document: proposal for acti… Henry Sinnreich
- RE: [P2PSIP] Concepts document: proposal for acti… Gustavo García
- Re: [P2PSIP] Concepts document: proposal for acti… Enrico Marocco
- RE: [P2PSIP] Concepts document: proposal for acti… Salman Abdul Baset
- Re: [P2PSIP] Concepts document: proposal for acti… Enrico Marocco
- Re: [P2PSIP] Concepts document: proposal for acti… Salman Abdul Baset
- RE: [P2PSIP] Concepts document: proposal for acti… JiangXingFeng
- Re: [P2PSIP] Concepts document: proposal for acti… Dean Willis
- Re: [P2PSIP] Concepts document: proposal for acti… Dean Willis
- Re: [P2PSIP] Concepts document: proposal for acti… Dean Willis
- Re: [P2PSIP] Concepts document: proposal for acti… Greger V. Teigre
- RE: [P2PSIP] Concepts document: proposalfor activ… marcin.matuszewski
- RE: [P2PSIP] Concepts document: proposal foractiv… marcin.matuszewski
- Re: [P2PSIP] Concepts document: proposal for acti… Philip Matthews
- RE: [P2PSIP] Concepts document: proposal foractiv… JiangXingFeng
- Re: [P2PSIP] Concepts document: proposalfor activ… Philip Matthews
- Re: [P2PSIP] Concepts document: proposal for acti… Enrico Marocco
- Re: [P2PSIP] Concepts document: proposalfor activ… Salman Abdul Baset
- RE: [P2PSIP] Concepts document: proposal for acti… marcin.matuszewski
- Re: [P2PSIP] Concepts document: proposal for acti… Enrico Marocco
- Re: [P2PSIP] Concepts document: proposal for acti… Enrico Marocco
- RE: [P2PSIP] Concepts document: proposalfor activ… Brian Rosen
- Re: [P2PSIP] Concepts document: proposal for acti… Philip Matthews
- Re: [P2PSIP] Concepts document: proposal foractiv… Dean Willis
- Re: [P2PSIP] Concepts document: proposalfor activ… Dean Willis
- RE: [P2PSIP] Concepts document: proposal for acti… Henry Sinnreich
- RE: [P2PSIP] Concepts document: proposal for acti… Henry Sinnreich
- Re: [P2PSIP] Concepts document: proposal for acti… Enrico Marocco
- Re: [P2PSIP] Concepts document: proposalfor activ… Greger V. Teigre
- RE: [P2PSIP] Concepts document: proposalfor activ… JiangXingFeng
- [P2PSIP] do we need a client protocol? Henry Sinnreich
- Re: [P2PSIP] do we need a client protocol? Alan Johnston
- Re: [P2PSIP] do we need a client protocol? Eunsoo Shim
- RE: [P2PSIP] do we need a client protocol? marcin.matuszewski
- RE: [P2PSIP] do we need a client protocol? David Barrett
- RE: [P2PSIP] do we need a client protocol? Henry Sinnreich
- RE: [P2PSIP] do we need a client protocol? David Barrett
- Re: [P2PSIP] do we need a client protocol? Philip Matthews
- RE: [P2PSIP] do we need a client protocol? marcin.matuszewski
- RE: [P2PSIP] do we need a client protocol? Zheng Hewen
- Re: [P2PSIP] do we need a client protocol? Michal Giermasinski
- RE: [P2PSIP] do we need a client protocol? Zheng Hewen
- RE: [P2PSIP] do we need a client protocol? HUANG Ping B
- RE: [P2PSIP] do we need a client protocol? Roy, Radhika R.
- RE: [P2PSIP] do we need a client protocol? Zheng Hewen
- RE: [P2PSIP] do we need a client protocol? HUANG Ping B
- RE: [P2PSIP] do we need a client protocol? Zheng Hewen
- RE: [P2PSIP] do we need a client protocol? marcin.matuszewski
- RE: [P2PSIP] do we need a client protocol? Zheng Hewen
- RE: [P2PSIP] do we need a client protocol? HUANG Ping B
- RE: [P2PSIP] do we need a client protocol? Roy, Radhika R.
- Re: [P2PSIP] do we need a client protocol? Duan Chen
- RE: [P2PSIP] do we need a client protocol? Zheng Hewen
- RE: [P2PSIP] do we need a client protocol? HUANG Ping B
- RE: [P2PSIP] do we need a client protocol? Zheng Hewen
- RE: [P2PSIP] do we need a client protocol? HUANG Ping B
- RE: [P2PSIP] do we need a client protocol? Zheng Hewen