Architecture for Distributed Content Delivery Network DCDN

1
Architecture for Distributed Content Delivery
Network (DCDN)

• (Akamai wont like it!)

2
Content Delivery - a bit of History

• Individual Web servers
• Increase in Web content
• Web Server Farms
• Issue of Flash Crowds
• Replication of same Web content around the globe
  in a net of Web servers
• Not financially viable for individual content
  providers (say, bbc.com) to set up their own
  server networks

3
Content Delivery Networks (CDN)

• What Geographically distributed network of Web
  servers around the globe (by an individual
  provider, E.g. Akamai).
• Why Improve the performance and scalability of
  content retrieval.
• How Allow several content providers to replicate
  their content in a network of servers.

4
Conventional CDN ArchitectureClassical Example
Akamai

• Figure Refhttp//arxiv.org/pdf/cs/0609027

5
Conventional CDN Architectures

• Commercial CDN
• Centralized Client-Server Architecture
• Owned by corporate companies
• E.g Akamai
• Academic CDN
• Peer-to-peer Architecture
• Designed to reduce the cost
• E.g Globule

6
Limitations of Commercial CDNs

• Network cost Huge cost involved in setting up
  clusters of servers around the globe and
  corresponding increase in network traffic.
• Economic cost Higher cost per service rate
  making them inaccessible to lower and medium
  level customers.
• Social cost Monopolization of revenue.

7
Limitations of Academic CDNs

• NO built-in network of independent servers around
  the globe.
• Efficiency at the mercy of peers.
• Content providers have to operate their own
  hosting platforms.

8
Motivation for DCDN!

• Reduce cost and improve scalability
• By making use of the resources of common Internet
  users (in terms of Storage capacity, Processing
  power, Bandwidth, Internet availability).
• By replacing conventional CDN servers with
  clusters of DCDN surrogates (aka. Internet users)
• And offer remuneration to surrogates to keep them
  alive! (Of course, from the acquired profit pool)

9
DCDN Architecture

• Best of both worlds client/server p2p
• Master DCDN Servers
• Local DCDN Servers
• DCDN Surrogates.

10

• DCDN Servers They are basically redirectors who
  have the knowledge about the location of the
  content. They do not store any content as such.
• Master DCDN servers are the first point of
  contact of a content provider.
• They monitor, regulate and control the content
  flow into DCDN servers and surrogates.
• Local DCDN Servers are placed very near to the
  end-users
• They have more local and specific knowledge about
  a particular Web content
• DCDN Surrogates are the large number of Web users
• They offer resources in terms of storage
  capacity, bandwidth and processing power to store
  and make available DCDN Web content.

11
Content Distribution Retrieval Interactions

• Content Provider Master/Local DCDN server
• Local DCDN Server - DNS Server
• Client - DNS Server
• Client - Local DCDN Server
• Local DCDN Server Surrogate
• DCDN Surrogate - Client

12
Performance Analysis

• Transmission delay at DCDN surrogate (this will
  be the bottleneck).
• Object Response Time in retrieving a content
• Queuing delay analysis to find transmission
  delays.
• Simulation techniques to compare object response
  time.

13
Queuing Analysis Results

• Performance of M/M/c/c/ models _at_ surrogates
  (where c lt 3) are found to be reasonable.
• Probable load balancing algorithm for DCDN server
  is derived on the basis of these results.

14
Simulation Scenarios

• Scenario 1- Conventional CDN 150 clients, 3
  servers, 100 Mbps link
• Scenario 2- DCDN, 150 clients, 6 surrogates, 10
  Mbps link
• Scenario 3 DCDN, 30 clients, 6 surrogates, 10
  Mbps link

15
Object Response Time
16
Conclusion Future Work

• Queuing analysis and simulation results suggest
  that DCDN architecture is viable.
• It will improve scalability and efficiency by
  pushing content to the local levels.
• Profit sharing.

• Security/integrity issues and fully-fledged
  algorithm for effective load-balancing _at_ DCDN
  server are to be addressed.
• Accounting and billing mechanism are to be
  developed.

17
Business Model

• Pyramid scheme
• Multi-level marketing (MLM) (Eg Amway)
• No big capital requirements.
• Add more surrogates to the hierarchical
  structure.
• Improve the scalability

18
Conventional CDN Architecture
19
Performance Analysis Inference

• Best performance When the surrogate serve one
  request at a time.
• Performance of M/M/c/c/ models _at_ surrogates
  (where c lt 3) are found to be reasonable.
• Larger files can be served with reasonable speed
  by surrogates with higher upload capacity.
• Probable Load Balancing Algorithms are derived on
  the basis of these inferences.