PPSP Group G.Lu Internet Draft JC.Zuniga Intended status: Informational A.Rahman Expires: January 9, 2011 InterDigital Communications, LLC July 9, 2010 P2P Streaming for Mobile Nodes: Scenarios and Related Issues draft-lu-ppsp-mobile-02.txt Abstract The scenarios where a Peer-to-Peer Streaming Protocol (PPSP) contains mobile nodes need special considerations. An analysis of all the scenarios that involve mobile nodes is necessary to provide the guidelines to PPSP protocol design and applicability. This document describes some key issues for a PPSP network with mobile nodes. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 9, 2011. Lu, et al. Expires January 9, 2011 [Page 1] Internet-Draft P2P Streaming for Mobile Nodes July 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction...................................................2 2. Conventions and Terminology....................................3 3. Mobile Node Capabilities.......................................3 3.1. Uplink vs. Downlink Bandwidth.............................3 3.2. Battery Power.............................................3 3.3. Processing Power..........................................4 3.4. Multiple Interfaces.......................................4 4. Geo-Targeting Issues...........................................5 5. Conclusion.....................................................6 6. Security Considerations........................................6 7. IANA Considerations............................................6 8. References.....................................................6 8.1. Normative References......................................6 8.2. Informative References....................................7 9. Acknowledgments................................................7 10. Appendix A - Other Mobility Considerations....................7 10.1. Link Layer Mobility......................................7 10.2. Mobile IP................................................8 10.3. Proxy Mobile IP.........................................10 10.4. Mobility support with RELOAD............................10 10.5. Tracker Mobility........................................10 1. Introduction The PPSP Working Group is developing protocols for Peer-to-Peer (P2P) streaming systems [I-D.zong-ppsp-reqs]. In the past P2P solutions Lu, et al. Expires January 9, 2011 [Page 2] Internet-Draft P2P Streaming for Mobile Nodes July 2010 have mostly targeted wired or fixed connections. Mobile P2P communications are expected to grow rapidly and the nature of mobile nodes and mobile environments cause specific challenges to P2P communications, specifically for streaming scenarios. This draft discusses some key mobility specific issues. 2. Conventions and Terminology This document uses the same terminologies as [I-D.zong-ppsp-reqs]. For simplicity, this document illustrates scenarios showing a centralized Tracker architecture. However, it should be understood that all the scenarios also apply to the distributed architecture, e.g. using a Distributed Hash Table (DHT). 3. Mobile Node Capabilities Mobile nodes are constrained by nature due to their limited battery, screen size, computational capability, etc. Also mobile nodes operate in variable and unpredictable environments. These attributes bring about the following problems that may adversely affect the P2P Streaming sessions. 3.1. Uplink vs. Downlink Bandwidth Often mobile nodes have asymmetrical bandwidth capabilities. For instance, most mobile nodes are capable of handling higher bit rates in the downlink (to the mobile) than in the uplink (from the mobile). In addition, many mobile networks also have policies to assign bandwidth in this asymmetrical manner regardless of the capabilities of the mobile node. Since peer-to-peer streaming sessions can be either generated or terminated on a mobile node, this bandwidth asymmetry should be considered for the Peer-Peer chunk (content) transfer protocol, and may also impact the Tracker-Peer protocol (e.g. as part of Peer status parameters reported to the Tracker). 3.2. Battery Power By definition, a mobile node is often disconnected from the electrical grid and runs on its own battery power. In this Lu, et al. Expires January 9, 2011 [Page 3] Internet-Draft P2P Streaming for Mobile Nodes July 2010 scenario, the user of the mobile node may want to restrict the types of P2P sessions that the mobile node should participate in because of battery drain issues. For example, the user may be willing to participate in a P2P session if the user herself is watching the content. However, the user may not want to participate in uploading large amounts of content to other peers. Therefore, battery power (or battery status) of a mobile node should be considered in both the Peer-Peer and the Tracker-Peer protocols (e.g. as part of Peer status parameters reported to the Tracker and other peers). 3.3. Processing Power Some devices are more capable than others in terms of computational performance or processing power. Similarly, devices can have different performance for generating a session (e.g. video recording) or terminating it (e.g. video display). Taking these differences into account is important for maintaining a good quality of the P2P streaming session. This information should be considered for reporting in the Tracker-Peer protocol (e.g. as part of Peer status parameters reported to the Tracker). 3.4. Multiple Interfaces Simple IP refers to the scenario where there is no IP layer mobility protocol such as Mobile IP or Proxy Mobile IP, and a peer needs to obtain a new IP address through a standard method like DHCP after losing the previous IP address. As illustrated in Figure 1, when Peer 1 moves from AN1 to AN2, its IP address changes from IP1 to IP2. This will impact both the Peer-Peer connection and the Tracker-Peer connection. For example, Peer-Peer communication maybe lost (e.g. Peer 2 incorrectly sends chunks to IP1 even though Peer 1 has now changed address to IP2). Also the Tracker-Peer communication may be compromised (e.g. Tracker has corrupted Peer lists containing incorrect IP Address for Peer 1). These effects may be somewhat mitigated by having the mobile node update the tracker and corresponding peers with its new IP address. The key question then is the trade-off between signaling required to provide notification of the IP address change and the load this Lu, et al. Expires January 9, 2011 [Page 4] Internet-Draft P2P Streaming for Mobile Nodes July 2010 causes on the system. Also race conditions must be carefully considered. +---------+ ---------- >| Tracker |< ---------- | +---------+ | X 3) Tracker-Peer communication | | may be corrupted | | | | | v 2) P2P communication v +------+ may be lost +------+ |Peer 1|< ------------X------------ >|Peer 2| ^ +------+ +------+ | IP1 ^ ^ IP2 1)IP address of ^ IP3 | | | Peer 1 changes | Logical P2P X --------- | Overlay Network | | | ---------------- | | | Physical | | | Network v v v | ****** ****** ****** | * AN1 * * AN2 * * AN3 * v * * * * * * ****** ****** ****** | | | | | | ************************************************ * Internet * * * ************************************************ Figure 1 P2P Streaming with Device with Multiple Interfaces 4. Geo-Targeting Issues Geo-targeting is a technique used to determine the physical location (i.e. geo-location) of a user. The geo-location is based on geographical and other personal information provided by the requester peer or a third party. Techniques to determine geo-location of a user can rely on civic location, GPS geographical coordinates, cellular base station ID, or most commonly IP address. The primary source for IP address geographical data is the regional Internet registries. Lu, et al. Expires January 9, 2011 [Page 5] Internet-Draft P2P Streaming for Mobile Nodes July 2010 Depending on the location, different regulations and rules may apply. For instance, some content may not be distributed on certain locations or can only be distributed on some other locations. Current content distribution policies can apply certain rules to P2P Streaming clients. However, IP mobility protocols such as Mobile IP and Proxy Mobile IP can hide the peer or a Tracker movement from one region to another where possibly different content distribution rules may apply hence rendering the set forth policies un-enforceable. This may also be the case where the peer is connecting through a Virtual Private Network (VPN) and in some cases even a Network Address Translator (NAT). 5. Conclusion The PPSP Working Group should consider the impacts of various aspects of mobility discussed in this draft. In particular, PPSP should study how these issues can be mitigated in a mobile P2P streaming environment when designing both the PPSP Peer-Peer and the Tracker- Peer protocols. 6. Security Considerations This draft does not introduce new threats to security. 7. IANA Considerations This document makes no request of IANA. 8. References 8.1. Normative References [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in Ipv6", RFC 3775, June 2004. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. Lu, et al. Expires January 9, 2011 [Page 6] Internet-Draft P2P Streaming for Mobile Nodes July 2010 8.2. Informative References [I-D.zong-ppsp-reqs] Zong, N., Zhang, Y., Pascual, V., and C. Williams, "P2P Streaming Protocol (PPSP) Requirements", draft-zong-ppsp- reqs-03 (Work in progress), March 5, 2010. [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base-08 (Work in progress), March 7, 2010. 9. Acknowledgments The authors would like to thank Serhad Doken and Milan Patel for their thorough review and valuable inputs to this draft. 10. Appendix A - Other Mobility Considerations This Appendix summarizes some other mobility considerations that were analyzed. However, these considerations are outside the scope of the current PPSP Working Group scope and thus are recorded here for purely informational purposes. 10.1. Link Layer Mobility PPSP uses a P2P based overlay network on top of the transport network. Mobility or link quality at link layers is not visible to the peers. As illustrated in Figure 1, if Peer 1 is connected to a poor quality link via mobile Access Network 1 (AN1), then the overall P2P streaming session quality can suffer from high error rate and low throughput due to poor link layer conditions. This will impact both the Peer-Peer connection and the Tracker-Peer connection. For example, on the Peer-Peer connection frame loss, audio/video synch loss, or streaming stalls are likely to be seen on the media transfer protocols. Lu, et al. Expires January 9, 2011 [Page 7] Internet-Draft P2P Streaming for Mobile Nodes July 2010 +---------+ ---------- >| Tracker |< ---------- | +---------+ | | 3)Tracker-Peer communication | X is poor | | | | | | 2)P2P streaming session | v quality is poor v +------+ +------+ ^ |Peer 1|< ------------X------------ >|Peer 2| | +------+ +------+ | IP1 ^ ^ IP2 Logical P2P | | Overlay Network X 1)Poor quality link layer | ------------------ | | Physical | | Network v v | ****** ****** | * AN1 * * AN2 * v * * * * ****** ****** | | | | ************************************************ * Internet * * * ************************************************ Figure 2 P2P Streaming with Link Layer Mobility 10.2. Mobile IP Mobile IP (MIP) provides IP mobility and hides the mobile's movement from the Correspondent Node (CN) [RFC3775]. Figure 3 illustrates the case when Peer 1 moves from AN1 to AN1'. Because of Mobile IP, neither the Tracker nor Peer 2 are aware of the change of network for peer 1. However, due to the inherent tunneling and triangular routing of the Mobile IP protocol (through the Home Agent) the P2P session may in some scenarios experience extra latency. This may adversely affect the user experience of the P2P Lu, et al. Expires January 9, 2011 [Page 8] Internet-Draft P2P Streaming for Mobile Nodes July 2010 streaming session. As seen above, Mobile IP will impact primarily the Peer-Peer connection (and the Tracker-Peer connection is not significantly affected). +---------+ ---------- >| Tracker |< ---------- | +---------+ | | | | | | 3) P2P chunk transfer (content) | | may experience extra latency | | due to extra MIP tunneling | v v +------+ +------+ |Peer 1|< -----------X------------- >|Peer 2| ^ +------+ +------+ | ^ ^ IP-HA 1) Peer 1 moves ^ IP2 | | | between networks | Logical P2P X --------- | Overlay Network | | | ---------------- | | | Physical | | | Network | | | | v v v | ****** ****** ****** v * AN1 * * AN2 * * AN3 * * * * * * * ****** ****** ****** | | | | | | +---------------+ 2) IP traffic of | | MIP Home Agent| Peer 1 is always | +---------------+ tunneled to the | | Home Agent | | | ************************************************ * Internet * * * ************************************************ Figure 3 P2P Streaming with Mobile IP Lu, et al. Expires January 9, 2011 [Page 9] Internet-Draft P2P Streaming for Mobile Nodes July 2010 10.3. Proxy Mobile IP The use of Proxy Mobile IP [RFC5213] causes similar issues as the ones mentioned for Mobile IP in the above section. On top of these, Proxy Mobile IP also introduces a new issue for P2P streaming sessions. Since Proxy Mobile IP is a network based solution, the mobile node (peer) is not aware of its IP mobility so it cannot inform the Tracker, P2P Cache, CDNs or other peers of the IP level mobility. Therefore IP mobility is totally invisible to the P2P Streaming session entities and harder to detect and respond accordingly. Thus Proxy Mobile IP will impact both the Peer-Peer connection and the Tracker-Peer connection. 10.4. Mobility support with RELOAD It has already been identified in the proposed WG charter that any PPSP developed protocol should be analyzed for interactions with the RELOAD protocol. The RELOAD protocol provides a signaling and routing mechanism for P2P overlay networks over the general Internet. The latest RELOAD draft [I-D.ietf-p2psip-base] also has a future consideration section for support of HIP (section 5.6.1.1). HIP is an experimental mobility protocol with good security properties. In addition to HIP, the following mobility protocols should also be considered for PPSP-RELOAD interactions: . Mobile IP . Proxy Mobile IP 10.5. Tracker Mobility Normally Trackers are assumed to be fixed nodes. However, in a mobile environment mobile nodes can also become Trackers. In this sense, similar considerations to the ones described above for mobile peers should be applied to mobile Trackers. Lu, et al. Expires January 9, 2011 [Page 10] Internet-Draft P2P Streaming for Mobile Nodes July 2010 Authors' Addresses Guang Lu InterDigital Communications, LLC Email: Guang.Lu@InterDigital.com Juan Carlos Zuniga InterDigital Communications, LLC Email: JuanCarlos.Zuniga@InterDigital.com Akbar Rahman InterDigital Communications, LLC Email: Akbar.Rahman@InterDigital.com Lu, et al. Expires January 9, 2011 [Page 11]