idnits 2.17.00 (12 Aug 2021) /tmp/idnits58984/draft-lu-ppsp-mobile-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 228: '...s of a Peer device MUST immediately be...' RFC 2119 keyword, line 232: '... MAY be reported via the Tracker Pro...' RFC 2119 keyword, line 234: '...of a Peer device SHOULD be reported vi...' RFC 2119 keyword, line 237: '...of a Peer device SHOULD be reported vi...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 21, 2010) is 4253 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-p2psip-base has been published as RFC 6940 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPSP Group G.Lu 2 Internet Draft JC.Zuniga 3 Intended status: Informational A.Rahman 4 Expires: March 21, 2011 InterDigital Communications, LLC 5 September 21, 2010 7 P2P Streaming for Mobile Nodes: Scenarios and Related Issues 8 draft-lu-ppsp-mobile-04.txt 10 Abstract 12 The scenarios where a Peer-to-Peer Streaming Protocol (PPSP) contains 13 mobile nodes need special considerations. An analysis of all the 14 scenarios that involve mobile nodes is necessary to provide the 15 guidelines to PPSP protocol design and applicability. This document 16 describes some key issues for a PPSP network with mobile nodes, and 17 proposes some additional requirements for PPSP to handle these 18 scenarios. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on March 21, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction...................................................2 61 2. Conventions and Terminology....................................3 62 3. Mobile Node Issues.............................................3 63 3.1. Uplink vs. Downlink Bandwidth.............................3 64 3.2. Battery Power.............................................3 65 3.3. Multiple Interfaces.......................................4 66 3.4. Geo-Targeting.............................................5 67 4. Conclusion and Recommendations.................................6 68 5. Security Considerations........................................6 69 6. IANA Considerations............................................6 70 7. References.....................................................7 71 7.1. Normative References......................................7 72 7.2. Informative References....................................7 73 8. Acknowledgments................................................7 74 9. Appendix A - Other Mobility Considerations.....................7 75 9.1. Processing Power..........................................8 76 9.2. Link Layer Mobility.......................................8 77 9.3. Mobile IP.................................................9 78 9.4. Proxy Mobile IP..........................................11 79 9.5. Mobility support with RELOAD.............................11 80 9.6. Tracker Mobility.........................................11 82 1. Introduction 84 The PPSP Working Group is developing protocols for Peer-to-Peer (P2P) 85 streaming systems [I-D.zong-ppsp-reqs]. In the past P2P solutions 86 have mostly targeted wired or fixed connections. Mobile P2P 87 communications are expected to grow rapidly and the nature of mobile 88 nodes and mobile environments cause specific challenges to P2P 89 communications, specifically for streaming scenarios. This draft 90 discusses some key mobility specific issues. 92 2. Conventions and Terminology 94 This document uses the same terminologies as [I-D.zong-ppsp-reqs]. 95 For simplicity, this document illustrates scenarios showing a 96 centralized Tracker architecture. However, it should be understood 97 that all the scenarios also apply to the distributed architecture, 98 e.g. using a Distributed Hash Table (DHT). 100 3. Mobile Node Issues 102 Mobile nodes are constrained by nature due to their limited battery, 103 screen size, computational capability, etc. Also mobile nodes operate 104 in variable and unpredictable environments. These attributes bring 105 about the following problems that may adversely affect the P2P 106 Streaming sessions. 108 3.1. Uplink vs. Downlink Bandwidth 110 Often mobile nodes have asymmetrical bandwidth capabilities. For 111 instance, most mobile nodes are capable of handling higher bit rates 112 in the downlink (to the mobile) than in the uplink (from the mobile). 113 In addition, many mobile networks also have policies to assign 114 bandwidth in this asymmetrical manner regardless of the capabilities 115 of the mobile node. Since peer-to-peer streaming sessions can be 116 either generated or terminated on a mobile node, this bandwidth 117 asymmetry should be considered for the Tracker-Peer protocol (e.g. as 118 part of Peer status parameters reported to the Tracker), and may also 119 affect Peer-Peer protocol in the peer information negotiation. 121 3.2. Battery Power 123 By definition, a mobile node is often disconnected from the 124 electrical grid and runs on its own battery power. In this 125 scenario, the user of the mobile node may want to restrict the types 126 of P2P sessions that the mobile node should participate in because of 127 battery drain issues. For example, the user may be willing to 128 participate in a P2P session if the user herself is watching the 129 content. However, the user may not want to participate in uploading 130 large amounts of content to other peers. 132 Therefore, battery power (or battery status) of a mobile node should 133 be considered in both the Peer-Peer and the Tracker-Peer protocols 134 (e.g. as part of Peer status parameters reported to the Tracker and 135 other peers). 137 3.3. Multiple Interfaces 139 Simple IP refers to the scenario where there is no IP layer mobility 140 protocol such as Mobile IP or Proxy Mobile IP, and a peer needs to 141 obtain a new IP address through a standard method like DHCP after 142 losing the previous IP address. 144 As illustrated in Figure 1, when Peer 1 moves from AN1 to AN2, its IP 145 address changes from IP1 to IP2. This will impact both the Peer-Peer 146 connection and the Tracker-Peer connection. For example, Peer-Peer 147 communication maybe lost (e.g. Peer 2 incorrectly sends chunks to IP1 148 even though Peer 1 has now changed address to IP2). Also the 149 Tracker-Peer communication may be compromised (e.g. Tracker has 150 corrupted Peer lists containing incorrect IP Address for Peer 1). 152 These effects may be somewhat mitigated by having the mobile node 153 update the tracker and corresponding peers with its new IP address. 154 The key question then is the trade-off between signaling required to 155 provide notification of the IP address change and the load this 156 causes on the system. Also race conditions must be carefully 157 considered. 159 Therefore, reporting of change of the IP address of a mobile node 160 should be considered in both the Peer-Peer and the Tracker-Peer 161 protocols. 163 +---------+ 164 ---------- >| Tracker |< ---------- 165 | +---------+ | 166 X 3) Tracker-Peer communication | 167 | may be corrupted | 168 | | 169 | | 170 v 2) P2P communication v 171 +------+ may be lost +------+ 172 |Peer 1|< ------------X------------ >|Peer 2| ^ 173 +------+ +------+ | 174 IP1 ^ ^ IP2 1)IP address of ^ IP3 | 175 | | Peer 1 changes | Logical P2P 176 X --------- | Overlay Network 177 | | | ---------------- 178 | | | Physical 179 | | | Network 180 v v v | 181 ****** ****** ****** | 182 * AN1 * * AN2 * * AN3 * v 183 * * * * * * 184 ****** ****** ****** 185 | | | 186 | | | 187 ************************************************ 188 * Internet * 189 * * 190 ************************************************ 192 Figure 1 P2P Streaming with Device with Multiple Interfaces 194 3.4. Geo-Targeting 196 Geo-targeting is a technique used to determine the physical location 197 (i.e. geo-location) of a user. The geo-location is based on 198 geographical and other personal information provided by the requester 199 peer or a third party. Techniques to determine geo-location of a user 200 can rely on civic location, GPS geographical coordinates, cellular 201 base station ID, or most commonly IP address. The primary source for 202 IP address geographical data is the regional Internet registries. 204 Depending on the location, different regulations and rules may apply. 205 For instance, some content may not be distributed on certain 206 locations or can only be distributed on some other locations. 208 Current content distribution policies can apply certain rules to 209 fixed P2P Streaming clients. However, device mobility may hide the 210 peer movement from one region to another where possibly different 211 content distribution rules may apply hence rendering the set forth 212 policies un-enforceable. This may also be the case where the peer is 213 connecting through a Virtual Private Network (VPN). 215 Therefore, geo-location reporting of a mobile node should be 216 considered in both the Peer-Peer and the Tracker-Peer protocols. 218 4. Conclusion and Recommendations 220 The PPSP Working Group should consider the impacts of various aspects 221 of mobility discussed in this draft. In particular, PPSP should 222 consider how these issues can be mitigated in a mobile P2P streaming 223 environment when designing both the PPSP Peer-Peer and the Tracker- 224 Peer protocols. Therefore, it is recommended that the following 225 requirements be added to the "Basic Requirements to PPSP Node" 226 section of [I-D.zong-ppsp-reqs]: 228 PPSP.REQ-1: Change in IP address of a Peer device MUST immediately be 229 reported via the Tracker Protocol and Peer Protocol 231 PPSP.REQ-2: Available uplink and downlink bandwidth of a Peer device 232 MAY be reported via the Tracker Protocol and Peer Protocol 234 PPSP.REQ-3: Battery status of a Peer device SHOULD be reported via 235 the Tracker Protocol and Peer Protocol 237 PPSP.REQ-4: Location of a Peer device SHOULD be reported via the 238 Tracker Protocol and Peer Protocol 240 5. Security Considerations 242 This draft does not introduce new threats to security. 244 6. IANA Considerations 246 This document makes no request of IANA. 248 7. References 250 7.1. Normative References 252 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 253 in Ipv6", RFC 3775, June 2004. 255 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 256 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 258 7.2. Informative References 260 [I-D.zong-ppsp-reqs] 261 Zong, N., Zhang, Y., Pascual, V., and C. Williams, "P2P 262 Streaming Protocol (PPSP) Requirements", draft-zong-ppsp- 263 reqs-04 (Work in progress), July 7, 2010. 265 [I-D.ietf-p2psip-base] 266 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. 267 Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base 268 Protocol", draft-ietf-p2psip-base-10 (Work in progress), 269 August 3, 2010. 271 8. Acknowledgments 273 The authors would like to thank Serhad Doken and Milan Patel for 274 their thorough review and valuable inputs to this draft. 276 9. Appendix A - Other Mobility Considerations 278 This Appendix summarizes some other mobility considerations that were 279 analyzed. However, these considerations are outside the scope of the 280 current PPSP Working Group scope and thus are recorded here for 281 purely informational purposes. 283 9.1. Processing Power 285 Some devices are more capable than others in terms of computational 286 performance or processing power. Similarly, devices can have 287 different performance for generating a session (e.g. video recording) 288 or terminating it (e.g. video display). Taking these differences into 289 account is important for maintaining a good quality of the P2P 290 streaming session. 292 9.2. Link Layer Mobility 294 PPSP uses a P2P based overlay network on top of the transport 295 network. Mobility or link quality at link layers is not visible to 296 the peers. 298 As illustrated in Figure 1, if Peer 1 is connected to a poor quality 299 link via mobile Access Network 1 (AN1), then the overall P2P 300 streaming session quality can suffer from high error rate and low 301 throughput due to poor link layer conditions. This will impact both 302 the Peer-Peer connection and the Tracker-Peer connection. For 303 example, on the Peer-Peer connection frame loss, audio/video synch 304 loss, or streaming stalls are likely to be seen on the media transfer 305 protocols. 307 +---------+ 308 ---------- >| Tracker |< ---------- 309 | +---------+ | 310 | 3)Tracker-Peer communication | 311 X is poor | 312 | | 313 | | 314 | 2)P2P streaming session | 315 v quality is poor v 316 +------+ +------+ ^ 317 |Peer 1|< ------------X------------ >|Peer 2| | 318 +------+ +------+ | 319 IP1 ^ ^ IP2 Logical P2P 320 | | Overlay Network 321 X 1)Poor quality link layer | ------------------ 322 | | Physical 323 | | Network 324 v v | 325 ****** ****** | 326 * AN1 * * AN2 * v 327 * * * * 328 ****** ****** 329 | | 330 | | 331 ************************************************ 332 * Internet * 333 * * 334 ************************************************ 336 Figure 2 P2P Streaming with Link Layer Mobility 338 9.3. Mobile IP 340 Mobile IP (MIP) provides IP mobility and hides the mobile's movement 341 from the Correspondent Node (CN) [RFC3775]. 343 Figure 3 illustrates the case when Peer 1 moves from AN1 to AN1'. 344 Because of Mobile IP, neither the Tracker nor Peer 2 are aware of the 345 change of network for peer 1. However, due to the inherent tunneling 346 and triangular routing of the Mobile IP protocol (through the Home 347 Agent) the P2P session may in some scenarios experience extra 348 latency. This may adversely affect the user experience of the P2P 349 streaming session. As seen above, Mobile IP will impact primarily the 350 Peer-Peer connection (and the Tracker-Peer connection is not 351 significantly affected). 353 +---------+ 354 ---------- >| Tracker |< ---------- 355 | +---------+ | 356 | | 357 | | 358 | 3) P2P chunk transfer (content) | 359 | may experience extra latency | 360 | due to extra MIP tunneling | 361 v v 362 +------+ +------+ 363 |Peer 1|< -----------X------------- >|Peer 2| ^ 364 +------+ +------+ | 365 ^ ^ IP-HA 1) Peer 1 moves ^ IP2 | 366 | | between networks | Logical P2P 367 X --------- | Overlay Network 368 | | | ---------------- 369 | | | Physical 370 | | | Network 371 | | | | 372 v v v | 373 ****** ****** ****** v 374 * AN1 * * AN2 * * AN3 * 375 * * * * * * 376 ****** ****** ****** 377 | | | 378 | | | 379 +---------------+ 2) IP traffic of | 380 | MIP Home Agent| Peer 1 is always | 381 +---------------+ tunneled to the | 382 | Home Agent | 383 | | 384 ************************************************ 385 * Internet * 386 * * 387 ************************************************ 389 Figure 3 P2P Streaming with Mobile IP 391 9.4. Proxy Mobile IP 393 The use of Proxy Mobile IP [RFC5213] causes similar issues as the 394 ones mentioned for Mobile IP in the above section. On top of these, 395 Proxy Mobile IP also introduces a new issue for P2P streaming 396 sessions. Since Proxy Mobile IP is a network based solution, the 397 mobile node (peer) is not aware of its IP mobility so it cannot 398 inform the Tracker, P2P Cache, CDNs or other peers of the IP level 399 mobility. Therefore IP mobility is totally invisible to the P2P 400 Streaming session entities and harder to detect and respond 401 accordingly. Thus Proxy Mobile IP will impact both the Peer-Peer 402 connection and the Tracker-Peer connection. 404 9.5. Mobility support with RELOAD 406 It has already been identified in the proposed WG charter that any 407 PPSP developed protocol should be analyzed for interactions with the 408 RELOAD protocol. The RELOAD protocol provides a signaling and routing 409 mechanism for P2P overlay networks over the general Internet. The 410 latest RELOAD draft [I-D.ietf-p2psip-base] also has a future 411 consideration section for support of HIP (section 5.6.1.1). HIP is 412 an experimental mobility protocol with good security properties. 414 In addition to HIP, the following mobility protocols should also be 415 considered for PPSP-RELOAD interactions: 417 . Mobile IP 419 . Proxy Mobile IP 421 9.6. Tracker Mobility 423 Normally Trackers are assumed to be fixed nodes. However, in a mobile 424 environment mobile nodes can also become Trackers. In this sense, 425 similar considerations to the ones described above for mobile peers 426 should be applied to mobile Trackers. 428 Authors' Addresses 430 Guang Lu 431 InterDigital Communications, LLC 432 Email: Guang.Lu@InterDigital.com 434 Juan Carlos Zuniga 435 InterDigital Communications, LLC 436 Email: JuanCarlos.Zuniga@InterDigital.com 438 Akbar Rahman 439 InterDigital Communications, LLC 440 Email: Akbar.Rahman@InterDigital.com