1 / 16

Relative Network Positioning via CDN Redirections

Relative Network Positioning via CDN Redirections. Ao-Jan Su , David R. Choffnes, Fabi á n E. Bustamante and Aleksandar Kuzmanovic Department of EECS Northwestern University. IEEE ICDCS 2008. Network Positioning. Why do we need network positioning systems?

jory
Download Presentation

Relative Network Positioning via CDN Redirections

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. Relative Network Positioning via CDN Redirections Ao-Jan Su, David R. Choffnes,Fabián E. Bustamante and Aleksandar Kuzmanovic Department of EECS Northwestern University IEEE ICDCS 2008

  2. Network Positioning • Why do we need network positioning systems? • Emerging large scale distributed systems can benefit from selecting among alternative nodes • Example: select an on-line gaming server • All-to-all measurements are not scalable • Current approaches • Provide network positioning services in a scalable way (e.g. landmark based) • Clear tradeoffs • Precision vs. overhead • Precision vs. deployment • And others

  3. Observations • Content distribution networks (e.g., Akamai) improve web performance by • Performing extensive network measurements • Redirecting clients to their closest replica servers • Publishing the results through DNS Can we reuse those measurements collected by CDNs to build a network positioning system?

  4. CDNs Basics • Web client’s request redirected to ‘close’ by server • Client gets web site’s DNS CNAME entry with domain name in CDN network • Hierarchy of CDN’s DNS servers direct client to 2 nearby servers Hierarchy of CDN DNS servers Internet Customer DNS servers Multiple redirections to find nearby edge servers Web replica servers (3) (4) Client is given 2 nearby web replica servers (fault tolerance) (5) Client gets CNAME entry with domain name in Akamai (2) (6) Client requests translation for yahoo LDNS (1) Web client

  5. Our approach • CDN-based Relative Network Positioning (CRP) • Clients are redirected to currently closest replica servers in general • CDN’s redirections are primarily driven by network conditions (latency) [Su et al. 2006] • Inferring relative network distance by overlapping CDN replica servers R1 R2 A C B

  6. Uses of CRP • Closest node selection • Select the closest node (shortest latency) from a group of candidates (e.g. select the closest on-line gaming server) • Methodology • Encode redirection frequency from a node to its redirected replica servers by a vector • Compare similarity (cosine similarity) of nodes’ redirection vectors to estimate proximity R1 Replica servers Server A 0.8 0.2 R2 Server B R3 Client

  7. Uses of CRP (Cont.) • Clustering • Select a set of nodes that are close to each other (e.g. replicate content to a group of nodes) • Methodology • Select cluster centers • Assign strong mapping peers to the cluster centers

  8. Evaluation Goals • Comparing the performance of CRP’s closest node selection to • Ground truth – active measurements • A state of the art network positioning system – Meridian [Wong 2005] • With respect to • Accuracy • Scalability • Deployment • Overhead Meridian: Closest node selection

  9. Experiment Setup • Globally distributed nodes • 1000 DNS servers as clients • 240 Planet Lab nodes as candidate servers (on the same nodes as our reference system – Meridian) • Concurrent data collection • Monitoring CDN redirections by recursive DNS queries for CRP • Querying Meridian via its interface • Measuring end-to-end latencies by pings as the ground truth

  10. Selecting the closest node • Clients are not close to any servers due to • Limited Planet Lab nodes coverage (Meridian) • Located in areas not well served by CDNs (CRP) CRP outperforms Meridian by 25% of the nodes due to larger deployment of CDN replica servers CRP’s accuracy is comparable to its alternative without active measurements and dedicated infrastructure CRP’s recommendations for 65% of nodes differ from Meridian by < 7ms

  11. Selecting the closest node (Cont.) Relative Error: estimated latency – ground truth CRP’s is quite accurate comparing to ground truth, with virtually no measurement overhead 80% of CRP nodes have relative error < 50ms

  12. Load on CDN’s DNS System Rank: rank 0 is the closest server • Low probe frequency • Smaller overhead • Less accurate • Miss overlapping replica servers • 100 mins probe frequency • Appropriate for 95% of nodes • Much less than CDN’s DNS TTL (20 secs) • Overhead is too small to impact CDN’s operations • High probe frequency • Can Improve accuracy • Larger overhead

  13. Load on CRP Clients • Small history • Sufficient for CRP • Small overhead • Capture network dynamics • Large history • More refined results • Larger computation overhead

  14. You May Be Wondering • “Will CDNs be unhappy because of CRP?” • CRP nodes behaves as regular web clients • CRP’s overhead does not impact CDN’s daily operations • Could be an additional service provided by CDNs • “What if CDNs change their redirection policy?” • CRP’s goal aligns with CDNs • Our approach is not restricted to a specific CDN, CRP can reuse results from other measurement infrastructures

  15. Summary • CRP discovers relative positions of end hosts • Closest node selection • Clustering • Key features of CRP • Accurate • Light-weight • Reuse CDN’s network measurements • Scalable • No dedicated infrastructure is required

  16. Cosine Similarity

More Related