CDN Brokering*

Presented ByNick Arnold

AuthorsAlexandros Biliris, et. Al

Topics*- Conjecture- Introduction- General CDN Brokering

- Selection- Redirection- Naming- Accounting

- IDNS- DNS Element- Control Element

- Performance & Results- Future Work- Questions

2

Conjecture

3

If caches can do it, so can we!

• Purpose is the same as caches– Decrease latency– Reduce Web Server work (costly)

• Inter-cache communication– Could work (optimally)– Not widely used

• CDNs distinct advantage?– Built on “capital-intensive” network– Better suited for “flash-crowds”

4

Introduction

5

This is why…

CDN Advantages:Can pay a fee to use high-powered operation.

This lets the little guy in (15 minutes of fame on your smalltime blog/video).

Decreased Latency!

6

…and why not.

• CDN DisadvantagesVery Costly.

Operationally Complex.

Rely on Locality.

7

What is CDN Brokering?

“Ability of one CDN to redirect clients dynamically among two or more CDNs”.

A specific implementation is covered in this paper.

The key is dynamic.

8

Background / Motivation

Equality:CDN x != CDN y

Goals:x -> “I want to serve the whole world!”y -> “I love YouTube and no one else!”

$$$:1. Overloaded? I’ll help you for $.2. I built this server, you can use it too…for $$.3. It’s a part of the design!

9

General CDN Brokering

10

Big Components

1. Selection2. Redirection3. Naming4. Accounting (I told you)

11

Selection

Our first and biggest objective:Where did the request come from?

Where should the request go?

Quickly.

12

Redirection

Going somewhere else:Use DNS.

Overhead of Brokering vs. Latency.

Enforced by TTL.

13

Naming

DNS Mapping:Name Server (NS) Redirection – The destination CDN is made authoritative for lowest level of domain name.

CNAME Redirection – Use Host Header in HTTP to identify content.*

*Only works if all servers treated the same. Otherwise, format must be agreed upon.

14

Accounting

$$$ is the driving factor:CDN is built on shares. Needs to “account” for measuring the usage of links.

Would this be included in an academic paper?

15

Intelligent Domain Name Server

16

IDNS How requests are passed

17

External vs. Internal

External• Forward request to another

CDN• Give client DNS resolution

for new CDN.• Client DNS resolves to get A

record of Edge Server

InternalOptions:

1. Return A record2. Triangular Resolution –

forward DNS query, let internal DNS respond to client DNS

3. Redirect to internal DNS just like external

18

IDNS Architecture

19

Several Critical Components of the IDNS DNS Element

DNS Engine Control Element

Control ComponentConfiguration AgentManagement AgentLoad Agent

DNS Element

Main Purpose: – Receive and answer DNS queries from the

network.

Main Structure: – Consists of only the “DNS Engine”. – Uses tables for lookups of where to route

request.

20

“Smart” Tables

Region table: clustered IP-addresses -> matched by longest prefix-match

Distribution table: Distinguished by “Service”.-> Multiple of them.-> 1 entry/region (type, CDN or DNS)

Customer Table: defined by your DNS name and particular distribution table

21

Resolving a Request

• One longest prefix match• One hash table lookup• One array element lookup• Simplified Random Number GeneratorO(1) + O(1) + O(log n) + O(1)

22

Control Element

Asynchronous Updating -> Dynamic!

Regions, customers, and CDNs are our measurements.

Load Balancing: -Our most important act--> Update the tables for the DNS Engine-> Probability Distribution

23

Agents

24

Configuration Agent:Task: Initialization

Management Agent:Task: Run-time, administrator control

Load Agent:Task: Communicate with other CDNs

Performance & Results

25

What should we test?

No established benchmark for this system.

Break into three categories:1. Brokering Server Performance2. Overhead3. Overall Performance

Got an idea for another test?

26

Test 1: Test Single Broker Server

SetupMeasure the front-end (DNS Engine) with the back-end (Control Element) performanceBasics (Simulated):Three situations -> No updates (only DNS Engine)

5 CDNS, 50 customers, 250 regions -> 1 update/sec (Both) 1-10 CDNs, 1-100 customers, 1-500 regions -> Max updates/sec (Heavy back-end) 1-10 CDNs, 1-100 customers, 1-500 regions

27

Test 1: Results

28

Test 2: Redirection Overhead

The big question: Is it worth it?Setup

Case Study – Examination of Packet Traces on DNSIncludes 6 websites, 25,000 clients

Three types of sites: Regular, CDN, and BrokeredUsed dig to issue requests (Domain Information Groper)Settings

- > Cold Client DNS- > “Lukewarm” Client DNS

29

Test 2: Results

30

Results Continued…

31

Test 3: Do we measure up?

Setup2 real CDNs, 2 web sites11 locations (worldwide)1 HTML object13 imbedded images4 parallel connections10x test runs.

PurposeWant to see if website performance is increased through use of CDN sharing

32

Test 3: Results

Neither CDN outperformed the other ~=82 KB/s > 52 KB/sInitial Delay decreased to 0.30 seconds**by?

33

Future Work

34

What else can be done?

• Research into reliance on locality -> CDNs biggest problem

• Content Bridge -> exchange between symbiotic networks.

• Closer inspection of load balancing.• …

35

My Thoughts

On the structure…• Brokering DNS is a bottleneck.• Uses the DNS structure for all routing, not the purpose.• Cool because it was actually implemented (IRL)

On the paper…• A lot of corners cut (e.g. semantic mapping, algorithm

for load information)• Fault tolerance and improve scale?• Doesn’t seem that useful.

36

Your Thoughts?

37