1 / 30

Design of Content Anycasting for Future Internet

Design of Content Anycasting for Future Internet. Proceeding the Second Exercises on Computer and Systems Engineering . Professor OKAMURA Laboratory. Othman Othman M.M. Outline:. Introduction. Motivation. Background and current solutions. Load-aware anycast [reference paper 2].

elam
Download Presentation

Design of Content Anycasting for Future Internet

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Design of Content Anycasting for Future Internet Proceeding the Second Exercises on Computer and Systems Engineering Professor OKAMURA Laboratory. Othman Othman M.M.

  2. Outline: • Introduction. • Motivation. • Background and current solutions. • Load-aware anycast [reference paper 2]. • Clustered BitTorrent [reference paper 3]. • Content anycasting. • OpenFlow Overview [reference paper 1]. • System Overview. • Requesting Content. • Usage Scenario. • Implementation. • Conclusion. • Q&A.

  3. 1- Introduction: • Current internet uses the Client/Server and the Peer to Peer delivery model. • Number of users grows along with their needs and demands. • Wide variety of contents ranging from web pages and emails to online videos and large file transfer. • Content Delivery Networks (CDN) were created to provide fast access and high availability.

  4. 1- Introduction: • Many technologies created or used in CDNs: • Anycast. • Load-aware Anycast [2] : which aims to improve the any cast. • Peer to Peer : e.g. BitTorrent. • Clustered BitTorrent [3].

  5. 2- Motivation: • Future internet aims to create new internet architecture for complex applications. • Important to create enabling technologies. • Content anycasting aims to: • provide the future internet’s CDN with a smarter, more flexible anycasting. • Fine granularity down to the content level. • Operates in a way that violates the current internet layered design. • Efficiently use of the bandwidth in the whole network.

  6. 3- Background and Current Solutions: • Load-aware Anycast [reference paper number 2]. • Anycast Overview. • Load-aware Anycast architecture. • Performance Evaluation. • Clustered BitTorrent [ reference paper number 3]. • Peer to Peer Overview. • Clustered BitTorrent architecture. • Peer Joining and Super Peer Selection Algorithms. • Performance Evaluation.

  7. 3.1: Load-aware Anycast [2]: 3.1.1: Anycast Overview: • Redirecting packets towards the nearest endpoint. 10.10.10.1 192.168.0.1 192.168.0.1 Endpoint B-1 10.10.10.1 Router 1 Router 1 Router 2 Router 2 Endpoint A Endpoint A Endpoint B-1 10.10.10.1 Router 3 Router 3 Router 4 Endpoint B-2 Router 4 192.168.0.2 192.168.0.2 Destination Next-Hop Distance 192.168.0.0 127.0.0.1 0 10.0.0.1 192.168.0.1 1 10.0.0.1 192.168.0.2 2 Destination Next-Hop Distance 192.168.0.0 127.0.0.1 0 10.0.0.1 192.168.0.1 1 10.0.0.1 192.168.0.2 2 • Drawbacks: • Not aware of network or endpoint loads. • Might cause session disruption.

  8. 3.1: Load-aware Anycast [2]: 3.1.2:Load-aware Anycast architecture: • Assuming servers are in single AS with large footprint (tire-1). • Rout Controller: • Centralized. • Exchanges routs with Provider Edge routers (PE). • Receive ingress l • Receive ingress load from PEs and server loads. • Aims to: • Reduce distance • React to server overload. • Reduce session disruption.

  9. 3.1: Load-aware Anycast [2]: 3.1.3: Performance Evaluation : • 4 different schemes: • SAC: Simple Anycast (native). • SLB: Simple Load Balancing. • ALB-A: Advanced Load Balancing, Always • ALB-O: Advanced Load Balancing, On-overload • Figures show number of concurrent connections to each server. (a) SAC (b) ALB-A (c) ALB-O

  10. 3.1: Load-aware Anycast [2]: 3.1.3: Performance Evaluation : • Fig 1. shows the average cost of each scheme. • Fig 2. shows the connection disruption: • SAC is high due to overloading some servers.

  11. 3.2: Clustered BitTorrent [3]: 3.2.1: Peer to Peer Overview: • Advantages of P2P: • Low cost of HW deployment. • Scalable. • Due to user contribution. • BitTorrent consists of peers and tracker (tracking server). • Disadvantages of BitTorrent: • Randomness in connections : missing a near peer. • Tracker bottleneck.

  12. 3.2: Clustered BitTorrent [3]: 3.2.2: Clustered BitTorrent architecture • Group peers into clusters according to proximity, to solve the randomness and improve performance. • Super peer, one in each cluster acts as a local tracker for its cluster, to solve the tracker overloading. • A new peer will : • get list of super peers form tracker upon request. • And perform a peer joining algorithm to find which cluster to join.

  13. 3.2: Clustered BitTorrent[3]: 3.2.3: Peer Joining and Super Peer Selection Algorithms • Proximity is measured by distance: • distance is measured by RTT (Round Trip Time) and TTL (Time To Live)(hop count) measured by traceroute measurement. • Peer Joining: • Done by new peers to find nearest cluster to join. • After getting list of super peers from tracker, probe all of them, and join the nearest. • Super peer selection: • Chosen form list of seeds willing to be super seed in a new cluster. • Finding the farthest seed in the list of candidate seeds.

  14. 3.2: Clustered BitTorrent [3]: 3.2.4: Performance Evaluation: • Average completion time for a file download is shown in the figure: • 30% reduction in 100 peer. • 35% reduction in 1500 peer.

  15. 4- Content anycasting :4.1: OpenFlow Overview[1]: • Separates routing decision making (in controller) and the forwarding (in the switch or router). • Matching in the switch or router is done according to Layer 2, 3 and VLAN headers. Figure 1: OpenFlow switch (ref: Nick McKeown et al, “OpenFlow: enabling innovation in campus networks”)

  16. 4- Content anycasting : 4.1: OpenFlow Overview [1]: • OpenFlow relies on the Flow-table, which is contains: • Header fields are the ones the incoming packet is matched against: • The actions can be : forwarding the packet to physical port, enqueue the packet in a physical port’s queue, dropping the packet or modifying incoming packet’s header fields Figure 1 Figure 2

  17. 4- Content anycasting : 4.2: System Overview: • Content Server: • supports content id. • send redirection request to the anycast manager. • Support the modified content request to serve contents to clients. • Anycast Manager: • Manage and organize redirection requests between multiple anycast managers. • Creating redirections and sending them to the OpenFlow switches or routers. Content Server • Anycast Manager Autonomous System 1 Anycast Manager Autonomous System 2 client client

  18. 4- Content anycasting : 4.2: System Overview: • OpenFlow router or switch: • caries out the redirection created by the anycast manager. • Match incoming packets for content id and server IP address. • If match change the destination IP to be that of other client. • User Client: • contribute by providing content to other user clients. • support the modified content request. Content Server • Anycast Manager Autonomous System 1 • Anycast Manager Autonomous System 2 client client

  19. 4- Content anycasting : Anycast Manager: • Functionality: • Receive the redirection request form the content server. • If the redirections are in the same AS make redirections and send them to the OpenFlow routers or switches. • And if in different AS send the redirection request to the appropriate anycast manager. Receive redirection request Lookup AS numbers for each current user client’s IP address in the redirection request Generate copies of the redirection request each designated for one AS Is the copy for this AS Yes No Send it to the anycast manager of the AS to which this copy is designated to Create redirections and send them

  20. 4- Content anycasting : 4.3: Requesting Content: Two phases: • Phase 1: • Client browses to find desired content. • Client sends the request (e.g. HTTP GET) • Server responds with content ID, to be sued in phase 2 to get the file. • Phase 2: • Uses 3 way handshake. • Requires modification to the TCP.

  21. 4- Content anycasting : 4.3: Requesting Content: • Phase 2: TCP headers modifications: • Adding the content id: will be used to redirect the packet by the OpenFlow router or switch. • Upload capabilities: used by the redirection system to make the number of redirections according to it. • IP address: to tell the other part of the self IP address.

  22. 4- Content anycasting : 4.3: Requesting Content: • Phase 2: 3 way handshake: • Start with SYN packet that is sent to the server. • Using OpenFlow and the content id packet will be redirected to an other client (Current Client). • Current client acknowledge to the SYN with its IP in packet. • New client starts to use the Current client’s IP address in the session. OpenFlow router New Client Current Client Destination: serverIP :SYN Destination: CurrentClientIP :SYN SYN/ACK With CurrentClientIP Destination: CurrentClientIP :SYN

  23. 4- Content anycasting : 4.4: Usage Scenario: anycast Manager 1 Content Server if Destination IP: 10.10.10.1 & Content id: 12345 Change : Destination IP: 192.168.10.1 2 3 10.10.10.1 Client A Client B 192.168.10.1 192.168.20.1

  24. 4- Content anycasting : 4.4: Usage Scenario: This figure shows the initiation of the redirection : • Step 1: the server sends the redirection request, which includes the contents ids and the IP addresses of the clients downloading those files along with their uploading capabilities. • Step 2: the anycast manager makes the OpenFlow redirections and sends them to the OpenFlow switch or router. • Step 3: OpenFlow switch or router stores the redirections.

  25. 4- Content anycasting : 4.4: Usage Scenario: This figure shows the first phase of the content request. • Step 1: client B requests the content id. • Step 2: server sends the content id to the client B. anycast Manager 10.10.10.1 Content Server 1 192.168.20.1 192.168.10.1 Client A Client B 2 Content id: 12345

  26. 4- Content anycasting : 4.4: Usage Scenario: Destination IP: 10.10.10.1 Content id: 12345 10.10.10.1 anycast Manager Content Server 2 Destination IP: 192.168.10.1 Content id: 12345 1 Client B Client A 3 192.168.20.1 192.168.10.1

  27. 4- Content anycasting : 4.4: Usage Scenario: This figure shows the second phase of requesting content: • Step 1: • sending the first packet in the hand shake. • Contains the content id. • Step 2: • Redirected by the OpenFlow using the content id and destination IP. • Step 3: • Client A acknowledge to the packet sent in step 1. • File transfer starts between client A and client B.

  28. 4- Content anycasting : 4.5: Implementation: • Currently we are building redirection system, modified content server, modified clients and using the reference OpenFlow implementation. • First, Redirection system with one anycast manager. • Second, duplicate redirection systems each with its own anycast manager. • Aiming to measure: communication cost, response time, efficiency in different load patterns and others. • And comparing those values to other solutions like the anycast and peer to peer.

  29. 5- Conclusion: • Our design makes use of OpenFlow to perform the redirection of packets along with using content id in addition to the destination IP to make the redirection decision. • And to enable that we designed a two phase content request, for getting the content id and using it. • The goal is provide the future internet’s CDNs with a smarter, more flexible anycasting which has a finer granularity that goes down to the content level rather than the server level in a way that violates the current internet’s layered design.

  30. 9- Q&A: • Thank you for listening.

More Related