Conception d’une architecture Pair-à-Pair orientée opérateur de services

In the last few years, the Internet has experienced a huge growth in terms of number of users and integration of new services. However, it has also shown some drawbacks. A model has emerged and fits in with various applications. This model experiencing a real success and that is at the center of many researches is the Peer to-Peer (P2P) model.

The particularity of P2P networks is that they belong to overlay networks that provide some services by using a specific logical topology and some nodes in the basic Internet infrastructure. The nodes are still working normally: the routing and the packets transport are still working following the network layer protocol but a layer on the top of the basic infrastructure works with its own rules in a totally transparent manner. The principal advantages of Overlay networks and especially P2P networks are scalability because of their distribution and the deployment that does not need high investment. The load is distributed among all peers and their capacities and resources are shared in order to make all peers take advantage of this aggregate of storage capacity, CPU or bandwidth.

P2P networks are experiencing a vast expansion while various types of applications are proposed generally with negligible costs. Applications that have been ascertained in the P2P model are file sharing applications like Naspter [NAP] a few years ago, Emule [KUL&al05] or BitTorrent [BIT] nowadays, instant messaging, VoIP peer-to-peer application like Skype. The higher proportion of traffic exchanged inside and between current Service Providers is the P2P traffic. While music and film production houses have launched a war against illegal content providers and consumers, the ISP have difficulties controlling and managing the P2P traffic, even before differentiating in this traffic the legal one from the illegal one. In the academic research and industrial activity we can distinguish common axes. Principal ones are video streaming, resources managing, semantic overlay networks, resilient overlay networks, signaling traffic optimization, etc.

The current Internet, composed of many Autonomous Systems, is facing an important problem that is the future challenge of OEMs (Orginial Equipment Manufacturers) and ISPs. It is to integrate the undeniable control and management level that they need to mitigate the impact of P2P traffic in current networks. We know that some techniques try to integrate QoS and resource reservation to reach some concurrent objectives, especially in the case of real time applications that need a certain level of quality. The IP protocol is not enough to ensure that these objectives will be reached. In P2P networks, only a well specified and robust control level can provide the necessary environment in which an application that needs to follow some specific objectives can run efficiently.

It is essential to present each P2P component in order to analyze the place of each contribution and the impact of implementing or changing any of its levels. A P2P protocol is composed of three major components:
• The first one is the proper data transport level. In this level are defined the protocol messages specification, the peers exchange rules, etc.
• The second component concerns data lookup and the routing algorithm that helps find the requested resource: how the queries are redirected, is the system logically structured as with Distributed Hash Tables (DHT) [JLI&al04].
• Finally we have the service that is the closest to the end user describing the application in question and the objectives (QoS rules) depending on the agreement signed with the ISP (TLA/SLA).

The majority of ISPs nowadays do not hold on the components described previously. P2P traffic is in general generated by applications that are totally independent and separated from the ISP infrastructure. After the success of structured P2P algorithms like DHT that directly acted into the routing level of P2P model, some projects tried to go further into these concepts by specifying a way to interface an ISP and its Autonomous System with the P2P applications entities. ALTO project gives rise to the P4P architecture [XIE&al07].

Following the needs of P2P protocols in terms of QoS and performance guarantee for both customers and ISPs, we can conclude that a Control/Management level must be added to ISP network architecture and that this level must be an interface to every level of the P2P model. The targets are:
• Optimizing the transport level by proposing some mechanism to ensure maximal packet entropy and the minimum loss ratio.
• Guarantying at the routing level the completion for each query with the higher rate by minimizing the steps number and the signaling packets used by the routing algorithm (overhead).
• Elaborating specifications for each service and its needs to 1) control the traffic that is generated inside the ISP network and that is exchanged between the ISP and the others for some economic reasons; 2) guarantee that the environment is conducive to the service implemented in terms of delay, bandwidth and loss rate depending on each application (real time application or data sharing have not the same constraints).

The main advantage that makes the Internet have such a huge success is the absence of the traffic control that permits deliver data with a best effort service. However, if this is a good point for some applications, other binding applications cannot find the best conditions to provide an optimized service in the basic Internet infrastructure. In P2P networks that are on top of the basic IP infrastructure, clients download resources from other peers at the same time in parallel. This flexibility in choice made P2P ton being robust and scalable. In basic protocols, traffic control is naturally solved by TCP/IP stack protocols. However in different new protocols, especially P2P ones, many ways must be integrated to control and manage this traffic depending on the application.

Traffic that is inside an ISP is easier to control than inter domain traffic. When peers from an AS1 solicit peers from AS2, the first operator responsible of AS1 must pay the traffic that was drawn from AS2 whereas when AS1 peers are using traffic from their AS this problem is not encountered. This does not mean that this traffic is not considered as a cost for AS1. Indeed, this traffic also has a cost and must be fairly controlled among all the peers depending on each QoS class required by each of them. The cause of intra domain traffic overhead is due to two principal problems: 1) When the routing protocol used by the applications is not optimized some signaling messages can disrupt the traffic especially when the queries are flooded inside the network like in Gnutella for instance [GNU01] 2) Some applications generated useless packets that must be controlled by the operator. For inter domain traffic the distributed aspect of P2P caused the generation of significant inter-domain traffic. In [KAR&al05] the authors show that for BitTorrent protocol, 50 to 90 % of local pieces are taken from other ASs. Some ISPs tend to violate peering agreements caused by traffic unbalance. Either the ISP control the traffic by estimating the needs depending on the applications or the P2P applications designers must adapt their traffic to networks variation. A compromise is here evocated concerning both the Service and the Routing level. In addition to providing traffic engineering at the Service level to control the traffic based on the application needs, it is important to adopt, at the routing level, protocols that minimize the message overhead and that provide the best performance in terms of resource lookup. The choice of DHT can be justified by their robustness and scalability. Many P2P applications propose the integration at the routing level of a structured algorithm like Chord [STO&al01], Pastry [ROW&al01], Tapestry [ZHA&al04], Kadmelia [MAY&al02], etc.

Table des matières

1. Introduction
1.1 Context
1.2 Problems and solutions
1.3 Contributions
1.4 Thesis plan
2. Overlay and Peer-to-Peer networks: Typology and Analysis
2.1 Overlay Networks
2.1.1 Overlay networks in Internet networks
2.1.2 Overlay functionality
2.1.3 Overlay networks emergence
2.1.4 Examples
2.2 Peer-to-Peer Networks
2.2.1 P2P objectives
2.2.2 Architectures
2.2.2.1 Centralized
2.2.2.2 Decentralized
2.2.2.2.1 Totally decentralized
2.2.2.2.2 Structured
2.2.2.3 Hybrid
2.2.3 Applications
2.2.3.1 File Sharing
2.2.3.2 Collaborative Computing
2.2.3.3 Real-Time Applications
2.2.3.4 Development Platforms
2.3 The BitTorrent protocol
2.3.1 Architecture
2.3.2 Functioning and protocol specification
2.3.2.1 How does BitTorrent works
2.3.2.2 Specification
2.3.3 Related works on BitTorrent
2.3.3.1 Performance studies based on measurements
2.3.3.2 Performance studies based on simulations
2.3.3.3 Performance studies based on analytical models
2.3.3.4 Contributions on locality-aware solution for BitTorrent
2.3.3.5 Contributions on erasure codes applied to BitTorrent
2.3.4 BitTorrent simulators
2.3.4.1 NS-2 for BitTorrent
2.3.4.2 OverSim on OMNet++
2.3.4.3 GPS
2.3.4.4 BTSim
2.3.4.5 Microsoft Research Octosim BitTorrent simulator
3. Peer-to-Peer traffic partitioning : a contribution
3.1 BitTorrent and peers locality
3.1.1 Aurora
3.1.2 Ono
3.1.3 TopBT
3.2 hTracker : Management and Control on a BitTorrent network
3.2.1 Problem statements and objectives
3.2.2 The hTracker architecture
3.2.3 Mapping the AS membership with the peerId
3.3 Simulations and results
3.3.1 Homogeneous networks
3.3.2 Heterogeneous networks
3.4 Conclusion
4. Integrating Forward Error Correction (FEC) in BitTorrent
protocol: Measures and Analysis
4.1 Error correction mechanisms
4.1.1 FEC at the end
4.1.2 Network Coding
4.1.3 Digital Fountain: FEC applied on blocks
4.2 Speed up data access in Peer-to-Peer content distribution
networks
4.3 The simulation framework: Seeds providing FEC
4.3.1 Homogeneous networks
4.3.2 Heterogeneous networks
4.4 Statistical test model validating the results
4.5 Conclusion
5. SPOP : a Service Provider Oriented P2P architecture
5.1 Objectives and requirements
5.2 Related works and existing architectures
5.2.1 The ALTO Project: P4P architecture
5.2.2 The SmoothIT architecture
5.3 Why proposing SPOP ?
5.4 The Service Provider Oriented P2P architecture
5.4.1 SPOP architecture plans
5.4.2 Context-Aware DHT Routing plan
5.4.3 ISP oriented FEC service for the transport plan
5.4.4 Control/Management plan
5.4.4.1 Peers Set size variation
5.4.4.2 Pieces size variation
5.4.4.3 Instantiate Seeds to compensate lack of resources
6. Global network security system: an application
6.1 Introduction
6.2 DDoS attacks overview
6.3 A P2P Collaborative Defense system based on SPOP
6.3.1 Problem Statement
6.3.2 The Distributed Hash Table algorithm
6.3.3 Description of the architecture
6.3.3.1 Principles and functioning
6.3.3.2 Simulation and results
6.3.3.3 Discussion
6.4 Conclusion
7. Conclusion

Cours gratuitTélécharger le document complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *