idnits 2.17.1 draft-pascual-p2psip-clients-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 498. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 509. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 522. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 24, 2008) is 5906 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC2119' on line 83 == Unused Reference: '1' is defined on line 400, but no explicit reference was found in the text -- No information found for draft-ietf - is the name correct? == Outdated reference: A later version (-04) exists of draft-bryan-p2psip-reload-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP WG V. Pascual 3 Internet-Draft Pompeu Fabra University 4 Intended status: Informational M. Matuszewski 5 Expires: August 27, 2008 Nokia 6 E. Shim 7 Locus Telecommunications 8 H. Zheng 9 Y. Song 10 Huawei Technologies 11 February 24, 2008 13 P2PSIP Clients 14 draft-pascual-p2psip-clients-01 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on August 27, 2008. 41 Abstract 43 This document describes why and when some devices would better be a 44 Client rather than a Peer. The purpose of this document is to 45 facilitate the discussion and understanding about the Client node 46 type. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Definition of P2PSIP Client . . . . . . . . . . . . . . . . . 3 53 3.1. Differences between a Client device and a device with 54 SIP UA connected to a SIP Proxy on a Peer . . . . . . . . 4 55 4. When a device should be a Client . . . . . . . . . . . . . . . 5 56 5. What functions a client can contribute in P2P layer . . . . . 7 57 5.1. Storage function by a Client . . . . . . . . . . . . . . . 8 58 5.2. P2P Relay function by a client . . . . . . . . . . . . . . 9 59 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 64 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 66 Intellectual Property and Copyright Statements . . . . . . . . . . 13 68 1. Introduction 70 The P2PSIP Client node type was proposed and introduced quite a while 71 ago. Many drafts mention the concept of Clients [3] [4] [5] [6] [7] 72 [8]. Nevertheless, there is some confusion about its concept or 73 definition or the benefit of having it yet in the group. The 74 document elaborates on the concept of the role of Clients to 75 facilitate the discussion and understanding about the Client node 76 type. 78 2. Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 The other concepts used in this document are compatible with RFC3261 85 [2] and the concept draft [3] 87 3. Definition of P2PSIP Client 89 Typical DHT-based P2P overlay networks (hereafter overlay) need the 90 following fundamental functions. 91 - Bootstrapping (Letting a new node find some of the existing 92 nodes in the overlay and facilitating the new node to join the 93 overlay) 94 - Overlay maintenance (nodes in the overlay maintain information 95 about other nodes and a routing table) 96 - Routing (nodes in the overlay route messages to other nodes in 97 the overlay; the messages may be for joining the overlay, storing 98 data(PUT), searching data (GET), and so on.) 99 - Storage (nodes store resource (user) records that contain 100 information about resources and users, for example, the location 101 information of a resource. Each user and resource has assigned an 102 identifier that is used to locate user's or resource's records in 103 the overlay. The user's and resource's records stored in a 104 particular node have assigned identifiers picked from the same 105 identifier space as the node identifier(s).) 107 Among these four functions, the Peers must support at least the 108 overlay maintenance, routing, and storage functions. Whether a 109 device provides any other function in addition to these three 110 functions is irrelevant to being a Peer or not. 112 Then what is a Client? It is a device that uses the overlay services 113 but does not perform overlay maintenance and routing. In this sense, 114 a possible analogy is that a Peer is a routing node and a Client a 115 non-routing node. Again whether a device provides any other services 116 is irrelevant to being a Client. A client uses the overlay services 117 through its associated peer; it can be associated with more than one 118 peer simultaneously to enhance redundancy. 120 Being a Client or a Peer is a matter in the overlay layer. It is 121 independent of what a device does in a different layer or different 122 context. For example, a device being a SIP UA or Proxy is completely 123 independent of being a Client or a Peer. As a Peer may not be 124 coupled with any SIP entity, a Client may not be coupled with any SIP 125 entity. 127 Declaring a device as a Peer or a Client makes the role of the device 128 significantly different from the overlay perspective. A device must 129 define its role in the overlay layer, i.e., whether to be a Peer or a 130 Client, explicitly and this should be recognized by other nodes 131 clearly. Otherwise, the DHT or the overlay operation may be messed 132 up. 134 3.1. Differences between a Client device and a device with SIP UA 135 connected to a SIP Proxy on a Peer 137 First of all, please note that SIP UA and Client belong to completely 138 different layers. SIP UA is an entity in the SIP 'layer' and Client 139 is a node type in the overlay 'layer'. One device may work only as a 140 SIP UA entity whereas another may work only as a Client device that 141 do not support SIP protocol. 143 A device running a SIP UA entity may be associated with a SIP Proxy 144 running on a Peer. This device is quite similar to a Client device 145 in that sense that it uses the service of the overlay without being a 146 Peer. But there are a number of differences. 148 First, the device with just SIP UA entity is not aware of the overlay 149 or supports the Peer or Client protocol. The Client device is aware 150 of the overlay and contains implementation of the Client Protocol. 151 It may contain the implementation of the Peer Protocol as well (in 152 particular, if the Client Protocol is a subset of the Peer Protocol). 153 Then a Client device may turn into a Peer if its situation changes. 154 For example, a device may choose to be a Client because its network 155 connection is wireless or unstable. When its network connection 156 becomes wired or stable, it can become a Peer. Even if the Client 157 Protocol is something quite different from the Peer Protocol, it is 158 anticipated that the two Protocols are going to be often packaged 159 together so that a device may choose to be a Client or a Peer 160 depending on its hardware resource or network condition, or uptime. 162 Second, if we allow only SIP UA on a device that is not a Peer take 163 advantage of the overlay, applications running over different 164 application protocols in the same device will not be able to use the 165 P2PSIP overlay. Let say conference announcements are made as data in 166 the overlay. Since the interaction between SIP UA and Proxy is not 167 for generic data search, a conferencing application running on a 168 device with just SIP UA entity cannot get conference announcements. 169 There is no such limitation with a Client device. Any application on 170 a Client device can use the overlay. When someone says we don't need 171 Clients because we can have Peers with SIP Proxy and SIP UA can 172 connect to the SIP Proxies, she/he is thinking about only what a SIP 173 UA can do via SIP Proxy. Clients can enable more than that and 174 increase the value of the P2PSIP overlay significantly. 176 Third, when a device with SIP UA is connected to a Proxy on a Peer, 177 the SIP messages from/to the SIP UA should go through the SIP Proxy 178 on the Peer. This may not be something the user of the device likes 179 since the SIP Proxy on a not-so-trusted Peer may modify the SIP 180 messages. On the other hand, a SIP application running in a device 181 that acts as a Client, may use the overlay just for search of data 182 (eg. Location of the callee) and communicates with the SIP UA at the 183 callee's device directly for session establishment. The callee 184 location data is generated by the callee and may be digitally signed 185 easily by the callee device. So getting just the location data 186 through an associated Peer has much less security threat than passing 187 INVITE messages through a SIP Proxy on a Peer. 189 Fourth, devices with just SIP UA need Peers with SIP Proxy entity. 190 In another word, many if not most of the Peers must be coupled with a 191 SIP Proxy entity if UA-Proxy relation is the only way non-Peer device 192 can use the overlay for session establishment. If the Client type is 193 allowed, there is no such need. 195 4. When a device should be a Client 197 In general, it is better for the overlay when more 'qualified' 198 devices become Peers rather than Clients. So it is an issue whether 199 a device should become a Client or a Peer. 201 If the main service of the particular P2P overlay network is to share 202 the bandwidth and storage (eg. for file sharing) and thus the 203 resource abundance is more important than search/lookup speed, 204 definitely all of the devices should become peers whenever possible. 206 On the other hand, in real-time applications like P2PSIP, the search 207 performance would be at least as important as the storage capacity. 208 Concerning the search performance, the smaller number of Peers is the 209 faster the lookup can potentially be. Therefore a larger number of 210 Peers is not necessarily beneficial. Of course the decision about 211 what devices should become Peers must be made carefully. We have to 212 remember that the smaller number of Peers is, the bigger impact of a 213 particular peer on the P2P overlay network performance can be. There 214 are situations where it is better for a device to be a Client rather 215 than a Peer. 217 First, some devices have unstable network connection or they churn 218 frequently. If a Peer churns frequently, it generates overhead to 219 its neighbors for resynchronization of the routing tables and 220 transfer of resource (user) records. If the device does abrupt 221 churning, the data stored in the device become unreachable. To cover 222 this, the overlay should increase the number of replicas. 224 Second, a device can be behind a very strict firewall/NAT that makes 225 it almost impossible for the device to operate as a Peer. If a 226 device is behind the symmetric NAT, then it is very hard for it to 227 setup direct connections with its neighbors. In this situation the 228 device would have to use relay servers when routing messages to its 229 neighbors. If many devices of this kind become peers, then the 230 overlay need many relays and the efficiency of the overlay becomes 231 very low. 233 Third, a device may have insufficient resources to support Peer 234 operation. Low-end mobile devices may have a little memory, a slow 235 CPU and may not support fast packet radio interfaces. 237 Forth, a device does not support the routing algorithm used by the 238 overlay. This is mentioned in [9]. The current direction of the 239 P2PSIP protocol design is to support pluggable DHT and it is likely 240 that overlays have choices of DHT algorithms to use. And a device 241 may not support the particular DHT algorithm used by the overlay the 242 device wants to join. Then such a device will have to be a Client 243 even if it has hardware resources and network conditions good enough 244 to be a Peer. This situation would not happen often with devices 245 which can download and install software easily. But small devices 246 with embedded software may be put into in this situation. 248 There are also other reasons why a device should not become a peer: 250 Even if it is possible to traverse NATs and firewalls, every 251 additional connection that has to be maintained with other peers in 252 the overlay will cause the battery of battery powered devices to 253 drain faster. If a device acts as a Client, it needs to maintain 254 only one connection with the overlay (a connection with a peer). 255 Besides the power consumption is impacted by maintenance of the 256 routing state and by routing incoming messages. As measurements 257 shown these operations have huge impact on how long a battery-powered 258 device can stay online without recharging. Nor the device user, nor 259 the overlay network operator benefits by enforcing the mobile devices 260 to be Peers and their battery to drain quickly. Such policy will 261 push away mobile device users from the overlay. 263 Operating on battery does not mean necessarily that the device should 264 be or wants to be a Client. For example, mobile devices in an 265 emergency situation running in an ad-hoc fashion might have to be 266 Peers since there is no other kind of devices to be Peers. Besides 267 the battery consumption caused by maintenance of the routing state 268 and by routing incoming messages can be reasonable in small overlays. 270 In mobile communication using P2PSIP, the consumptions of rare mobile 271 bandwidth in the access networks due to P2PSIP traffic will be 272 significantly reduced if mobile devices become more Clients and less 273 P2PSIP peers as possible (assuming there are enough non-mobile 274 devices being Peers). Besides we have to remember that bandwidth is 275 expensive. If someone has to pay for every packet her/his device 276 exchanges, probably having the device be a Peer makes no economical 277 sense to the her/him especially that the overlay maintenance and 278 routing of incoming messages are not directly linked to the service 279 usage. 281 A device may not meet the requirements of Peers for the particular 282 overlay desired by the overlay operator. For example, the OpenDHT is 283 built with nodes on PlanetLab. Any devices that use the OpenDHT 284 become a kind of Client. This was the choice of the people that 285 designed and built the OpenDHT. Probably they needed access and 286 control to the nodes to participate in the DHT that is not available 287 in general devices. A similar thing may happen that an overlay 288 operator wants only certain devices to be Peers due to various 289 reasons such as high security requirements. For example, only 290 devices that were authenticated using offline means may be allowed be 291 a Peer or only devices that have been a Client for a long time 292 without any bad behavior may be allowed to be a Peer or a devices 293 that have enough fast network interface and uptime can become a peer. 295 5. What functions a client can contribute in P2P layer 297 Clients get services from the overlay network, however, clients can 298 also contribute varialbe useful functions to the overlay. For 299 example, a client can provide STUN server function to help establish 300 connections between other peers, and also other useful functions. We 301 focus on several functions that a client can contribute to the 302 overlay in P2P layer here. 304 5.1. Storage function by a Client 306 In DHT, a Peer is responsible for storing data (resource (user) 307 records) of a certain range of Resource IDs. For example, in Pastry/ 308 Bamboo/OpenDHT, data (resource (user) records) are assigned to a Peer 309 whose Node ID is closest to the Resource IDs than any other Peers. 311 It is possible for a Peer to delegate actual storage of the data to 312 another node and just keep a pointer (location information) to the 313 data in a different node. For example, a Peer may have a remote 314 storage device and uses it as actual storage for the data the Peer is 315 responsible for. Such a remote storage device may be another Peer, a 316 Client, or a node not involved in the overlay at all. In this 317 situation, any lookup message for the data will be routed to the Peer 318 responsible for storing the data (Responsible Peer) and it is the 319 responsibility of the Responsible Peer to reply to the lookup message 320 with the data or a pointer to a node where the data is located. This 321 is how a typical DHT operates. It should be transparent to other 322 Peers whether a Peer uses its local memory or disk or remote memory 323 or disk to store the data it is responsible for. 325 Whether to allow a Client to be a remote storage for a Peer (or 326 multiple Peers) does not affect the overlay operation significantly 327 because it is a local arrangement between the respective Peer(s) and 328 the Client. However it affects the design of the protocol used 329 between Peer and Client. 331 The reason for a device to become a Client instead of a Peer must not 332 depend on the decision whether a Client may serve as a remote storage 333 for a Peer or not. 335 Many of the reasons a device to become a Client rather than become a 336 Peer make the device unsuitable to provide the storage service. For 337 example, if a device is online only intermittently, storing data in 338 such a device does not bring much benefit. However there is a case a 339 Client may be able to store data for its associated Peers. It is 340 when the device became a Client because it did not support the 341 overlay's DHT algorithm while it met other requirements for a Peer. 343 In a sense, it is better for the overlay if some of its Clients can 344 provide the storage service since the overlay's overall storage 345 capacity increases. We need to look into two aspects: 346 - How much complexity is introduced to allow Clients to provide 347 the storage service? 348 - Is the benefit of having Clients provide the storage service 349 large enough? 351 More thought will be given to these questions. 353 5.2. P2P Relay function by a client 355 In some scenarios like for real time applications, a larger number of 356 Peers is not necessarily beneficial, therefore there is probability 357 that some capable devices act as clients in the overlay. These 358 devices have the ability to relay messages for other devices. 360 A node behind strict firewall/NAT may need a relay when it wants to 361 communicate with others. Generally, it can route messages with the 362 overlay routing, however, for more efficiency, it can use a "Relay" 363 with public address to relay requests or responses when it knows the 364 contact address of the other party. All capable peers or clients can 365 act as Relays. The choice of Relays must be well designed for some 366 criterions, e.g. proximity. The best choice of Relay for a peer or 367 client may be a peer or a client. Not in all cases can peer Relays 368 be more efficient than client Relays. 370 Clients that provide relay function do not need to understand the DHT 371 algorithm of the overlay. It only provides relay service to a 372 certain peer or client that needs its help for communication 373 convenience. 375 We only focus on the relay function for P2P layer communication here, 376 e.g., P2P requests or responses. All relay functions beyond those 377 are out of scope. 379 6. Acknowledgments 381 Some of the idea described in the draft came from the discussion in 382 the P2PSIP mailing list. Thanks to Henning Schulzrinne,Henry 383 Sinreich, and Lichun Li 385 7. Security Considerations 387 Clients (providing no storage service) are free riders. If not many 388 devices qualifed to be a Peer do not volunterr to be a Peer, the 389 P2PSIP network may not work well. It is a concern for P2P networks 390 in general. 392 8. IANA Considerations 394 There are no IANA considerations associated to this memo. 396 9. References 398 9.1. Normative References 400 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 401 Levels", BCP 14, RFC 2119, March 1997. 403 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 404 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 405 Session Initiation Protocol", RFC 3261, June 2002. 407 9.2. Informative References 409 [3] Bryan, D., Matthew, Shim, E., and D. Willis, "Concepts and 410 Terminology for Peer to Peer SIP", Internet Draft draft- 411 ietf=p2psip-concepts-00, June 2007. 413 [4] Bryan, D., Baset, S., Matuszewski, M., and Sinreich, "P2PSIP 414 Protocol Framework and Requirements", Internet 415 Draft draft-bryan-p2psip-requirements-00, June 2007. 417 [5] Jennings, C., Lowekamp, B., Rescorla, E., and Rosenberg, 418 "REsource LOcation And Discovery (RELOAD)", Internet 419 Draft draft-bryan-p2psip-reload-02, November 2007. 421 [6] Baset, S., Schulzrinne, H., and M. Matuszweski, "Peer-to-Peer 422 Protocol (P2PP)", Internet Draft draft-baset-p2psip-p2pp-01, 423 November 2007. 425 [7] Song, Y., Jiang, X., Zheng, H., and H. Deng, "P2PSIP Client 426 Protocol", Internet Draft draft-zheng-p2psip-client-protocol-01, 427 February 2008. 429 [8] Jiang, X., Zheng, H., Macian, C., and V. Pascual, "Service 430 Extensible P2P Peer Protocol", Internet 431 Draft draft-jiang-p2psip-sep-01, February 2008. 433 [9] Li, L Ch. and Y. Wang, "Different types of nodes in P2PSIP", 434 Internet Draft draft-li-p2psip-node-types-00, November 2007. 436 Authors' Addresses 438 Victor Pascual 439 Pompeu Fabra University 440 Barcelona, Passeig de la Circumval.lacio 8 08003 441 Spain 443 Phone: +34-93-5421561 444 Fax: +34-93-5422517 445 Email: victor.pascuala@upf.edu 447 Marchin Matuszewski 448 Nokia 449 P.O.Box 407 450 NOKIA GROUP, FIN 00045 451 Finland 453 Phone: unlisted 454 Email: marcin.matsuszewski@nokia.com 456 Eunsoo Shim 457 Locus Telecommunications 458 111 Sylvan Avenue 459 Englewood Cliffs, New Jersey 07632 460 USA 462 Phone: unlisted 463 Email: eunsooshim@gmail.com 465 Hewen Zheng 466 Huawei Technologies 467 Baixia Road No. 91 468 Nanjing, Jiangsu Province 210001 469 PRC 471 Phone: +86-25-84565467 472 Fax: +86-25-84565354 473 Email: hwzheng@huawei.com 474 Song Yongchao 475 Huawei Technologies 476 Baixia Road No. 91 477 Nanjing, Jiangsu Province 210001 478 PRC 480 Phone: +86-25-84565081 481 Fax: +86-25-84565070 482 Email: melodysong@huawei.com 484 Full Copyright Statement 486 Copyright (C) The IETF Trust (2008). 488 This document is subject to the rights, licenses and restrictions 489 contained in BCP 78, and except as set forth therein, the authors 490 retain all their rights. 492 This document and the information contained herein are provided on an 493 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 494 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 495 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 496 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 497 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 498 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 500 Intellectual Property 502 The IETF takes no position regarding the validity or scope of any 503 Intellectual Property Rights or other rights that might be claimed to 504 pertain to the implementation or use of the technology described in 505 this document or the extent to which any license under such rights 506 might or might not be available; nor does it represent that it has 507 made any independent effort to identify any such rights. Information 508 on the procedures with respect to rights in RFC documents can be 509 found in BCP 78 and BCP 79. 511 Copies of IPR disclosures made to the IETF Secretariat and any 512 assurances of licenses to be made available, or the result of an 513 attempt made to obtain a general license or permission for the use of 514 such proprietary rights by implementers or users of this 515 specification can be obtained from the IETF on-line IPR repository at 516 http://www.ietf.org/ipr. 518 The IETF invites any interested party to bring to its attention any 519 copyrights, patents or patent applications, or other proprietary 520 rights that may cover technology that may be required to implement 521 this standard. Please address the information to the IETF at 522 ietf-ipr@ietf.org.