[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

P2PSIP WG                                          Pascual Avila. Victor
Internet-Draft                                   Pompeu Fabra University
Intended status: Informational                       Marcin. Matuszewski
Expires: June 6, 2008                                              Nokia
                                                            Eunsoo. Shim
                                                Locus Telecommunications
                                                            Hewen. Zheng
                                                     Huawei Technologies
                                                        December 4, 2007


                             P2PSIP Clients
                    draft-pascual-p2psip-clients-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 6, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document describes why and when some devices would better be a
   Client rather than a Peer.  The purpose of this document is to
   facilitate the discussion and understanding about the Client node



Victor, et al.            Expires June 6, 2008                  [Page 1]


Internet-Draft               P2PSIP Clients                December 2007


   type.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Definition of P2PSIP Client  . . . . . . . . . . . . . . . . .  3
     3.1.  Differences between a Client device and a device with
           SIP UA connected to a SIP Proxy on a Peer  . . . . . . . .  4
   4.  When a device should be a Client . . . . . . . . . . . . . . .  5
   5.  Storage function by a Client?  . . . . . . . . . . . . . . . .  7
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     9.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 11































Victor, et al.            Expires June 6, 2008                  [Page 2]


Internet-Draft               P2PSIP Clients                December 2007


1.  Introduction

   The P2PSIP Client node type was proposed and introduced quite a while
   ago.  Many drafts mention the concept of Clients [3] [4] [5] [6] [7]
   [8] [9] .Nevertheless, there is some confusion about its concept or
   definition or the benefit of having it yet in the group.  The
   document elaborates on the concept of the role of Clients to
   facilitate the discussion and understanding about the Client node
   type. .


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The other concepts used in this document are compatible with RFC3261
   [2] and the concept draft [3]


3.  Definition of P2PSIP Client

   Typical DHT-based P2P overlay networks (hereafter overlay) need the
   following fundamental functions.
      - Bootstrapping (Letting a new node find some of the existing
      nodes in the overlay and facilitating the new node to join the
      overlay)
      - Overlay maintenance (nodes in the overlay maintain information
      about other nodes and a routing table)
      - Routing (nodes in the overlay route messages to other nodes in
      the overlay; the messages may be for joining the overlay, storing
      data(PUT), searching data (GET), and so on.)
      - Storage (nodes store resource (user) records that contain
      information about resources and users, for example, the location
      information of a resource.  Each user and resource has assigned an
      identifier that is used to locate user's or resource's records in
      the overlay.  The user's and resource's records stored in a
      particular node have assigned identifiers picked from the same
      identifier space as the node identifier(s).)

   Among these four functions, the Peers must support at least the
   overlay maintenance, routing, and storage functions.  Whether a
   device provides any other function in addition to these three
   functions is irrelevant to being a Peer or not.

   Then what is a Client?  It is a device that uses the overlay services
   but does not perform overlay maintenance and routing.  In this sense,



Victor, et al.            Expires June 6, 2008                  [Page 3]


Internet-Draft               P2PSIP Clients                December 2007


   a possible analogy is that a Peer is a routing node and a Client a
   non-routing node.  Again whether a device provides any other services
   is irrelevant to being a Client.  A client uses the overlay services
   through its associated peer; it can be associated with more than one
   peer simultaneously to enhance redundancy.

   Being a Client or a Peer is a matter in the overlay layer.  It is
   independent of what a device does in a different layer or different
   context.  For example, a device being a SIP UA or Proxy is completely
   independent of being a Client or a Peer.  As a Peer may not be
   coupled with any SIP entity, a Client may not be coupled with any SIP
   entity.

   Declaring a device as a Peer or a Client makes the role of the device
   significantly different from the overlay perspective.  A device must
   define its role in the overlay layer, i.e., whether to be a Peer or a
   Client, explicitly and this should be recognized by other nodes
   clearly.  Otherwise, the DHT or the overlay operation may be messed
   up.

3.1.  Differences between a Client device and a device with SIP UA
      connected to a SIP Proxy on a Peer

   First of all, please note that SIP UA and Client belong to completely
   different layers.  SIP UA is an entity in the SIP 'layer' and Client
   is a node type in the overlay 'layer'.  One device may work only as a
   SIP UA entity whereas another may work only as a Client device that
   do not support SIP protocol.

   A device running a SIP UA entity may be associated with a SIP Proxy
   running on a Peer.  This device is quite similar to a Client device
   in that sense that it uses the service of the overlay without being a
   Peer.  But there are a number of differences.

   First, the device with just SIP UA entity is not aware of the overlay
   or supports the Peer or Client protocol.  The Client device is aware
   of the overlay and contains implementation of the Client Protocol.
   It may contain the implementation of the Peer Protocol as well (in
   particular, if the Client Protocol is a subset of the Peer Protocol).
   Then a Client device may turn into a Peer if its situation changes.
   For example, a device may choose to be a Client because its network
   connection is wireless or unstable.  When its network connection
   becomes wired or stable, it can become a Peer.  Even if the Client
   Protocol is something quite different from the Peer Protocol, it is
   anticipated that the two Protocols are going to be often packaged
   together so that a device may choose to be a Client or a Peer
   depending on its hardware resource or network condition, or uptime.




Victor, et al.            Expires June 6, 2008                  [Page 4]


Internet-Draft               P2PSIP Clients                December 2007


   Second, if we allow only SIP UA on a device that is not a Peer take
   advantage of the overlay, applications running over different
   application protocols in the same device will not be able to use the
   P2PSIP overlay.  Let say conference announcements are made as data in
   the overlay.  Since the interaction between SIP UA and Proxy is not
   for generic data search, a conferencing application running on a
   device with just SIP UA entity cannot get conference announcements.
   There is no such limitation with a Client device.  Any application on
   a Client device can use the overlay.  When someone says we don't need
   Clients because we can have Peers with SIP Proxy and SIP UA can
   connect to the SIP Proxies, she/he is thinking about only what a SIP
   UA can do via SIP Proxy.  Clients can enable more than that and
   increase the value of the P2PSIP overlay significantly.

   Third, when a device with SIP UA is connected to a Proxy on a Peer,
   the SIP messages from/to the SIP UA should go through the SIP Proxy
   on the Peer.  This may not be something the user of the device likes
   since the SIP Proxy on a not-so-trusted Peer may modify the SIP
   messages.  On the other hand, a SIP application running in a device
   that acts as a Client, may use the overlay just for search of data
   (eg.  Location of the callee) and communicates with the SIP UA at the
   callee's device directly for session establishment.  The callee
   location data is generated by the callee and may be digitally signed
   easily by the callee device.  So getting just the location data
   through an associated Peer has much less security threat than passing
   INVITE messages through a SIP Proxy on a Peer.

   Fourth, devices with just SIP UA need Peers with SIP Proxy entity.
   In another word, many if not most of the Peers must be coupled with a
   SIP Proxy entity if UA-Proxy relation is the only way non-Peer device
   can use the overlay for session establishment.  If the Client type is
   allowed, there is no such need.


4.  When a device should be a Client

   In general, it is better for the overlay when more 'qualified'
   devices become Peers rather than Clients.  So it is an issue how to
   encourage or enforce devices to become a Peer rather than a Client
   without penalizing the overall performance of the overlay or without
   limiting the access to the overlay unnecessarily.

   A 'benign' device should try to be a Peer whenever possible.
   However, there are situations it is better for a device to be a
   Client rather than a Peer.

   First, some devices have unstable network connection or they churn
   frequently.  If a Peer churns frequently, it generates overhead to



Victor, et al.            Expires June 6, 2008                  [Page 5]


Internet-Draft               P2PSIP Clients                December 2007


   its neighbors for resynchronization of the routing tables and
   transfer of resource (user) records.  If the device does abrupt
   churning, the data stored in the device become unreachable.  To cover
   this, the overlay should increase the number of replicas.

   Second, a device may not meet the requirements of Peers for the
   particular overlay desired by the overlay operator.  For example, the
   OpenDHT is built with nodes on PlanetLab.  Any devices that use the
   OpenDHT become a kind of Client.  This was the choice of the people
   that designed and built the OpenDHT.  Probably they needed access and
   control to the nodes to participate in the DHT that is not available
   in general devices.  A similar thing may happen that an overlay
   operator wants only certain devices to be Peers due to various
   reasons such as high security requirements.  For example, only
   devices that were authenticated using offline means may be allowed be
   a Peer or only devices that have been a Client for a long time
   without any bad behavior may be allowed to be a Peer or a devices
   that have enough fast network interface and uptime can become a peer.

   There are cases it does not makes sense for a device to become a Peer
   even though the owner of the device is a benign user.

   First, the device operates on battery.  Operating on battery does not
   mean necessarily that the device should be or wants to be a Client.
   For example, mobile devices in an emergency situation running in an
   ad-hoc fashion might have to be Peers since there is no other kind of
   devices to be Peers.  In different situations like a large scale
   commercial P2PSIP network where many Peers exist, mobile devices with
   limited battery power might as well be Clients.  The power
   consumption is impacted by maintenance of the routing state and by
   routing incoming messages.  As measurements shown these operations
   have huge impact on how long a battery-powered device can stay online
   without recharging.  Nor the device user, nor the overlay network
   operator benefits by enforcing the mobile devices to be Peers and
   their battery to drain quickly.  Such policy will push away mobile
   device users from the overlay.

   Second, the bandwidth is expensive.  If someone has to pay for every
   packet her/his device exchanges, probably having the device be a Peer
   makes no economical sense to the her/him especially that the overlay
   maintenance and routing of incoming messages are not directly linked
   to the service usage.

   Third, a device is behind a very strict firewall/NAT that makes it
   almost impossible for the device to operate as a Peer.  Even if it is
   possible to traverse NATs and firewalls, every additional connection
   that has to be maintained with other peers in the overlay will cause
   the battery of battery powered devices to drain faster.  If a device



Victor, et al.            Expires June 6, 2008                  [Page 6]


Internet-Draft               P2PSIP Clients                December 2007


   acts as a Client, it needs to maintain only one connection with the
   overlay (a connection with a peer).

   Fourth, a device has insufficient resources to support Peer
   operation.  Low-end devices may have a little memory, a slow CPU and
   may not support fast packet radio interfaces.  In mobile
   communication using P2PSIP, the consumptions of rare mobile bandwidth
   due to P2PSIP traffic will be significantly reduced if mobile devices
   become more Clients and less P2PSIP peers as possible (assuming there
   are enough non-mobile devices being Peers).

   Fifth, a device does not support the routing algorithm used by the
   overlay.  This is mentioned in [10].  The current direction of the
   P2PSIP protocol design is to support pluggable DHT and it is likely
   that overlays have choices of DHT algorithms to use.  And a device
   may not support the particular DHT algorithm used by the overlay the
   device wants to join.  Then such a device will have to be a Client
   even if it has hardware resources and network conditions good enough
   to be a Peer.  This situation would not happen often with devices
   which can download and install software easily.  But small devices
   with embedded software may be put into in this situation.


5.  Storage function by a Client?

   In DHT, a Peer is responsible for storing data (resource (user)
   records) of a certain range of Resource IDs.  For example, in Pastry/
   Bamboo/OpenDHT, data (resource (user) records) are assigned to a Peer
   whose Node ID is closest to the Resource IDs than any other Peers.

   It is possible for a Peer to delegate actual storage of the data to
   another node and just keep a pointer (location information) to the
   data in a different node.  For example, a Peer may have a remote
   storage device and uses it as actual storage for the data the Peer is
   responsible for.  Such a remote storage device may be another Peer, a
   Client, or a node not involved in the overlay at all.  In this
   situation, any lookup message for the data will be routed to the Peer
   responsible for storing the data (Responsible Peer) and it is the
   responsibility of the Responsible Peer to reply to the lookup message
   with the data or a pointer to a node where the data is located.  This
   is how a typical DHT operates.  It should be transparent to other
   Peers whether a Peer uses its local memory or disk or remote memory
   or disk to store the data it is responsible for.

   Whether to allow a Client to be a remote storage for a Peer (or
   multiple Peers) does not affect the overlay operation significantly
   because it is a local arrangement between the respective Peer(s) and
   the Client.  However it affects the design of the protocol used



Victor, et al.            Expires June 6, 2008                  [Page 7]


Internet-Draft               P2PSIP Clients                December 2007


   between Peer and Client.

   The reason for a device to become a Client instead of a Peer must not
   depend on the decision whether a Client may serve as a remote storage
   for a Peer or not.

   Many of the reasons a device to become a Client rather than become a
   Peer make the device unsuitable to provide the storage service.  For
   example, if a device is online only intermittently, storing data in
   such a device does not bring much benefit.  However there is a case a
   Client may be able to store data for its associated Peers.  It is
   when the device became a Client because it did not support the
   overlay's DHT algorithm while it met other requirements for a Peer.

   In a sense, it is better for the overlay if some of its Clients can
   provide the storage service since the overlay's overall storage
   capacity increases.  We need to look into two aspects:
      - How much complexity is introduced to allow Clients to provide
      the storage service?
      - Is the benefit of having Clients provide the storage service
      large enough?

   More thought will be given to these questions.


6.  Acknowledgments

   Some of the idea described in the draft came from the discussion in
   the P2PSIP mailing list.  Thanks to Henning Schulzrinne,Henry
   Sinreich, and Lichun Li


7.  Security Considerations

   Clients (providing no storage service) are free riders.  If not many
   devices qualifed to be a Peer do not volunterr to be a Peer, the
   P2PSIP network may not work well.  It is a concern for P2P networks
   in general.


8.  IANA Considerations

   There are no IANA considerations associated to this memo.


9.  References





Victor, et al.            Expires June 6, 2008                  [Page 8]


Internet-Draft               P2PSIP Clients                December 2007


9.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

9.2.  Informative References

   [3]   Bryan, D., Matthew, Shim, E., and D. Willis, "Concepts and
         Terminology for Peer to Peer SIP", Internet Draft draft-
         ietf=p2psip-concepts-00, June 2007.

   [4]   Bryan, D., Baset, S., Matuszewski, M., and Sinreich, "P2PSIP
         Protocol Framework and Requirements", Internet
         Draft draft-bryan-p2psip-requirements-00, June 2007.

   [5]   Jennings, C., Lowekamp, B., Rescorla, E., and Rosenberg,
         "REsource LOcation And Discovery (RELOAD)", Internet
         Draft draft-bryan-p2psip-reload-02, November 2007.

   [6]   Baset, S., Schulzrinne, H., and M. Matuszweski, "Peer-to-Peer
         Protocol (P2PP)", Internet Draft draft-baset-p2psip-p2pp-01,
         November 2007.

   [7]   Jiang, X. and H. Zheng, "Service Extensible P2P Peer Protocol",
         Internet Draft draft-jiang-p2psip-sep-00, November 2007.

   [8]   Zheng, H., "P2PSIP Client Protocol", Internet
         Draft draft-zheng-p2psip-client-protocol-00, October 2007.

   [9]   Jiang, X. and H. Zheng, "Service Extensible P2P Peer Protocol",
         Internet Draft draft-jiang-p2psip-sep-00, November 2007.

   [10]  Li, L Ch. and Y. Wang, "Different types of nodes in P2PSIP",
         Internet Draft draft-li-p2psip-node-types-00, November 2007.













Victor, et al.            Expires June 6, 2008                  [Page 9]


Internet-Draft               P2PSIP Clients                December 2007


Authors' Addresses

   Victor Pascual Avila
   Pompeu Fabra University
   Barcelona, Passeig de la Circumval.lacio  8 08003
   Spain

   Phone: +34-93-5421561
   Fax:   +34-93-5422517
   Email: victor.pascual.avila@gmail.com


   Marchin Matuszewski
   Nokia
   P.O.Box 407
   NOKIA GROUP, FIN  00045
   Finland

   Phone: unlisted
   Email: marcin.matsuszewski@nokia.com


   Eunsoo Shim
   Locus Telecommunications
   111 Sylvan Avenue
   Englewood Cliffs, New Jersey  07632
   USA

   Phone: unlisted
   Email: eunsooshim@gmail.com


   Hewen Zheng
   Huawei Technologies
   Baixia Road No. 91
   Nanjing, Jiangsu Province  210001
   PRC

   Phone: +86-25-84565467
   Fax:   +86-25-84565354
   Email: hwzheng@huawei.com










Victor, et al.            Expires June 6, 2008                 [Page 10]


Internet-Draft               P2PSIP Clients                December 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Victor, et al.            Expires June 6, 2008                 [Page 11]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/