[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01
P2PSIP WG V. Pascual
Internet-Draft Pompeu Fabra University
Intended status: Informational M. Matuszewski
Expires: August 27, 2008 Nokia
E. Shim
Locus Telecommunications
H. Zheng
Y. Song
Huawei Technologies
February 24, 2008
P2PSIP Clients
draft-pascual-p2psip-clients-01
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 August 27, 2008.
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
type.
Pascual, et al. Expires August 27, 2008 [Page 1]
Internet-Draft P2PSIP Clients February 2008
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. What functions a client can contribute in P2P layer . . . . . 7
5.1. Storage function by a Client . . . . . . . . . . . . . . . 8
5.2. P2P Relay function by a client . . . . . . . . . . . . . . 9
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Pascual, et al. Expires August 27, 2008 [Page 2]
Internet-Draft P2PSIP Clients February 2008
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]. 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,
Pascual, et al. Expires August 27, 2008 [Page 3]
Internet-Draft P2PSIP Clients February 2008
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.
Pascual, et al. Expires August 27, 2008 [Page 4]
Internet-Draft P2PSIP Clients February 2008
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 whether
a device should become a Client or a Peer.
If the main service of the particular P2P overlay network is to share
the bandwidth and storage (eg. for file sharing) and thus the
resource abundance is more important than search/lookup speed,
definitely all of the devices should become peers whenever possible.
On the other hand, in real-time applications like P2PSIP, the search
performance would be at least as important as the storage capacity.
Concerning the search performance, the smaller number of Peers is the
Pascual, et al. Expires August 27, 2008 [Page 5]
Internet-Draft P2PSIP Clients February 2008
faster the lookup can potentially be. Therefore a larger number of
Peers is not necessarily beneficial. Of course the decision about
what devices should become Peers must be made carefully. We have to
remember that the smaller number of Peers is, the bigger impact of a
particular peer on the P2P overlay network performance can be. There
are situations where 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
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 can be behind a very strict firewall/NAT that makes
it almost impossible for the device to operate as a Peer. If a
device is behind the symmetric NAT, then it is very hard for it to
setup direct connections with its neighbors. In this situation the
device would have to use relay servers when routing messages to its
neighbors. If many devices of this kind become peers, then the
overlay need many relays and the efficiency of the overlay becomes
very low.
Third, a device may have insufficient resources to support Peer
operation. Low-end mobile devices may have a little memory, a slow
CPU and may not support fast packet radio interfaces.
Forth, a device does not support the routing algorithm used by the
overlay. This is mentioned in [9]. 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.
There are also other reasons why a device should not become 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 acts as a Client, it needs to maintain
only one connection with the overlay (a connection with a peer).
Besides the power consumption is impacted by maintenance of the
routing state and by routing incoming messages. As measurements
Pascual, et al. Expires August 27, 2008 [Page 6]
Internet-Draft P2PSIP Clients February 2008
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.
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. Besides
the battery consumption caused by maintenance of the routing state
and by routing incoming messages can be reasonable in small overlays.
In mobile communication using P2PSIP, the consumptions of rare mobile
bandwidth in the access networks 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). Besides we have to remember that 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.
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.
5. What functions a client can contribute in P2P layer
Clients get services from the overlay network, however, clients can
also contribute varialbe useful functions to the overlay. For
example, a client can provide STUN server function to help establish
connections between other peers, and also other useful functions. We
focus on several functions that a client can contribute to the
overlay in P2P layer here.
Pascual, et al. Expires August 27, 2008 [Page 7]
Internet-Draft P2PSIP Clients February 2008
5.1. 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
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?
Pascual, et al. Expires August 27, 2008 [Page 8]
Internet-Draft P2PSIP Clients February 2008
- Is the benefit of having Clients provide the storage service
large enough?
More thought will be given to these questions.
5.2. P2P Relay function by a client
In some scenarios like for real time applications, a larger number of
Peers is not necessarily beneficial, therefore there is probability
that some capable devices act as clients in the overlay. These
devices have the ability to relay messages for other devices.
A node behind strict firewall/NAT may need a relay when it wants to
communicate with others. Generally, it can route messages with the
overlay routing, however, for more efficiency, it can use a "Relay"
with public address to relay requests or responses when it knows the
contact address of the other party. All capable peers or clients can
act as Relays. The choice of Relays must be well designed for some
criterions, e.g. proximity. The best choice of Relay for a peer or
client may be a peer or a client. Not in all cases can peer Relays
be more efficient than client Relays.
Clients that provide relay function do not need to understand the DHT
algorithm of the overlay. It only provides relay service to a
certain peer or client that needs its help for communication
convenience.
We only focus on the relay function for P2P layer communication here,
e.g., P2P requests or responses. All relay functions beyond those
are out of scope.
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.
Pascual, et al. Expires August 27, 2008 [Page 9]
Internet-Draft P2PSIP Clients February 2008
8. IANA Considerations
There are no IANA considerations associated to this memo.
9. References
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] Song, Y., Jiang, X., Zheng, H., and H. Deng, "P2PSIP Client
Protocol", Internet Draft draft-zheng-p2psip-client-protocol-01,
February 2008.
[8] Jiang, X., Zheng, H., Macian, C., and V. Pascual, "Service
Extensible P2P Peer Protocol", Internet
Draft draft-jiang-p2psip-sep-01, February 2008.
[9] Li, L Ch. and Y. Wang, "Different types of nodes in P2PSIP",
Internet Draft draft-li-p2psip-node-types-00, November 2007.
Pascual, et al. Expires August 27, 2008 [Page 10]
Internet-Draft P2PSIP Clients February 2008
Authors' Addresses
Victor Pascual
Pompeu Fabra University
Barcelona, Passeig de la Circumval.lacio 8 08003
Spain
Phone: +34-93-5421561
Fax: +34-93-5422517
Email: victor.pascuala@upf.edu
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
Pascual, et al. Expires August 27, 2008 [Page 11]
Internet-Draft P2PSIP Clients February 2008
Song Yongchao
Huawei Technologies
Baixia Road No. 91
Nanjing, Jiangsu Province 210001
PRC
Phone: +86-25-84565081
Fax: +86-25-84565070
Email: melodysong@huawei.com
Pascual, et al. Expires August 27, 2008 [Page 12]
Internet-Draft P2PSIP Clients February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Pascual, et al. Expires August 27, 2008 [Page 13]
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/