Request Rerouting for ISP Operated CDNS Jeffrey

Request Rerouting for ISP Operated CDNS Jeffrey

SCHOOL OF ELECTRICAL ENGINEERING AND TELECOMMUNICATION Request rerouting for ISP operated CDNS by Jeffrey Lai Thesis submitted as a requirement for the degree Bachelor of Engineering (Electrical Engineering) Submitted: November 3, 2014 Student ID: z3372655 Supervisor: Tim Moors Topic ID: TM125 Abstract Content Delivery Networks(CDN) currently utilise the Domain Name System to direct end users towards optimal CDN replica servers. However, current CDN redirection mech- anisms do not adequately take into account DNS caching performed by end users. Specifi- cally, end-users may cache DNS answers that later lead to unoptimal CDN nodes, possibly leading to a decreased browsing experience. This document proposes a CDN redirection mechanism for ISP operated CDNs that overcomes this problem. By utilising SDN tech- niques it is possible for ISPs to perform end-user redirection at a TCP flow-based level, without relying on the end-user having up-to-date DNS information. This method is shown to demonstrate improvements in several web-browsing performance parameters such as access-delay time and page-load time. Thesis title: Request rerouting for ISP operated CDNs Topic number: TM125 Student Name: Jeffrey Lai Student ID: z3372655 A. Problem statement ISP operated CDNs and CDN-ISP collaborations are becoming increasingly common. These CDNs are in a unique position to be able to apply better request rerouting mechanisms, as well as utilise cloud and virtualised servers to rapidly create additional infrastructure as needed. There are currently no request rerouting mechanisms that can transparently reroute a user from one CDN node to another, if they have stale DNS information. Stale DNS information may arise when users cache DNS information, or if network topology changes occur that render their current information stale. B. Objective Perform an analysis on the effects of client side DNS caching on current DNS-based redirection mechanisms Design and implement a request rerouting mechanism that can reroute users in case of stale DNS information, as well as being able to utilise the creation of new CDN replica servers via cloud services. C. My solution DNS request rerouting mechanism already exists, and is proven to work – Why change what works? Propose that we augment the current DNS request rerouting mechanism with SDN techniques Using OpenFlow flow rules, detect if users are going towards an IP address belonging to a CDN we know about. Check if these users are going to the ideal CDN replica server mapped for their location (That we know since we are their ISP) If they are not going to the optimal CDN node, then perform a DNAT on their outgoing packets, and a SNAT on packets coming back from the CDN If they are going to the right CDN node, then forward and route as usual D. Contributions (at most one per line, most important first) We have successfully created a request rerouting mechanism that augments the current DNS redirection mechanism and achieves the goals listed above. Performed a first of it's kind analysis on the effects of client side DNS caching on CDN performance. E. Suggestions for future work Analyze the scalability of the mechanism that has been proposed by this thesis Generate a request rerouting algorithm that works efficiently with the mechanism proposed by this thesis While I may have benefited from discussion with other people, I certify that this thesis is entirely my own work, except where appropriately documented acknowledgements are included. Signature: __________Jeffrey Lai____________ Date: 30 / 10 / 14__ Thesis Pointers List relevant page numbers in the column on the left. Be precise and selective: Don’t list all pages of your thesis! 14 Problem Statement 14 Objective Theory (up to 5 most relevant ideas) 10 Current CDN redirection mechanisms have limitations 12 Software defined networking allows me to achieve my design goals 15 Analysis of possible ways to achieve my design goals 17 The design and theory behind my chosen solution Method of solution (up to 5 most relevant points) 19 Description of my solution 20 Description of the setup of my solution 21 Description of the testing framework for testing my solution Contributions (most important first) 35 Demonstrate that my controller works to the design goals 28 Create testing procedures to demonstrate the effects of DNS caching on CDN performance My work 21, 28 Testing procedures described, testing framework described 41 Appendix contains my code for my controller Description of procedure (e.g. for experiments) Results 31 Succinct presentation of results 35 Analysis 35 Significance of results Conclusion 38 Statement of whether the outcomes met the objectives 38 Suggestions for future research Literature: (up to 5 most important references) 3 “Pushing cdn-isp collaboration to the limit” 5 “The akamai network: A platform for high- performance applications” Abbreviations API Application Programming Interface AS Autonomous System BGP Border Gateway Protocol CDN Content Distrubution Network CLI Command Line Interface DNS Domain Name System EDNS Exenstion mechanisms for DNS HTTP HyperText Transfer Protocol IP Internet Protocol ISP Internet Service Provider Mbps Megabits per second NAT Network Address Translation OS Operating System PoP Point of Presence QoE Quality of Experience QoS Quality of Service REST Representational State Transfer RTT Return Trip Time SDN Software Defined Networking TCP Transport Control Protocol TTL Time To Live URL Uniform Resource Locator 3 Contents 1 Introduction 8 2 Background 10 2.1 Content Delivery Networks . 10 2.1.1 ISP operated CDNs . 11 2.2 Request rerouting . 12 2.2.1 Current request rerouting mechanisms . 12 2.2.2 Limitations of current request rerouting mechanisms . 13 2.3 Software Defined Networking . 15 2.4 Literature review . 15 3 Request Rerouting Mechanisms for ISP Operated CDNs 17 3.1 Problem statement & design goals . 17 3.2 Analysis of possible mechanisms . 18 3.2.1 Anycasting CDN nodes . 18 3.2.2 Using DNS augmented with NAT . 20 3.3 Experimental set up of a DNS request rerouting mechanism augmented with NAT . 24 3.3.1 Testing framework . 24 3.3.2 Testing procedures . 31 4 Results & Performance 34 4.1 Request rerouting after link failure . 34 4.2 Request rerouting during link congestion . 35 4.3 Request rerouting with the introduction of a new CDN replica server . 36 5 Evaluation 38 5.1 Results . 38 5.2 Discussion . 39 6 Conclusion 41 6.1 Future Work . 41 Bibliography 42 4 Appendix 1 44 .1 An example of a DNS request for facebook.com, a CDN hosted website. 45 .2 HTML for wikipedia.com . 45 .3 The Ryu controller for my thesis. 45 .4 The mininet topology for my thesis . 50 5 List of Figures 2.1 A visit to http://www.abc.com yields HTTP requests to various CDN hosts, as seen in the left-hand column. 11 3.1 Our network topology diagram . 25 3.2 A Trace demonstrating the typical NAT procedure that happens to a TCP flow. ....................................... 28 1 A wireshark trace of a DNS request for facebook.com . 45 6 List of Tables 2.1 Browser usage by market share . 14 3.1 Design requirements fulfilled by utilising an IP Anycast method . 20 3.2 Table miss flow that catches everything. Used as part of learning switch functionality . 26 3.3 Table miss flow that catches traffic from h1(10.0.0.1) to the CDN replica servers. 26 3.4 An example forwarding flow inserted into the switch in the case that there is no need to further redirect the end user. Note that IP destination and TCP source port values are context dependant, the values here are just examples. 26 3.5 Example flows inserted into the switch in case there is a need to further redirect the end user. Note that as with the previous table, the IP address and TCP port values are arbitrary in this case, but remain relevant between the DNAT and SNAT rules. 27 4.1 Time taken to fully traverse and load the thesis.com testpages, in seconds. 34 4.2 Time taken to fully traverse and load the thesis.com testpages, in seconds. Also shown is time delay until the client connects to the optimal CDN server over the congested one. 35 4.3 Time taken to fully traverse and load the thesis.com testpages, in seconds. 36 7 Chapter 1 Introduction Content Delivery Networks are finding an increase in usage in today's internet landscape. In response to a growing demand for high definition content, Internet Service Providers are also starting to provide and host their own CDNs [1, 2]. Large CDN providers such as Akamai have also started collaborating with ISPs to provide better services to their end users [3]. These ISP operated CDNs are in a unique position wherein they control the edge routers that sit at the last hop to their users. Because of this, ISP operated CDNs1 have a larger amount of control over how their end users are redirected towards CDN nodes. Currently, hostnames for CDN hosted websites are resolved using DNS services that provide end users with an IP address that maps to the optimal CDN node for that user at the time of request [4]. However, end user caching of DNS information can lead to an end user accessing a nonoptimal CDN node. To illustrate, we show in this thesis how a website's Quality of Experience is affected by end user caching of DNS information in modern web browsers and operating systems. The results of this testing indicate that indeed, end user DNS caching has a negative effect on website QoE. As such, DNS caching also inhibits the rapid startup and application of cloud services to adapt to changes in network topology and congestion, possibly inhibiting future ISP CDN collaboration [3].

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    53 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us