Cross-layer Optimization of Peer-to-Peer Video Streaming in OpenFlow-based ISP Networks

Cross-layer Optimization of Peer-to-Peer Video Streaming in OpenFlow-based ISP Networks Diplomarbeit Jeremias Blendin PS-D-0003 Fachbereich Elektrotechnik und Informationstechnik Institut für Datentechnik Fachgebiet P2P Systems Engineering Prof. Dr. David ausheer

Cross-layer Optimization of Peer-to-Peer Video Streaming in OpenFlow-based ISP Networks Diplomarbeit PS-D-0003 Eingereicht von Jeremias Blendin Tag der Einreichung: 30. April 2013 Gutachter: Prof. Dr. David ausheer Zweitgutachter: Prof. Dr.-Ing. Ralf Steinmetz Betreuer: M.Sc. Julius Rückert Technische Universität Darmstadt Fachbereich Elektrotechnik und Informationstechnik Institut für Datentechnik Fachgebiet P2P Systems Engineering Prof. Dr. David ausheer

Ehrenwörtliche Erklärung iermit versichere ich, die vorliegende Diplomarbeit ohne ilfe Dritter und nur mit den angegebenen Quellen und ilfsmitteln angefertigt zu haben. Alle Stellen, die aus den Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in dieser oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen. Die schriftliche Fassung stimmt mit der elektronischen Fassung überein. Darmstadt, den 30. April 2013 Jeremias Blendin i

Contents 1. Introduction 1 1.1. Goal and Contribution.......................................... 1 1.2. Outline................................................... 2 2. Background 3 2.1. Live Video Streaming........................................... 3 2.1.1. Multicast on the Internet.................................... 3 2.1.2. Peer-to-Peer Live Video Streaming.............................. 5 2.2. Internet Service Providers........................................ 7 2.2.1. Classification........................................... 7 2.2.2. Network Topology and Characteristics............................ 8 2.2.3. ISPs and Peer-to-Peer Systems................................. 10 2.3. Openflow.................................................. 10 2.3.1. The OpenFlow Standard.................................... 12 2.3.2. OpenFlow Switches....................................... 15 3. Related Work 17 3.1. ISP and Peer-to-Peer Cooperation................................... 17 3.1.1. ISP Network Information Services.............................. 17 3.1.2. ISP-Owned Peers......................................... 18 3.2. Peer-to-Peer Live Video Streaming and Super Peers........................ 18 3.2.1. mtreebone............................................ 18 3.2.2. SALSA............................................... 19 3.3. Overlay Networks and Multicast.................................... 19 3.4. Improvements to IP Multicast...................................... 20 3.4.1. Recursive Unicast........................................ 20 3.4.2. Explicit Multicast......................................... 22 3.4.3. LIPSIN............................................... 22 3.4.4. Labelcast.............................................. 23 3.5. OpenFlow and IP Multicast....................................... 23 3.5.1. IP multicast with Fast Tree Switching............................ 23 3.5.2. CastFlow.............................................. 23 4. Assumptions and Requirements 25 4.1. Assumptions................................................ 25 4.2. Requirements of ISPs........................................... 25 4.2.1. Service Resource Consumption Requirements....................... 26 4.2.2. Service Integration and Management Requirements................... 26 4.3. Requirements of Peer-to-Peer Live Video Streaming........................ 27 4.3.1. Technical Requirements..................................... 27 iii

4.3.2. Requirements of Users, Operators and Application Providers.............. 27 5. System Design 29 5.1. Description and Rationale........................................ 29 5.1.1. Functional Description..................................... 29 5.1.2. Rationale.............................................. 31 5.2. Architecture................................................ 34 5.2.1. OpenFlow based Network Architectures........................... 34 5.2.2. System Structure and Interactions.............................. 35 5.3. Components................................................ 36 5.3.1. Rent-a-Super Peer Controller Component.......................... 36 5.3.2. Virtual Peer Component..................................... 39 5.3.3. Software Defined Multicast Component........................... 40 5.3.4. Explicit Multicast Subcomponent............................... 45 5.4. Peer-to-Peer System Integration.................................... 47 5.4.1. General Considerations and Peer Behavior Adaptation.................. 47 5.4.2. Super Peer Adaptation..................................... 48 5.4.3. Rent-a-Super Peer Instance Discovery............................ 48 6. Prototype 49 6.1. Architecture................................................ 50 6.2. Network Emulation............................................ 51 6.2.1. Mininet............................................... 51 6.2.2. OpenFlow Switch........................................ 51 6.2.3. Topology Database and Network Experiments....................... 54 6.2.4. OpenFlow Routing and Forwarding............................. 55 6.3. The Ryu OpenFlow Controller..................................... 57 6.3.1. Architecture and Overview................................... 57 6.3.2. Limitations............................................ 58 6.3.3. Ryu Application Blueprint................................... 58 6.4. Implementation.............................................. 60 6.4.1. Rent-a-Super Peer Controller and Public API........................ 60 6.4.2. Topology Application...................................... 62 6.4.3. Virtual Peer Application..................................... 63 6.4.4. Software-Defined Multicast Application........................... 64 7. Evaluation 69 7.1. Scenario................................................... 69 7.1.1. ISP Core Networks........................................ 70 7.1.2. ISP Access and Aggregation Networks............................ 72 7.1.3. Applied Network Topology Variations............................ 73 7.1.4. Peer-to-Peer Live Video Streaming Model and Emulation................ 76 7.1.5. Overlay Topology Generation................................. 77 7.2. Transmission Efficiency......................................... 81 7.2.1. Metrics............................................... 81 7.2.2. Implementation.......................................... 82 iv Contents

7.2.3. Results............................................... 83 7.3. System Costs................................................ 86 7.3.1. Number of Required OpenFlow Rules............................ 88 7.3.2. OpenFlow Messaging Overhead................................ 91 7.3.3. API Management Overhead.................................. 92 7.4. Conclusion................................................. 93 8. Conclusion and Future Work 95 8.1. Future Work on the RASP Implementation and Integration into P2P LVS Systems...... 96 8.2. Future Work on the Large Scale Evaluation............................. 97 8.3. Future Work on Using the RASP Service with other Applications................ 97 A. Evaluation Statistics 99 A.1. t-test Statistics of the Intra-ISP Traffic Volume Ratio Differences................ 99 A.2. t-test Statistics of the Cross-Border Traffic Volume Differences.................. 100 Acronyms 103 Bibliography 104 Contents v

List of Figures 2.1. A P2P LVS layer model (based on [67], p. 73)............................ 5 2.2. Tree and mesh topologies for video stream distribution in P2P LVS. Blue boxes denote existing, white boxes missing parts of the video........................... 6 2.3. ierarchical topology of the Internet [58, p. 78]........................... 8 2.4. ISP network topology by network types................................ 9 2.5. A traditional networking scheme and the OpenFlow networking scheme [see 72, p. 2]... 11 2.6. Operating schema of the OpenFlow version 1.0 flow table..................... 13 2.7. Operating schema of the OpenFlow version 1.1 packet-processing pipeline.......... 14 3.1. The forwarding scheme of REUNITE (adapted from [104, p. 1645]).............. 21 5.1. A simplified illustration of the operation of a P2P LVS system................... 30 5.2. A simplified illustration of the operation of a P2P LVS system using the RASP service.... 31 5.3. OpenFlow network architecture (adapted from [82, p. 7]).................... 34 5.4. Architecture of the RASP service.................................... 35 5.5. The names of entities involved with the RASP system........................ 37 5.6. OpenFlow rules for implementing a virtual peer for a connection initiated by peer P to super peer SP................................................ 40 5.7. Comparison of an IP multicast and a SDM domain......................... 41 5.8. Schema of the SDM concept....................................... 42 5.9. Schematic overview of an Explicit SDM domain and its subdomains............... 46 6.1. The components of the RASP service that are part of the prototype............... 49 6.2. Overview of the prototype implementation and the accompanying emulation system of RASP..................................................... 50 6.3. Throughput of the three OpenFlow software switches as measured by iperf.......... 53 6.4. The process schema of running an emulated network experiment................ 54 6.5. An example network based on the topology database information used for creating emulated networks............................................... 55 6.6. Simplified diagram of an OpenFlow LAN switch in the emulated network........... 56 6.7. The architecture of Ryu [77]....................................... 58 6.8. UML class diagram of a typical Ryu application skeleton...................... 59 6.9. Overview over the parts of the prototype whose implementations are described in Section 6.4.................................................... 60 6.10.Example of a super peer using the RASP API to set up a video stream and adding a member to it...................................................... 61 6.11.The structure of the RASP controller implementation........................ 62 6.12.The structure of the topology application implementation..................... 63 6.13.The structure of the Virtual Peer application implementation................... 63 6.14.The structure of the SDM application implementation....................... 64 vii

6.15.Multicast tree construction problem.................................. 66 6.16.Schematic cutout of a SDM multicast tree with three different forwarding states....... 67 7.1. Deutsche Telekom s core network [26, p. 4]............................. 71 7.2. The network topology model used as basis for network topology with annotations on the scaling possibilities............................................. 71 7.3. Access and aggregation networks: Ethernet application and PPP encapsulation........ 72 7.4. Network model instance DT small................................... 74 7.5. Network model instance scaled by increasing the number of connected host per access switch (DT osts)............................................. 75 7.6. Network model instance scaled by adding core nodes (DT Core)................. 76 7.7. Network model instance scaled by increasing the trees depths (DT Depths).......... 77 7.8. Overlay network algorithm examples based on the DT Small topology............. 79 7.9. The cumulative distribution functions of two characteristics of the three P2P video overlay tree algorithms............................................... 80 7.10.The intra ISP data volume per peer for each topology and overlay network algorithm.... 84 7.11.The intra ISP data volume per peer for each topology and overlay network algorithm normalized by the mean of the Random overlay algorithm for each topology......... 85 7.12.The cross-border data volume for each topology and overlay network algorithm....... 85 7.13.The link stretch for each topology and overlay............................ 86 7.14.The RASP system architecture with annotations on system cost related parts......... 87 7.15.Schema of the SDM distribution tree and the relevant parts for assessing the number of used OpenFlow rules............................................ 88 7.16.The number of OpenFlow flow modification messages that install new rules during the network experiments........................................... 90 7.17.The number of OpenFlow message required for adding peers to a RASP instance....... 92 viii List of Figures

List of Tables 2.1. The packet header match fields available in OpenFlow 1.0.................... 13 5.1. Comparison of multicast concepts (based on [46, p. 158]).................... 33 5.2. OpenFlow rule schema for marking packets addresses to a SDM multicast group on the group s marking switches......................................... 43 5.3. OpenFlow rule schema for writing a member s socket information to packets of a SDM multicast group on the group s member switches.......................... 44 5.4. OpenFlow rule schema for switch S4.................................. 46 5.5. OpenFlow rule schema for switch S9.................................. 46 6.1. Throughput of the three OpenFlow software switches as measured by iperf.......... 53 6.2. OpenFlow 1.0 flowtables for a LAN switch in the emulated network............... 56 6.3. RASP controller service API overview.................................. 61 6.4. Topology application API overview................................... 62 6.5. Virtual Peer application API overview.................................. 64 6.6. SDM application API overview...................................... 65 6.7. OpenFlow matcher G match for packets of SDM group G....................... 67 6.8. OpenFlow rules during the three steps of the SDM tree forwarding example......... 68 7.1. Overview of the methods and tools used for evaluation...................... 82 7.2. Average number of OpenFlow rules per device class for the scenario used for evaluation.. 89 ix

1 Introduction Internet video streaming causes the second largest transfer volume and is the second fastest growing application class in Internet traffic analysis [58, p. 82]. In the American broadband access market, streaming video is the source of 50% of the traffic volume and still expected to increase its volume share [101]. Many large video streaming services use CDNs or closed multicast systems. An approach that works without fixed infrastructure is Peer-to-Peer (P2P) video streaming. Using P2P systems enables Internet wide use of video streaming, but it is a burden for Internet Service Providers (ISPs) due to its hard to control, unpredictable, and unfavorable traffic patterns. Software Defined Networking (SDN) and especially its OpenFlow variant is a network paradigm that gains traction in the network market [1] and which is already used in production environments [40]. OpenFlow enables network domains and, more importantly, the forwarding hardware network switches and routers to be controlled remotely by software. At the same time, it allows a logically centralized view on the network state. These features are of immediate relevance for efficient and centralized network management. Furthermore, new networking concepts can be applied that have been unfeasible before. This work investigates how OpenFlow can be used to improve Peer-to-Peer Live Video Streaming (P2P LVS) for users, operators and ISPs. The approach is based on cross-layer optimization, as OpenFlow is a network layer technology and P2P LVS an application layer technology. It focuses on the network domains of residential broadband access ISPs, whose customers are the main users of video streaming applications. The concept presented in this work, Rent-a-Super Peer (RASP), is a service that enables users of P2P LVS systems to increase their network resources within a ISP network, thereby providing them super peer like capabilities. The service is offered by residential broadband ISPs for users outside their networks to distribute their video streams within the ISP s network in an efficient way. This concept allows using the system on-demand. The generic cross-layer system enables P2P LVS to increase its number of super peers, which leads to improved system performance. At the same time, it improves the ISPs role in P2P LVS by increasing their control on P2P LVS traffic and making its transmission more efficient and, thus, reducing the generated traffic volume. The approach of the service and its design is presented and discussed in this work. A prototypical implementation is described and its conceptual characteristics evaluated. OpenFlow is a new technology and its usage as well as its application to specific application domains is not extensively documented yet. ence, this work should give an insight on how an OpenFlow application can be designed and evaluated. For designing the service, it is assumed that, in the future, OpenFlow will be adopted in most networking domains, including ISPs. 1.1 Goal and Contribution The goals of the RASP service are threefold: improving P2P LVS systems as well as increasing the transmission efficiency and the control of P2P LVS traffic in ISP networks. The service aims to improve P2P LVS systems by creating an on-demand service in ISP networks that provides super peer like network performance to normal peers. The services works for peers outside the ISP network by providing network resources for other peers inside the network. In addition to that, the 1

service provides them with a network layer proxy presence within the ISP network. The transmission efficiency is increased by using a network layer multicast mechanism for distributing the video stream. It uses unicast IP addresses and its usage is transparent for its users outside the ISP s OpenFlow network. This approach in combination with the network layer proxy enables the ISP to have full control of the service and its network traffic. The contribution of this work is the design of network layer service for enabling generic, on-demand ISP-owned Peers [89]. It is based OpenFlow and is aimed at exploiting the performance and efficiency of OpenFlow hardware. The RASP service provides the network resources, while the P2P LVS users provide the peer s computing resources and operation. The respective applications providers add the integration of the service into P2P LVS systems. Due to its generic approach, the service can be integrated into a wide range of P2P LVS systems. This is possible because it does not require peers to support special network protocols such as IP multicast. 1.2 Outline An overview of P2P LVS systems, ISPs, their relationship, and OpenFlow is given in Chapter 2. The state of the art on improvements of P2P LVS systems, their cooperation with ISPs, and approaches to integrate network layer multicast in P2P LVS systems is described in Chapter 3. The requirements for OpenFlowbased services offered by ISPs to P2P LVS systems are discussed in Chapter 4. The system design of RASP is described in Chapter 5, its implementation for evaluation in Chapter 6. The system is evaluated in Chapter 7. Its results are summed up in Chapter 8, finally and an outlook on the next steps in the research is given. 2 1. Introduction

2 Background In this section, the relevant background on the research areas of P2P LVS, ISPs and OpenFlow is given. The historical development of live video streaming on the Internet is described in Section 2.1, beginning from IP multicast to today s P2P LVS systems. An introduction into the structure of the Internet and the role of ISPs is given in Section 2.2. Furthermore, their relationship with P2P LVS systems is described. Lastly, the SDN variant OpenFlow is introduced and relevant features described in Section 2.3. 2.1 Live Video Streaming Live video streaming is only one of three forms of Internet video application types, the others are video file sharing, and video on demand. Video file sharing works similar to sharing of other files; the videos are downloaded and watched some time later. When using video on demand, the videos are played back while still being downloaded. In addition to that, live video streams are watched synchronously by all clients. The synchronicity of the playback of live video streaming is defined by application specific deadlines. If the deadlines are met the playback is considered synchronous [119, pp. 3548,3589]. The two major applications of live video streaming are video conferencing and Internet Protocol Television (IPTV). Typical differences in the usage characteristics between video conferencing and IPTV are the delay deadline and the number of users. In video conferencing, the number of participating users is small as is the delay deadline. For IPTV the delay deadline is higher, and the number of users is usually much larger [65, p. 14]. In live video streaming, a source sends a video stream to multiple of consumers. The natural way of handling this communication is multicast. The concept and application of multicast is described in Section 2.1.1, its application for streaming live video is described in Section 2.1.2 2.1.1 Multicast on the Internet The different approaches on implementing multicast services are presented in this section. Multicast communication is a service for sending one message to multiple recipients. Without such a service, the sender has to send the message to each recipient separately. The sender and its recipients in multicast services constitute a multicast group; the recipients are also called members in this context. Computer systems connected to the network (hosts) can join and leave groups. Members of a group receive its messages and depending on the system can send messages to the group. owever, in this work only multicast services with one sender per group are discussed. Components required by all types of multicast services are functionality for creating, joining and leaving groups. Further required functionalities are routing and signaling of the multicast group information as well as an addressing scheme for identifying multicast packets and their destinations. A multicast service can be implemented on different levels of the ISO/OSI network layer reference model. In the next paragraphs, a short overview over the historical development of multicast services is given. 3

IP Multicast The implementation of multicast services at the network layer is very efficient. This concept, IP multicast, has been a research topic since 1990 [22]. The goal of IP multicast is to create facilities for Internet wide multicast communications. The fundamental mechanism of all IP multicast services is the distribution tree. The members of a multicast group are connected by a tree spanning, which consists of IP multicast enabled routers. Multicast Packets are forwarded along the tree and duplicated at joints of the tree. IP multicast consists of a number of components that are implemented using different network protocols. Multicast groups are identified and addressed by IP addresses from a special range [21]. Group management, joining and leaving is enabled by a network layer group management protocol (e.g. IGMPv3 [15]) that is used between hosts and routers. To join a group, a host sends an IGMP message which is forwarded through the network towards the multicast management router. The management router adds the hosts to the member list, and adjusts the multicast tree accordingly. The setup and maintenance of the routes that constitute the multicast tree is provided by IP multicast routing protocols, such as PIM-SM [28]. Forwarding of IP multicast packets is done by the normal method of packet forwarding but with special IP addresses. The protocols described up to this point are for usage within a network domain. Interconnecting multicast domains is enabled by inter-domain multicast routing protocols (e.g. MSDP [27]). A wide range of IP multicast protocols exists, the ones mentioned here are prominent examples. Today, IP multicast is not deployed on a global basis. Only isolated IP multicast domains, called multicast islands, exist. For example, some ISPs use IP multicast to deliver services like IPTV within their networks as for example described in [66]. The reasons for the failure of IP multicast to be deployed globally on the Internet are discussed in [23]. Although the paper is more than 10 years old, many arguments still hold. From a technical perspective, the deployment, management, and operations of IP multicast are complex and thus expensive. One problem that hinders the global deployment of IP multicast is the necessity to store the state of multicast groups in the network. IP multicast enabled routers have to store information on the multicast distribution tree on each group they are part of. This characteristic is the reason for the unfavorable scaling characteristics of IP multicast, which is a cause for the failure of Internet-wide IP multicast. Today the scalability aspect of IP multicast is still an active research topic [92]. Admission control and security features are not part of most IP multicast protocols. ence, ISPs have no control over IP multicast communications, its users and usage, while its implementation is expensive. ence, there are no incentives for the major network providers to deploy Internet wide IP multicast services for public consumption. Overlay Multicast and Application Level Multicast Application layer multicast and overlay multicast were developed in response to the slow adaption of IP Multicast. Both approaches construct a virtual application layer network. The main differences among [...] IP multicast, application layer multicast, and overlay multicast, depend on whether the group management and data delivery control are implemented in network routers, and hosts, or intermediate proxy nodes. [113, 526] In application layer multicast, hosts replicate the packets and manage the group features, which is approach similar to P2P. The approach of overlay multicast is to connect IP multicast domains using specialized hosts. They act as multicast proxies, connecting the multicast islands in a P2P fashion. IP multicast and overlay multicast rely on the IP multicast protocol, while application layer multicast uses IP unicast only and therefore does not rely specialized routers. 4 2. Background

2.1.2 Peer-to-Peer Live Video Streaming While IP multicast is the most efficient method to implement one to many communications, it is not widely deployed. ence, alternatives such as application layer multicast are researched and used. One form of application layer multicast are P2P LVS systems. The concept of such systems is described in this paragraph. In the following paragraph, an insight into current research on P2P LVS is given. Applications are called P2P systems because they do net rely on servers to communicate. Instead, the application is run by the participating clients, the peers. Their communication paths form a virtual network on top of the underlying one, called overlay network. The underlying network is called underlay network in this context. P2P systems are distributed systems in which participating entities (peers) share resources with the goal of running applications mutually. Each peer acts as client and server, the application is consumed and provided by peers at the same time. Different P2P systems have been developed to offer a range of applications such as file sharing, content distribution, and application-level multicast [67, p. 72]. The topology of the overlay network can be arbitrary and is not bound to the topology of the underlay network. owever, the overlay networks performance is bounded by the resources and qualities of the underlay network. P2P LVS System Live video streaming Service: Video distribution Overlay network Network communication Underlay network Figure 2.1.: A P2P LVS layer model (based on [67], p. 73). P2P LVS is an application of P2P systems for distributing live video streams. A layer model for such applications is depicted in Figure 2.1. The system is built on the underlay network, which is used for creating overlay network connections to other peers. The system uses them for management, maintenance, and message transport. A video distribution service is built on top of the overlay network. It defines the topology and the behavior of peers during video distribution. Finally, the live video streaming layer creates a video stream for the consumption of the user. The general approach to live video streaming in P2P systems is to split into small pieces, junks, and distribute them using the overlay network. The methods for distributing the video is either tree or mesh-based. In tree-based systems, the video distribution topology forms a tree as shown in Figure 2.2a. Tree-based systems are application layer multicast systems. For each stream an arborescence is created, in which each peer immediately forwards the video data it receives along the arcs. The root of the arborescence is the source of the video, denoted by node A in the figure. The video parts 1,2, and 3 are available, as depicted by the blue boxes. These parts are consecutively sent to the downstream nodes B and C. Node C itself has two downstream nodes, to which it sends each part immediately after it is received. Nodes B, D, and E are leaf nodes, they receive the video stream but do not take part in its distribution. Mesh-based systems work similar to common file sharing systems. As shown in Figure 2.2b, each peer maintains a list of currently relevant parts of the video. Neighbors exchange information on the 2.1. Live Video Streaming 5

parts they already received and on those they need. Based on this information the missing parts are exchanged, initiated by either the receiver or sender of a part. In contrast to the tree topology there is no predefined video dissemination path and no predefined sender and receiver roles. Neighbors are treated individually, while in tree systems all downstream neighbors of a node get the next part as soon as it is available [119, p. 3552,3553]. 1 2 3 A 1 2 3 4 2 2 A 2 1 2 3 B C 1 2 3 1 2 3 4 B 3 C 1 2 3 4 1 1 3 2 1 2 3 D E 1 2 3 1 2 3 4 D 1 E 1 2 3 4 (a) Tree topology (b) Mesh topology Figure 2.2.: Tree and mesh topologies for video stream distribution in P2P LVS. Blue boxes denote existing, white boxes missing parts of the video. The topology of P2P LVS systems influences the performance characteristics of the system. Tree-based systems have the advantage of achieving much smaller playback delays than mesh-based systems [119, p. 3559]. Their transmission efficiency is higher, because the distribution tree is fixed. For mesh-based systems the distribution of the stream is negotiated between neighbors for every junk, hence the management overhead is higher. The disadvantage of tree-based systems is their susceptibility to peers leaving the system unexpectedly. If a node fails, its complete tree of downstream node loses its video stream source. If a node in a level near the video source fails, such an event affects a large number of nodes. Multiple trees are used in some systems to mitigate this characteristic of tree topologies. The video is split in several sub streams at the video source and each sub stream is distributed through a different tree. The sub streams are recombined to a complete video stream before playback. Mesh-based systems have the advantage of being more resilient to peers leaving and entering the system. Due to this tradeoff, hybrid systems are developed which include either both topology approaches for different parts of the system or allow the dynamic switching for adaptation to different situations [4, p. 183,184]. P2P LVS issues A number of issues existing for P2P LVS systems. An overview over current research topics is given in [4]. The issues can be categorized in three groups: underlay issues, overlay issues and application layer issues. Underlay issues comprise quality issues of network connections such as packet loss, high latency or failing links. Also, insufficient network resources influence the systems performance. One example are peers that are connected to the Internet by residential broadband Internet connections. These connections often exhibit asymmetric transmission capacities for upload and download, which restrict the number of downstream nodes a peer can forward the video stream to. In addition, the costs of the data volume might be an issue, for examples for broadband users with data volume limits in their contract. 6 2. Background

The upload capacity of peers plays an important role in both topologies. In trees it constraints out degree of the participating nodes, which in turn influences the trees depths and the playback delay [4, p. 181]. In mesh systems, uplink capacities of a peers neighbor influences the number of them needed to receive all parts in time. In sum, the upload capacity determines how many neighbors a peer can distribute a video stream to. Also, studies show that the ratio of peers with low uplink capacities to peers with high uplink capacities influences the performance of the whole P2P LVS system [57],[64, p. 349]. Overlay issues concern the P2P network itself. Problems include bad overlay connections, unresponsive peers or improper overlay topologies. The unpredictable joining and leaving of peers in the system is called churn. It is of relevance in P2P systems, as the peers are part of the overlay networks infrastructure. Peer churn can cause instability in the system or be the reason for packet loss in the video stream in case of P2P LVS systems. Another problem is a high rate of new peers, which can overwhelm the system s ability to integrate new peers; this phenomenon is also called flash crowd. Similar problems arise during high rates of peers leaving the system. Lastly application layer problems could arise, especially if the ISP of the user tries to mitigate the negative influence of P2P systems on the network. This could lead to throttling or blocking of P2P overlay connections, obstructing the user to use the overlay network. Approaches for mitigating these issues are an active research topic. Besides optimizing the P2P LVS systems, mechanisms for the cooperation of different layers, called cross-layer optimization, are researched. One is underlay awareness, which is the concept of considering the characteristics of the underlay network and adapting the overlay network accordingly. 2.2 Internet Service Providers ISPs play an important role in the Internet architecture. This work focuses on residential broadband Internet access. Other means of connecting to the Internet like cellular networks are not discussed, as P2P systems are discussed in the context of fixed Internet connections only. In Section 2.2.1 an overview is given over the entities involved in the Internet architecture and the role and classification of ISPs. The network characteristics of broadband access ISPs are described in Section 2.2.2. The issue of P2P systems and their relation to ISPs is discussed in Section 2.2.3. 2.2.1 Classification The Internet is made up of autonomous systems, administrative domains that are operated by entities that take the role of network operators. This section gives an overview of different types of network operators with a special focus on ISPs. ISPs are network operators whose purpose is to provide network connectivity to other entities. The networks differ in geographical extent, network degree, data volume, and place in the topology of the Internet. As shown in Figure 2.3, the networks can be classified into a hierarchy. On the bottom of the hierarchy are networks that are completely managed by a single entity and do net sell their connectivity (customer networks). They are geographically small, placed at the edge of the Internet topology, exchange small data volumes and are mostly connected to only on other network, their ISP. Examples for this class are home, company, and educational networks as well as small hosting companies. The next class are regional or tier2 ISPs, that offer transit connectivity for other networks, and large hosting and content companies. They might span a larger area, and are connected to a larger number of other networks, and exchange larger data volumes. Examples for this class are small ISPs and midsized hosting companies. The top class of the hierarchy is called the global Internet core. 2.2. Internet Service Providers 7

It consists of worldwide operating transit ISPs (tier1), large content and hosting companies, and large consumer access providers. They have a high network degree and high transit data volumes. Examples for this class are tier1 ISPs like Verizon and Deutsche Telekom, large hosting and content companies like Google and content distribution companies like Akamai [58, pp. 78-80]. Internet exchange Points (IXPs) are located between the top class and the middle class in the hierarchy. They are small networks (consisting only of a few hundred nodes), span a small area but their transit traffic volume and network degree [7] are huge. Global Internet Core Global Transit & National Backbone ISPs "yper Giants" Large Content Provider Networks, Consumer Access Provider, Content Distribution Networks IXP IXP IXP Regional/Tier 2 ISPs ISP 1 ISP 2 Customer IP Networks Figure 2.3.: ierarchical topology of the Internet [58, p. 78]. 2.2.2 Network Topology and Characteristics Most entities from the global Internet core have no direct business contacts with end customers. Large content and transit providers sell their services to other ISPs. The same is true for IXPs, content providers like Google and content distribution providers like Akamai. Often, IXPs operate at layer 2 only [7, p. 165] and are not involved with the Internet protocol or services provided by upper layers of the ISO/OSI reference model because of that. The only exceptions are large consumer access providers, for example Comcast. The approach described in this work is applicable for ISP with end costumers, because they are the ones interested in P2P LVS services. Only a few consumer access providers are yper Giants, hence can be seen as a special case. Providing a service for P2P LVS systems and users implies a business relationship with residential broadband access users. P2P LVS are alternatives to Content Delivery Networks (CDNs), hence the content providers are not the target group. This leaves tier2 ISPs as the main audience for P2P LVS optimization services. Consumer ISPs share certain network characteristics. A typical structure of a residential customer ISP is shown in Figure 2.4. It consists of three types of networks: access networks, aggregation networks and one core network. Access networks consist of devices needed for the network links to the customers. Aggregation networks aggregate the customer connections and connect them to the backbone. Both access and aggregation networks are either local or regional networks of which a number exists. There is one core network, which enables connectivity between the aggregation networks, the Internet and other parts of the ISP [33, p. 1][36, p. 1284]. The system is hierarchical; a tree is formed with the core network as root node, the access networks as leaves and aggregation networks as inner nodes. 8 2. Background

Internet ISP B ISP ISP C Access Core Aggregation Access Access Aggregation Access Access Access Broadband Customer Networks Figure 2.4.: ISP network topology by network types. Global routing on the Internet is provided by network connections to neighboring networks. The connectivity is redundant for resilience and performance. Each network operator applies its own policies for routing, with which the forwarding of its own and transit traffic can be influenced. This is not true for incoming traffic however; it can enter the ISP network on any link that is connected to another network. Predictions on where traffic from other networks enters the ISP network are hence not possible. Applying special treatment for traffic from certain networks is only possible when it is enabled on all incoming links. In the core network, IP and often MPLS are used for forwarding. It is optimized for high throughput and efficient forwarding, not for service delivery or its implementation. In the aggregation and access networks, the network protocol used for forwarding depends on the access technology. When offering Internet connectivity to consumers, the network access technology used has a big influence on the network. Network access technology groups are Digital Subscriber Line (DSL), cable and Fiber-to-the-x (FTTX). DSL uses existing telephone wires as medium, cable works on existing TV cables while FTTX relies on fiber cables to or near the access location. The currently prevalent residential network access technology is DSL both worldwide and in Western Europe. The worldwide and western European market share of DSL is about 60%. The market shares of cable are similar for both areas at about 20%. The market share of FTTX shows a difference, it is globally at about 20% and in western Europe below 10%. The remaining market share represents other connection technologies that are not listed separately [105, 93]. 2.2. Internet Service Providers 9

2.2.3 ISPs and Peer-to-Peer Systems P2P traffic makes up a considerable part of the traffic volumes [69, p. 90][58, p. 82]. ence, it affects the ISPs and their networks, and here especially residential broadband access providers. This is because the users of P2P systems are predominantly residential broadband users. Most of the data volume is caused by P2P file sharing. The effects of P2P systems on ISPs are an active research topic. While many issues arise from the usage of P2P file sharing system, many aspects are valid for P2P LVS systems too, even when they are used at a smaller scale. A good overview of the research is given in [25] and [20]. P2P systems cause considerable network traffic, while bringing no additional profit for the ISPs. Many overlay systems are unaware of the underlying network topology leading to inefficient network usage. This could result in increased usage of expensive links. The amount of data volume leaving the network could also increase. This is an issue, because of the billing structure between network operators on the Internet. While transit and tier1 providers and large networks often have different approaches for settling their peering, smaller tier2 providers have to pay for the data volume transferred. In addition, controlling P2P traffic is difficult, as it is often encrypted. Unpredictable usage pattern and traffic flows in the overlay network make it more difficult for ISPs to manage their networks and to ensure service quality for all users. A large body of approaches on how to improve this situation have been developed, good overviews are given in [20] or [25]. Unilateral remedies deployed today by ISP are throttling and blocking of P2P network traffic. owever, due to the market competition, and legal issues such as net neutrality, research suggests other solutions. One approach that can be used by P2P systems is implementing underlay awareness as described in Section 2.1.2. Even greater improvements are expected from cooperation between ISPs and P2P systems. Examples are topology information services provided by ISPs that are used by P2P systems to improve their underlay awareness. 2.3 Openflow OpenFlow is a variant of the SDN approach. Unlike earlier variants, it is supported by hardware vendors and dedicated high performance OpenFlow hardware is available. The technology is already deployed in the industry [40], and is popular in the research community. In traditional networks, the forwarding elements, such as switches or routers, consist of specialized hardware for packet forwarding, the datapath, and a general purpose CPU that runs management software. The management software configures the datapath; both, the software and the hardware are vendor specific and not standardized. The forwarding elements exchange relevant information using feature specific, standards based network protocols as shown in Figure 2.5a. The management software of such a network represents a distributed system. This has the advantage of high robustness against failures of single forwarding elements. owever, as no central entity exists, it is managed by changing settings in the configuration of the management software of single forwarding elements. Due to the distributed network state, configuration or network changes take time to disseminate through the network [90, p. 8]. It is generally not possible for researchers or users to change the behavior of forwarding elements as the vendors do not disclose details of their implementation. ence, often routers based on PCs are used, for which free open source routing software exists. owever, low performance makes software routers unsuitable for large experiments or production deployments. To change the behavior of the network, the modification of the network protocols used is necessary. This is difficult, since for changed network protocols the forwarding element s software needs to be changed. ence, standards need to be 10 2. Background

changed, which might in turn be implemented by the vendors. This situation slows down the research of networks as well as the introduction of new networking features [71, p. 12]. Feature Specific, Standards Based Network Protocols OpenFlow Normal Secure Software Channel Normal Flow Datapath Table OpenFlow Normal Secure Software Channel Normal Flow Datapath Table OpenFlow Normal Secure Software Channel Normal Flow Datapath Table (a) Traditional networking scheme. OpenFlow Controller OpenFlow Switch Secure Channel Flow Table OpenFlow Protocol OpenFlow Switch Secure Channel Flow Table OpenFlow Switch Secure Channel Flow Table (b) OpenFlow networking scheme. Figure 2.5.: A traditional networking scheme and the OpenFlow networking scheme [see 72, p. 2]. OpenFlow [72] introduces a concept for managing computer networks that aims to change this situation. OpenFlow is a standard that defines the configuration of datapaths and a protocol for the remote configuration of them: the OpenFlow protocol. This allows moving the management of the forwarding device to a central software system, the OpenFlow controller, as shown in Figure 2.5b. An OpenFlow network is still a distributed system, but centralized management is possible. OpenFlow forwarding elements are called OpenFlow switches, the datapath of an OpenFlow switch is called flow table. OpenFlow datapaths can be implemented in hardware, which allows the configuration of high performance forwarding hardware with an open standard protocol. The scopes of OpenFlow are Ethernet and TCP/IP based networks, specifically the OSI/ISO network layers 2-4. The OpenFlow controller is software that runs on a standard PC. It is connected to the OpenFlow switches, handles incoming information from them and sends configuration messages. The general packet-forwarding scheme of OpenFlow is based on rules stored in the flow table. Each rule consists of a matcher and actions. The matcher consists of values for packet header fields of Layers 2-4 of the TCP/IP network stack, that are matched against the values of arriving packets. If all values match, the list of associated actions is applied. Actions include the changing of header field values, send- 2.3. Openflow 11

ing packets out a network interface, dropping packets and sending incoming packets to the OpenFlow controller. In Section 2.3.1 an overview is given on OpenFlow, its implementations and the versions of the Open- Flow standard. The latter are described in more detail in Section 2.3.1. 2.3.1 The OpenFlow Standard The OpenFlow standards, named OpenFlow Switch Specification, define a network protocol and associated roles for communication between an OpenFlow controller and an OpenFlow switch. The purpose of the OpenFlow protocol is to enable the remote operation of the OpenFlow switch from the OpenFlow controller. The main responsibilities are the configuration of the flow table on OpenFlow switches and handling associated events. These include packets that are forwarded from the OpenFlow switch to the controller for inspection and flow table related events like rules that are remove due to timeouts. The protocol also enables the controller to configure and gather statistical data on the flow table. Finally, OpenFlow switches send events on their status to the controller; examples are a change of a network interface status. The configuration of the switch hardware is not part of the standard, however an accompanying standard, the OpenFlow Management and configuration protocol (OF-Config) [83]. Its responsibility includes the configuration of the network ports and accompanying queues as well as configuring the switches flow tables and their controller connections. The OF-Config protocol is beyond the scope of this work. The OpenFlow standard describes a network protocol and by defining the semantics of the flow table configuration messages, the behavior of an OpenFlow switch. An overview over the versions of the OpenFlow standard and their port prominent features is given, then relevant versions are described in detail in the remainder of this section. The first OpenFlow standard for public use, version 1.0, was released in 2009 [78]. It contains a simple flow table model, which also illustrates basic OpenFlow concepts. A number of updates of the OpenFlow were released. Version 1.1 was published in 2011 [80] and includes, among other changes, a fundamental change of the flow table behavior. All OpenFlow versions release after 1.1 introduces incremental changes, but no major change as from version 1.0 to 1.1. OpenFlow version 1.2 [79] published in 2011 introduces a new approach for packet matching. Two versions of the standard were released in 2012, version 1.3 [81] and 1.3.1 [84]. OpenFlow version 1.3 adds a number of supported network protocols, improves the connection to the controller and introduces interoperability to the OF-Config protocol. The latest version of the standard, version 1.3.1, contains predominantly corrections and small improvements. The last two standards will not be discussed in details, as currently no complete implementations are available, neither for the controller nor for the switch. OpenFlow 1.0 The process of packet handling in OpenFlow version 1.0 [78] starts with an incoming packet. It is matched against the rules in the flow table; the action list associated with the first matching rule is applied to the packet. The rules in the flow table are ordered by their priority value. Figure 2.6 shows the operating schema of the flow table in OpenFlow version 1.0. For matching, a set of packet header fields and the ingress port of the packets can be used as shown in Table 2.1. Matching rules consist of values for one or more of the fields, which are matched against the values of incoming packets. Fields that should not be matched can be marked as wildcard value, in this case all values match. For all fields except the IP addresses, matching means that all bits of the given value and the packet data are equal. In case of IP addresses, a subnet mask may be set, in which case 12 2. Background