idnits 2.17.1 draft-jiang-p2psip-relay-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If IGNORE-STATE-KEEPING is set, any peer receiving this message and which is not the destination of the message MUST forward the message with the full VIA list and MUST not maintain any internal state. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 10, 2011) is 4788 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'ChurnDHT' is defined on line 923, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-behave-tcp' is defined on line 936, but no explicit reference was found in the text == Unused Reference: 'I-D.lowekamp-mmusic-ice-tcp-framework' is defined on line 940, but no explicit reference was found in the text == Unused Reference: 'RFC4787' is defined on line 946, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-12 == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-03 ** Downref: Normative reference to an Informational draft: draft-ietf-p2psip-concepts (ref. 'I-D.ietf-p2psip-concepts') == Outdated reference: A later version (-08) exists of draft-ietf-behave-nat-behavior-discovery-04 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP X. Jiang 3 Internet-Draft N. Zong 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 11, 2011 R. Even 6 Gesher Erove 7 Y. Zhang 8 China Mobile 9 March 10, 2011 11 An extension to RELOAD to support Direct Response and Relay Peer routing 12 draft-jiang-p2psip-relay-05 14 Abstract 16 This document proposes an optional extension to RELOAD to support 17 direct response and relay peer routing modes. RELOAD recommends 18 symmetric recursive routing for routing messages. The new optional 19 extensions provide a shorter route for responses reducing the 20 overhead on intermediary peers and describe the potential cases where 21 these extensions can be used. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 11, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1.1. Backgrounds . . . . . . . . . . . . . . . . . . . . . . . 5 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.1.1. Symmetric Recursive Routing (SRR) . . . . . . . . . . 7 75 3.1.2. Direct Response Routing (DRR) . . . . . . . . . . . . 7 76 3.1.3. Relay Peer Routing (RPR) . . . . . . . . . . . . . . . 8 77 3.2. Scenarios Where DRR can be Used . . . . . . . . . . . . . 9 78 3.2.1. Managed or Closed P2P System . . . . . . . . . . . . . 9 79 3.2.2. Wireless Scenarios . . . . . . . . . . . . . . . . . . 9 80 3.3. Scenarios Where RPR Benefits . . . . . . . . . . . . . . . 10 81 3.3.1. Managed or Closed P2P System . . . . . . . . . . . . . 10 82 3.3.2. Using Bootstrap Peers as Relay Peers . . . . . . . . . 10 83 3.3.3. Wireless Scenarios . . . . . . . . . . . . . . . . . . 10 84 4. Relationship Between SRR and DRR/RPR . . . . . . . . . . . . . 10 85 4.1. How DRR Works . . . . . . . . . . . . . . . . . . . . . . 10 86 4.2. How RPR Works . . . . . . . . . . . . . . . . . . . . . . 11 87 4.3. How These Three Routing Modes Work Together . . . . . . . 11 88 5. Comparison on cost of SRR and DRR/RPR . . . . . . . . . . . . 12 89 5.1. Closed or managed networks . . . . . . . . . . . . . . . . 12 90 5.2. Open networks . . . . . . . . . . . . . . . . . . . . . . 13 91 6. Extensions to RELOAD . . . . . . . . . . . . . . . . . . . . . 14 92 6.1. Basic Requirements . . . . . . . . . . . . . . . . . . . . 14 93 6.2. Modification To RELOAD Message Structure . . . . . . . . . 14 94 6.2.1. State-keeping Flag . . . . . . . . . . . . . . . . . . 14 95 6.2.2. Extensive Routing Mode . . . . . . . . . . . . . . . . 15 96 6.3. Creating a Request . . . . . . . . . . . . . . . . . . . . 15 97 6.3.1. Creating a Request for DRR . . . . . . . . . . . . . . 15 98 6.3.2. Creating a request for RPR . . . . . . . . . . . . . . 16 99 6.4. Request And Response Processing . . . . . . . . . . . . . 16 100 6.4.1. Destination Peer: Receiving a Request And Sending 101 a Response . . . . . . . . . . . . . . . . . . . . . . 17 102 6.4.2. Sending Peer: Receiving a Response . . . . . . . . . . 17 103 6.4.3. Relay Peer Processing . . . . . . . . . . . . . . . . 17 104 7. Discovery Of Relay Peer . . . . . . . . . . . . . . . . . . . 18 105 8. Optional Methods to Investigate Node Connectivity . . . . . . 18 106 8.1. Getting Addresses To Be Used As Candidates for DRR . . . . 19 107 8.2. Public Reachability Test . . . . . . . . . . . . . . . . . 20 108 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 109 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 110 10.1. A new RELOAD Forwarding Option . . . . . . . . . . . . . . 21 111 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 113 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 114 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 118 1. Introduction 120 1.1. Backgrounds 122 RELOAD [I-D.ietf-p2psip-base] recommends symmetric recursive routing 123 (SRR) for routing messages and describes the extensions that would be 124 required to support additional routing algorithms. Other than SRR, 125 two other routing options: direct response routing (DRR) and relay 126 peer routing (RPR) are also discussed in Appendix D in [I-D.ietf- 127 p2psip-base]. As we show in section 3, DRR and RPR are advantageous 128 over RPR in some scenarios reducing load (CPU and link BW) on 129 intermediary peers . For example, in a closed network where every 130 node is in the same address realm, DRR performs better than SRR. On 131 the other hand, RPR works better in a network where relay peers are 132 provisioned in advance so that relay peers are publicly reachable in 133 the P2P system. In other scenarios, using a combination of these 134 three routing modes together is more likely to bring benefits than if 135 SRR is used alone. Some discussion on connectivity is in Non- 136 Transitive Connectivity and DHTs 137 [http://srhea.net/papers/ntr-worlds05.pdf]. 139 In this draft, we first discuss the problem statement, then the 140 relationship between the three routing modes is presented. In 141 Section 5, we give comparison on the cost of SRR, DRR and RPR in both 142 managed and open networks. An extension to RELOAD to support DRR and 143 RPR is proposed in Section 6. 145 2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 We use the terminology and definitions from the Concepts and 152 Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts] draft 153 extensively in this document. We also use terms defined in NAT 154 behavior discovery [I-D.ietf-behave-nat-behavior-discovery]. Other 155 terms used in this document are defined inline when used and are also 156 defined below for reference. 158 There are two types of roles in the RELOAD architecture: peer and 159 client. Node is used when describing both peer and client. In 160 discussions specific to behavior of a peer or client, the term peer 161 or client is used instead. 163 Publicly Reachable: A node is publicly reachable if it can receive 164 unsolicited messages from any other node in the same overlay. Note: 166 "publicly" does not mean that the nodes must be on the public 167 Internet, because the RELOAD protocol may be used in a closed system. 169 Relay Peer: A type of publicly reachable peer that can receive 170 unsolicited messages from all other nodes in the overlay and forward 171 the responses from destination peers towards the request sender. 173 Direct Response Routing (DRR): refers to a routing mode in which 174 responses to P2PSIP requests are returned to the sending peer 175 directly from the destination peer based on the sending peer's own 176 local transport address(es). For simplicity, the abbreviation DRR is 177 used instead in the following text. 179 Relay Peer Routing (RPR): refers to a routing mode in which responses 180 to P2PSIP requests are sent by the destination peer to a relay peer 181 transport address who will forward the responses towards the sending 182 peer. For simplicity, the abbreviation RPR is used instead in the 183 following text. 185 Symmetric Recursive Routing(SRR): refers to a routing mode in which 186 responses follow the request path in the reverse order to get back to 187 the sending peer. For simplicity, the abbreviation SRR is used 188 instead in the following text. 190 3. Problem Statement 192 RELOAD is expected to work under a great number of application 193 scenarios. The situations where RELOAD is to be deployed differ 194 greatly. For instance, some deployments are global, such as a Skype- 195 like system intended to provide public service. Some run in closed 196 networks of small scale. SRR works in any situation, but DRR and RPR 197 may work better in some specific scenarios. 199 3.1. Overview 201 RELOAD is a simple request-response protocol. After sending a 202 request, a node waits for a response from a destination node. There 203 are several ways for the destination node to send a response back to 204 the source node. In this section, we will provide detailed 205 information on three routing modes: SRR, DRR and RPR. 207 Some assumptions are made in the following illustrations. 209 1) Peer A sends a request destined to a peer who is the responsible 210 peer for Resource-ID k; 212 2) Peer X is the root peer being responsible for resource k; 213 3) The intermediate peers for the path from A to X are peer B, C, D. 215 3.1.1. Symmetric Recursive Routing (SRR) 217 For SRR, when the request sent by peer A is received by an 218 intermediate peer B, C or D, each intermediate peer will insert 219 information on the peer from whom they got the request in the via- 220 list as described in RELOAD. As a result, the destination peer X 221 will know the exact path which the request has traversed. Peer X 222 will then send back the response in the reverse path by constructing 223 a destination list based on the via-list in the request. 225 A B C D X 226 | Request | | | | 227 |----------->| | | | 228 | | Request | | | 229 | |----------->| | | 230 | | | Request | | 231 | | |----------->| | 232 | | | | Request | 233 | | | |----------->| 234 | | | | | 235 | | | | Response | 236 | | | |<-----------| 237 | | | Response | | 238 | | |<-----------| | 239 | | Response | | | 240 | |<-----------| | | 241 | Response | | | | 242 |<-----------| | | | 243 | | | | | 245 SRR works in any situation, especially when there are NATs or 246 firewalls. A downside of this solution is that the message takes 247 several hops to return to the client, increasing the bandwidth usage 248 and CPU/battery load of multiple nodes. 250 3.1.2. Direct Response Routing (DRR) 252 In DRR, peer X receives the request sent by peer A through 253 intermediate peer B, C and D, as in SRR. However, peer X sends the 254 response back directly to peer A based on peer A's local transport 255 address. In this case, the response won't be routed through 256 intermediate peers. Shorter route means less overhead on 257 intermediary peers, especially in the case of wireless network where 258 the CPU and uplink BW is limited. In the absence of NATs or other 259 connectivity issues, this is the optimal routing technique. Note 260 that secure connection requires multiple round trips. Please refer 261 to Section 5 for cost comparison between SRR, DRR/RPR. 263 A B C D X 264 | Request | | | | 265 |----------->| | | | 266 | | Request | | | 267 | |----------->| | | 268 | | | Request | | 269 | | |----------->| | 270 | | | | Request | 271 | | | |----------->| 272 | | | | | 273 | | | | Response | 274 |<-----------+------------+------------+------------| 275 | | | | | 277 3.1.3. Relay Peer Routing (RPR) 279 If peer A knows it is behind a NAT or NATs, and knows one or more 280 relay peers with whom they have a prior connections, peer A can try 281 RPR. Assume A is associated with relay peer R. When sending the 282 request, peer A includes information describing peer R transport 283 address in the request. When peer X receives the request, peer X 284 sends the response to peer R, which forwards it directly to Peer A on 285 the existing connection. Note that RPR also allows a shorter route 286 for responses compared to SRR, which means less overhead on 287 intermediary peers. Establishing a connection to the relay with TLS 288 requires multiple round trips. Please refer to Section 5 for cost 289 comparison between SRR, DRR/RPR. 291 This technique relies on the relative population of nodes such as A 292 that require relay peers and peers such as R that are capable of 293 serving as a relay peers. It also requires mechanism to enable peers 294 to know which nodes can be used as their relays. This mechanism may 295 be based on configuration, for example as part of the overlay 296 configuration an initial list of relay peers can be supplied. 297 Another option is in a response to ATTACH request the peer can signal 298 that it can be used as a relay peer. 300 A B C D X R 301 | Request | | | | | 302 |----------->| | | | | 303 | | Request | | | | 304 | |----------->| | | | 305 | | | Request | | | 306 | | |----------->| | | 307 | | | | Request | | 308 | | | |----------->| | 309 | | | | | Response | 310 | | | | |---------->| 311 | | | | Response | | 312 |<-----------+------------+------------+------------+-----------| 313 | | | | | | 315 3.2. Scenarios Where DRR can be Used 317 This section lists several scenarios where using DRR would work, and 318 when the increased efficiency would be advantageous. 320 3.2.1. Managed or Closed P2P System 322 The properties that make P2P technology attractive, such as the lack 323 of need for centralized severs, self-organization, etc. are 324 attractive for managed systems as well as unmanaged systems. Many of 325 these systems are deployed on private network where nodes are in the 326 same address realm and/or can directly route to each other. In such 327 a scenario, the network administrator can indicate preference for DRR 328 in the peer's configuration file. Peers in such a system would 329 always try DRR first, but peers must also support SRR in case DRR 330 fails. If during the process of establishing a direct connection the 331 responding peer receives a retransmit on a request with SRR as the 332 preferred routing mode he should stop trying to establish a direct 333 connection and use SRR. A node can keep a list of unreachable nodes 334 based on trying DRR and use only SRR for these nodes. The advantage 335 in using DRR is on the network stability since it puts less overhead 336 on the intermediary peers that will not route the responses. The 337 intermediary peers will need to route less messages and save CPU 338 resources as well as the link bandwidth usage. 340 3.2.2. Wireless Scenarios 342 While some mobile deployments may use clients, in mobile networks 343 with full peers, there is an advantage to using DRR in order to 344 reduce the load on intermediary nodes. Using DRR helps with reducing 345 radio battery usage and bandwidth by the intermediary peers. The 346 service provider may recommend in the configuration using DRR based 347 on his knowledge of the topology. 349 3.3. Scenarios Where RPR Benefits 351 In this section, we will list several scenarios where using RPR would 352 provide improved performance. 354 3.3.1. Managed or Closed P2P System 356 As described in Section 3.2.1, many P2P systems run in a closed or 357 managed environment so that network administrators can better manage 358 their system. For example, the network administrator can deploy 359 several relay peers which are publicly reachable in the system and 360 indicate their presence in the configuration file. After learning 361 where these relay peers are, peers behind NATs can use RPR with the 362 help from these relay peers. As with DRR, peers must also support 363 SRR in case RPR fails. 365 Another usage is to install relay peers on the managed network 366 boundary allowing external peers to send responses to peers inside 367 the managed network. 369 3.3.2. Using Bootstrap Peers as Relay Peers 371 Bootstrap peers must be publicly reachable in a RELOAD architecture. 372 As a result, one possible architecture would be to use the bootstrap 373 peers as relay peers for use with RPR. The requirements for being a 374 relay peer are publicly accessible and maintaining a direct 375 connection with its client. As such, bootstrap peers are well suited 376 to play the role of relay peers. 378 3.3.3. Wireless Scenarios 380 While some mobile deployments may use clients, in mobile networks 381 using peers, RPR, like DRR, may reduce radio battery usage and 382 bandwidth usage by the intermediary peers. The service provider may 383 recommend in the configuration using RPR based on his knowledge of 384 the topology. Such relay peers may also help connectivity to 385 external networks. 387 4. Relationship Between SRR and DRR/RPR 389 4.1. How DRR Works 391 DRR is very simple. The only requirement is for the source peers to 392 provide their (publically reachable) transport address to the 393 destination peers, so that the destination peer knows where to send 394 the response. Responses are sent directly to the requesting peer. 396 4.2. How RPR Works 398 RPR is a bit more complicated than DRR. Peers using RPR must 399 maintain a connection with their relay peer(s). This can be done in 400 the same way as establishing a neighbor connection between peers by 401 using the Attach method. 403 A requirement for RPR is for the source peer to convey their relay 404 peer (or peers) transport address in the request, so the destination 405 peer knows where the relay peer are and send the response to a relay 406 peer first. The request should include also the requesting peer 407 information enabling the relay peer to route the response back to the 408 right peer. 410 (Editor's Note: Being a relay peer does not require that the relay 411 peer have more functionality than an ordinary peer. As discussed 412 later, relay peers comply with the same procedure as an ordinary peer 413 to forward messages. The only difference is that there may be a 414 larger traffic burden on relay peers. Relay peers can decide whether 415 to accept a new connection based on their current burden.) 417 4.3. How These Three Routing Modes Work Together 419 DRR and RPR are not intended to replace SRR. As seen from Section 3, 420 DRR or RPR have better performance in some scenarios, but have 421 limitations as well, see for example section 4.3 in Non-Transitive 422 Connectivity and DHTs [http://srhea.net/papers/ntr-worlds05.pdf]. As 423 a result, it is better to use these three modes together to adapt to 424 each peer's specific situation. In this section, we give some 425 suggestions on how to transition between the routing modes in RELOAD. 427 Editor's Note: What this draft proposes are optional extensions to 428 support DRR/RPR. There is no requirement for implementation to use 429 the strategy described to choose the appropriate mode. 431 A peer can collect statistical data on the success of the different 432 routing modes based on previous transactions and keep a list of non- 433 reachable addresses. Based on the data, the peer will have a clearer 434 view about the success rate of different routing modes. Other than 435 the success rate, the peer can also get data of fine granularity, for 436 example, the number of retransmission the peer needs to achieve a 437 desirable success rate. 439 A typical strategy for the node is as follows. A node chooses to 440 start with DRR or RPR. Based on the success rate as seen from the 441 lost message statistics or responses that used SRR, the node can 442 either continue to offer DRR/RPR first or switch to SRR. 444 The node can decide whether to try DRR or RPR based on other 445 information such as configuration file information. If an overlay 446 runs within a private network and all nodes in the system can reach 447 each other directly, nodes may send most of the transactions with 448 DRR. If a relay peer is provided by the service provider, nodes may 449 prefer RPR over SRR. 451 5. Comparison on cost of SRR and DRR/RPR 453 The major advantages in using DRR/RPR are in going through less 454 intermediary peers on the response. By doing that it reduces the 455 load on those peers' resources like processing and communication 456 bandwidth. 458 5.1. Closed or managed networks 460 As described in Section 3, many P2P systems run in a closed or 461 managed environment (e.g. carrier networks) so that network 462 administrators would know that they could safely use DRR/RPR. 464 SRR brings out more routing hops than DRR and RPR. Assuming that 465 there are N nodes in the P2P system and Chord is applied for routing, 466 the number of hops for a response in SRR, DRR and RPR are listed in 467 the following table. Establishing a secure connection between 468 sending/relay peer and responding peer with (D)TLS requires multiple 469 messages. Note that establishing (D)TLS secure connections for P2P 470 overlay is not optimal in some cases, e.g. direct response routing 471 where (D)TLS is heavy for temporary connections. Instead, some 472 alternate security techniques, e.g. using public keys of the 473 destination to encrypt the messages, signing timestamps to prevent 474 reply attacks can be adopted. Therefore, in the following table, we 475 show the cases of: 1) no (D)TLS in DRR/RPR; 2) still using DTLS in 476 DRR/RPR as sub-optimal and, as the worst-cost case, 7 messages are 477 used during the DTLS handshaking [DTLS]. (TLS Handshake is two 478 round-trip negotiation protocol while DTLS handshake is three round- 479 trip negotiation protocol.) 481 Mode | Success | No. of Hops | No. of Msgs 482 ---------------------------------------------------- 483 SRR | Yes | logN | logN 484 DRR | Yes | 1 | 1 485 RPR | Yes | 2 | 2 486 DRR(DTLS) | Yes | 1 | 7+1 487 RPR(DTLS) | Yes | 2 | 7+2 489 From the above comparison, it is clear that: 491 1) In most cases of N > 2^2=4, DRR/RPR has fewer hops than SRR. 492 Shorter route means less overhead and resource usage on intermediary 493 peers, which is an important consideration for adopting DRR/RPR in 494 the cases where the resource such as CPU and BW is limited, e.g. the 495 case of mobile, wireless network. 497 2) In the cases of N > 2^9=512, DRR/RPR also has fewer messages than 498 SRR. 500 3) In the cases where 4 < N < 512, DRR/RPR has more messages than SRR 501 (but still has fewer hops than SRR). So the consideration to use 502 DRR/RPR or SRR depends on other factors like using less resources 503 (bandwidth and processing) from the intermediaries peers. Section 4 504 provides use cases where DRR/RPR has better chance to work or where 505 the intermediary resources considerations are important. 507 5.2. Open networks 509 In open network where DRR/RPR is not guaranteed, DRR/RPR can fall 510 back to SRR If it fails after trial, as described in Section 4. 511 Based on the same settings in Section 5.1, the number of hops, number 512 of messages for a response in SRR, DRR and RPR are listed in the 513 following table. 515 Mode | Success | No. of Hops | No. of Msgs 516 ----------------------------------------------------------- 517 SRR | Yes | logN | logN 518 DRR | Yes | 1 | 1 519 | Fail&Fall back to SRR | 1+logN | 1+logN 520 RPR | Yes | 2 | 2 521 | Fail&Fall back to SRR | 2+logN | 2+logN 522 DRR(DTLS) | Yes | 1 | 7+1 523 | Fail&Fall back to SRR | 1+logN | 8+logN 524 RPR(DTLS) | Yes | 2 | 7+2 525 | Fail&Fall back to SRR | 2+logN | 9+logN 527 From the above comparison, it can be observed that: 529 1) Trying DRR/RPR would still have a good chance of fewer hops than 530 SRR. Suppose that P peers are publicly reachable, the number of hops 531 in DRR and SRR is P*1+(N-P)*(1+logN), N*logN, respectively. The 532 condition for fewer hops in DRR is P*1+(N-P)*(1+logN) < N*logN, which 533 is P/N > 1/logN. This means that when the number of peers N grows, 534 the required ratio of publicly reachable peers P/N for fewer hops in 535 DRR decreases. Similar analysis can be easily applied to RPR. 536 Therefore, the chance of trying DRR/RPR with fewer hops than SRR 537 becomes better as the scale of the network increases. 539 2) In the cases of large network and the success rate of DRR/RPR is 540 good, it is still possible that DRR/RPR has fewer messages than SRR. 541 Otherwise, the consideration to use DRR/RPR or SRR depends on other 542 factors like using less resources from the intermediaries peers. 544 6. Extensions to RELOAD 546 Adding support for DRR and RPR requires extensions to the current 547 RELOAD protocol. In this section, we define the changes required to 548 the protocol, including changes to message structure and to message 549 processing. 551 6.1. Basic Requirements 553 All peers implementing DRR or RPR MUST support SRR. 555 All peers MUST be able to process requests for routing in SRR, and 556 MAY support DRR or RPR routing requests. 558 Peers that do not support or do not wish to provide DRR or RPR MAY 559 reject these messages. 561 6.2. Modification To RELOAD Message Structure 563 RELOAD provides an extensible framework to accommodate future 564 extensions. In this section, we define a ForwardingOption structure 565 to support DRR and RPR modes. Additionally we present a state- 566 keeping flag to inform intermediate peers if they are allowed to not 567 maintain state for a transaction. 569 6.2.1. State-keeping Flag 571 RELOAD allows intermediate peers to maintain state in order to 572 implement SRR, for example for implementing hop-by-hop 573 retransmission. If DRR or RPR is used, the response will not follow 574 the reverse path, and the state in the intermediate peers won't be 575 cleared until such state expires. In order to address this issue, we 576 propose a new flag, state-keeping flag, in the message header to 577 indicate whether the state should be maintained in the intermediate 578 peers. 580 flag : 0x3 IGNORE-STATE-KEEPING 582 If IGNORE-STATE-KEEPING is set, any peer receiving this message and 583 which is not the destination of the message MUST forward the message 584 with the full VIA list and MUST not maintain any internal state. 586 6.2.2. Extensive Routing Mode 588 This draft introduces a new forwarding option for an extensive 589 routing mode. This option conforms to the description in section 590 5.3.2.3 in [I-D.ietf-p2psip-base]. 592 We first define a new type to define the new option, 593 EXTENSIVE_ROUTING_MODE_TYPE: 595 The option value will be illustrated in the following figure, 596 defining the ExtensiveRoutingModeOption structure: 598 enum { 0x0, 0x01 (DRR), 0x02(RPR), 255} RouteMode; 599 struct { 600 RouteMode routemode; 601 OverlayLink transport; 602 IpAddressPort ipaddressport; 603 Destination destination<1..2>; 604 } ExtensiveRoutingModeOption; 606 The above structure reuses: Transport, Destination and IpAddressPort 607 structure defined in section 5.3.1.1 and 5.3.2.2 in [I-D.ietf-p2psip- 608 base]. 610 Route mode: refers to which type of routing mode is indicated to the 611 destination peer. Currently, only DRR and RPR are defined. 613 Transport: refers to the transport type which is used to deliver 614 responses from the destination peer to the sending peer or the relay 615 peer. 617 IpAddressPort: refers to the transport address that the destination 618 peer should use to send the response to. This will be a sending node 619 address for DRR and a relay peer address for RPR. 621 Destination: refers to the relay peer or the sending node itself. if 622 the routing mode is DRR, then the destination only contains the 623 sending node's node-id; If the routing mode is RPR, then the 624 destination contains two destinations, which are the relay peer's 625 node-id and the sending node's node-id. 627 6.3. Creating a Request 629 6.3.1. Creating a Request for DRR 631 When using DRR for a transaction, the sending peer MUST set the 632 IGNORE-STATE-KEEPING flag in the ForwardingHeader. Additionally, the 633 peer MUST construct and include a ForwardingOptions structure in the 634 ForwardingHeader. When constructing the ForwardingOption structure, 635 the fields MUST be set as follows: 637 1) The type MUST be set to EXTENSIVE_ROUTING_MODE_TYPE. 639 2) The ExtensiveRoutingModeOption structure MUST be used for the 640 option field within the ForwardingOptions structure. The fields MUST 641 be defined as follows: 643 2.1) RouteMode set to 0x01 (DRR). 645 2.2) Transport set as appropriate for the sender. 647 2.3) IPAddressPort set to the peer's associated transport address. 649 2.4) The destination structure MUST contain one vaule, defined as 650 type peer and set with the sending peer's own values. 652 6.3.2. Creating a request for RPR 654 When using RPR for a transaction, the sending peer MUST set the 655 IGNORE- STATE-KEEPING flag in the ForwardingHeader. Additionally, 656 the peer MUST construct and include a ForwardingOptions structure in 657 the ForwardingHeader. When constructing the ForwardingOption 658 structure, the fields MUST be set as follows: 660 1) The type MUST be set to EXTENSIVE_ROUTING_MODE_TYPE. 662 2) The ExtensiveRoutingModeOption structure MUST be used for the 663 option field within the ForwardingOptions structure. The fields MUST 664 be defined as follows: 666 2.1) RouteMode set to 0x02 (RPR). 668 2.2) Transport set as appropriate for the relay peer. 670 2.3) IPAddressPort set to the transport address of the relay peer 671 that the sender wishes the message to be relayed through. 673 2.4) Destination structure MUST contain two values. The first MUST 674 be defined as type peer and set with the values for the relay peer. 675 The second MUST be defined as type peer and set with the sending 676 peer's own values. 678 6.4. Request And Response Processing 680 This section gives normative text for message processing after DRR 681 and RPR are introduced. Here, we only describe the additional 682 procedures for supporting DRR and RPR. Please refer to [I-D.ietf- 683 p2psip-base] for RELOAD base procedures. 685 6.4.1. Destination Peer: Receiving a Request And Sending a Response 687 When the destination peer receives a request, it will check the 688 options in the forwarding header. If the destination peer can not 689 understand extensive_routing_mode option in the request, it MUST 690 attempt to use SRR to return a error response to the sending peer. 692 If the routing mode is DRR, the peer MUST construct the Destination 693 list for the response with only one entry, using the sending peer's 694 node-id from the option in the request as the value. 696 If the routing mode is RPR, the destination peer MUST construct a 697 Destination list for the response with two entries. The first MUST 698 be set to the relay peer node-id from the option in the request and 699 the second MUST be the sending node node-id from the option of the 700 request. 702 In the event that the routing mode is set to DRR and there is not 703 exactly one destination, or the routing mode is set to RPR and there 704 are not exactly two destinations the destination peer MUST try to 705 send a error response to the sending peer using SRR. 707 After the peer constructs the destination list for the response, it 708 sends the response to the transport address which is indicated in the 709 IpAddressPort field in the option using the specific transport mode 710 in the Forwardingoption. If the destination peer receives a 711 retransmit with SRR preference on the message he is trying to 712 response to now, the responding peer should abort the DRR/RPR 713 response and use SRR. 715 6.4.2. Sending Peer: Receiving a Response 717 Upon receiving a response, the peer follows the rules in [I-D.ietf- 718 p2psip-base]. The peer should note if DRR worked in order to decide 719 if to offer DRR again. If the peer does not receive a response until 720 the timeout it SHOULD resend the request using SRR. 722 If the sender used RPR and does not get a response until the timeout, 723 it MAY either resend the message using RPR but with a different relay 724 peer (if available), or resend the message using SRR. 726 6.4.3. Relay Peer Processing 728 Relay peers are designed to forward responses to nodes who are not 729 publicly reachable. For the routing of the response, this draft 730 still uses the destination list. The only difference from SRR is 731 that the destination list is not the reverse of the via-list, instead 732 it is constructed from the forwarding option as described below. 734 When a relay peer receives a response, it MUST follow the rules in 735 [I-D.ietf-p2psip-base]. It receives the response, validates the 736 message, re-adjust the destination-list and forward the response to 737 the next hop in the destination list based on the connection table. 738 There is no added requirement for relay peer. 740 7. Discovery Of Relay Peer 742 There are several ways to distribute the information about relay 743 peers throughout the overlay. P2P network providers can deploy some 744 relay peers and advertise them in the configuration file. With the 745 configuration file at hand, peers can get relay peers to try RPR. 746 Another way is to consider relay peer as a service and then some 747 service advertisement and discovery mechanism can also be used for 748 discovering relay peers, for example, using the same mechanism as 749 used in TURN server discovery in base RELOAD [I-D.ietf-p2psip-base]. 750 Another option is to let a peer advertise his capability to be a 751 relay in the response to ATTACH or JOIN. 753 Editor note: This section will be extended if we adopt RPR, but like 754 other configuration information, there may be many ways to obtain 755 this. 757 8. Optional Methods to Investigate Node Connectivity 759 This section is for informational purposes only for providing some 760 mecahnsism that can be used when the configuration information does 761 not specify if DRR or RPR can be used. It summarizes some methods 762 which can be used for a node to determine its own network location 763 compared with NAT. These methods may help a node to decide which 764 routing mode it may wish to try. Note that there is no foolproof way 765 to determine if a node is publically reachable, other than via out- 766 of-band mechanisms. As such, peers using these mechanisms may be 767 able to optimize traffic, but must be able to fall back to SRR 768 routing if the other routing mechanisms fail. 770 For DRR and RPR to function correctly, a node may attempt to 771 determine whether it is publicly reachable. If it is not, RPR may be 772 chosen to route the response with the help from relay peers, or the 773 peers should fall back to SRR. If the peer believes it is publically 774 reachable, DRR may be attempted. NATs and firewalls are two major 775 contributors preventing DRR and RPR from functioning properly. There 776 are a number of techniques by which a node can get its reflexive 777 address on the public side of the NAT. After obtaining the reflexive 778 address, a peer can perform further tests to learn whether the 779 reflexive address is publicly reachable. If the address appears to 780 be publicly reachable, the nodes to which the address belongs can use 781 DRR for responses and can also be a candidate to serve as a relay 782 peer. Nodes which are not publicly reachable may still use RPR to 783 shorten the response path with the help from relay peers. 785 Some conditions are unique in P2PSIP architecture which could be 786 leveraged to facilitate the tests. In P2P overlay network, each node 787 only has partial a view of the whole network, and knows of a few 788 nodes in the overlay. P2P routing algorithms can easily deliver a 789 request from a sending node to a peer with whom the sending node has 790 no direct connection. This makes it easy for a node to ask other 791 nodes to send unsolicited messages back to the requester. 793 In the following sections, we first introduce several ways for a node 794 to get the addresses needed for the further tests. Then a test for 795 learning whether a peer may be publicly reachable is proposed. 797 8.1. Getting Addresses To Be Used As Candidates for DRR 799 In order to test whether a peer may be publicly reachable, the node 800 should first get one or more addresses which will be used by other 801 nodes to send him messages directly. This address is either a local 802 address of a node or a translated address which is assigned by a NAT 803 to the node. 805 STUN is used to get a reflexive address on the public side of a NAT 806 with the help of STUN servers. There is also a STUN usage [I-D.ietf- 807 behave-nat-behavior-discovery] to discover NAT behavior. Under 808 RELOAD architecture, a few infrastructure servers can be leveraged 809 for this usage, such as enrollment servers, diagnostic servers, 810 bootstrap servers, etc. 812 The node can use a STUN Binding request to one of STUN servers to 813 trigger a STUN Binding response which returns the reflexive address 814 from the server's perspective. If the reflexive transport address is 815 the same as the source address of the Binding request, the node can 816 determine that there likely is no NAT between him and the chosen 817 infrastructure server. (Certainly, in some rare cases, the allocated 818 address happens to be the same as the source address. Further tests 819 will detect this case and rule it out in the end.). Usually, these 820 infrastructure severs are publicly reachable in the overlay, so the 821 node can be considered publicly reachable. On the other hand, with 822 the techniques in [I-D.ietf-behave-nat-behavior-discovery], a node 823 can also decide whether it is behind NAT with endpoint-independent 824 mapping behavior. If the node is behind a NAT with endpoint- 825 independent mapping behavior, the reflexive address should also be a 826 candidate for further tests. 828 UPnP-IGD is a mechanism that a node can use to get the assigned 829 address from its residential gateway and after obtaining this address 830 to communicate it with other nodes, the node can receive unsolicited 831 messages from outside, even though it is behind a NAT. So the 832 address obtained through the UPnP mechanism should also be used for 833 further tests. 835 Another way that a node behind NAT can use to learn its assigned 836 address by NAT is NAT-PMP. Like in UPnP-IGD, the address obtained 837 using this mechanism should also be tested further. 839 The above techniques are not exhaustive. These techniques can be 840 used to get candidate transport addresses for further tests. 842 8.2. Public Reachability Test 844 Using the transport addresses obtained by the above techniques, a 845 node can start a test to learn whether the candidate transport 846 address is publicly reachable. The basic idea for the test is for a 847 node to send a request and expect another node in the overlay to send 848 back a response. If the response is received by the sending node 849 successfully and also the node giving the response has no direct 850 connection with the sending node, the sending node can determine that 851 the address is probably publicly reachable and hence the node may be 852 publicly reachable at the tested transport address. 854 In P2P overlay, a request is routed through the overlay and finally a 855 destination peer will terminate the request and give the response. 856 In a large system, there is a high probability that the destination 857 peer has no direct connection with the sending node. Especially in 858 RELOAD architecture, every node maintains a connection table. So it 859 is easier for a node to check whether it has direct connection with 860 another node. 862 Note: Currently, no existing message in base RELOAD can achieve the 863 test. In our opinion, this kind of test is within diagnostic scope, 864 so authors hope WG can define a new diagnostic message to do that. 865 We don't plan to define the message in this document, for the 866 objective of this draft is to propose an extension to support DRR and 867 RPR. The following text is informative. 869 If a node wants to test whether its transport address is publicly 870 reachable, it can send a request to the overlay. The routing for the 871 test message would be different from other kinds of requests because 872 it is not for storing/fetching something to/from the overlay or 873 locating a specific node, instead it is to get a peer who can deliver 874 the sending node an unsolicited response and which has no direct 875 connection with him. Each intermediate peer receiving the request 876 first checks whether it has a direct connections with the sending 877 peer. If there is a direct connection, the request is routed to the 878 next peer. If there is no direct connection, the intermediate peer 879 terminates the request and sends the response back directly to the 880 sending node with the transport address under test. 882 After performing the test, if the peer determines that it may be 883 publicly reachable, it can try DRR in subsequent transaction, and may 884 advertise that it is a candidate to serve as a relay peer. 886 9. Security Considerations 888 TBD 890 10. IANA Considerations 892 10.1. A new RELOAD Forwarding Option 894 A new RELOAD Forwarding Option type is add to the Registry. 896 Type: 0x1 - extensive_routing_mode 898 11. Acknowledgements 900 David Bryan has helped extensively with this document, and helped 901 provide some of the text, analysis, and ideas contained here. The 902 authors would like to thank Ted Hardie, Narayanan Vidya, Dondeti 903 Lakshminath and Bruce Lowekamp for their constructive comments. 905 12. References 907 12.1. Normative References 909 [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., 910 Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery 911 (RELOAD) Base Protocol", draft-ietf-p2psip-base-12 (work in 912 progress), March 2010. 914 [I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis, 915 D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", 916 draft-ietf-p2psip-concepts-03 (work in progress), October 2010. 918 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 919 Requirement Levels", BCP 14, RFC 2119, March 1997. 921 12.2. Informative References 923 [ChurnDHT] Rhea, S., "Handling Churn in a DHT", Proceedings of the 924 USENIX Annual Technical Conference. Handling Churn in a DHT, June 925 2004. 927 [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation of 928 Datagram TLS", 11th Network and Distributed System Security Symposium 929 (NDSS), 2004. 931 [I-D.ietf-behave-nat-behavior-discovery] MacDonald, D. and B. 932 Lowekamp, "NAT Behavior Discovery Using STUN", 933 draft-ietf-behave-nat-behavior-discovery-04 (work in progress), July 934 2008. 936 [I-D.ietf-behave-tcp] Guha, S., Biswas, K., Ford, B., Sivakumar, S., 937 and P. Srisuresh, "NAT Behavioral Requirements for TCP", 938 draft-ietf-behave-tcp-08 (work in progress), September 2008. 940 [I-D.lowekamp-mmusic-ice-tcp-framework] Lowekamp, B. and A. Roach, "A 941 Proposal to Define Interactive Connectivity Establishment for the 942 Transport Control Protocol (ICE-TCP) as an Extensible Framework", 943 draft-lowekamp-mmusic-ice-tcp-framework-00 (work in progress), 944 October 2008. 946 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 947 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, 948 January 2007. 950 Authors' Addresses 952 Xingfeng Jiang 953 Huawei Technologies 955 Email: jiang.x.f@huawei.com 957 Ning Zong 958 Huawei Technologies 960 Email: zongning@huawei.com 961 Roni Even 962 Gesher Erove 964 Email: ron.even.tlv@gmail.com 966 Yunfei Zhang 967 China Mobile 969 Email: zhangyunfei@chinamobile.com