Distributed Content in the Network: A Backbone View

1
Distributed Content in the Network A Backbone
View

• William Maggs
• Internet Architecture and Engineering
• MCI Worldcom
• billm_at_mci.net
• This talk http//www.vbns.net/billm/nanog14.html

2
Why Not Cache Because

• By volume, much content will be static, popular
• Not true and networks do more of their work
• Just another tool for traffic engineering
• Reliable content switching/routing (soon)
• Webtone, multimedia
• Its something to sell
• New services, new services, new services

• No Future for Static Content (40-55 dynamic)
• Content Providers dont care about cacheability
• Against Internet model
• No application servers in my POPs! f
  
• Always easier to add BW
• Technology in search of solution

3
Who Benefits?

• End Users - Latency, maybe
• Content Providers- Server load, availability,
  disaster recovery, performance to end users, slow
  network buildout, local markets, PR value, etc.
• Content Aggregators (Hosting Centers)-
  distribution of content, server load balance, new
  value-added services from content switching
• Regional Traffic Aggregators (ISPs, Cable Head
  Ends) - links to backbone, end user performance
• Global Traffic Aggregators (backbones)-system-wide
  benefits, scaling economies
• Biggest Single Benefit is to Content Provider
  but
• Largest Total Benefit is to entity that
  aggregates both content and traffic, providing
  end-to-end service

4
Where
C
Content
Provider
C
Core/
Border
Routers
C
C
Core/
Core/
ISP/
Border
Border
Head
Routers
Routers
End
C
Core/
Border
Routers
C
5
Browser (cache discovery)
Content Provider
C
Core/
Border
Routers
C
C
Core/
Core/
US
ISP/
Border
Border
Head
Routers
Routers
End
C
Core/
Border
Routers
C
6
Transparent
Content
Provider
THEM
C
Core/
peer
Border
Routers
C
peer
C
Core/
Core/
US
ISP/
Border
Border
Head
Routers
Routers
End
C
Core/
Border
Routers
C
7
Distributed Content Hosting

• A service for content providers, built on a
  content infrastructure
• for any of the networks own customers with
  content to distribute
• no complaints extends the relation between
  content provider and end user pays for improved
  performance, resilience, reach of content
  distributed close to requests
• simple to implement and manage
• Requirements
• well-engineered big network
• good management of IP address space
• content engines well-placed in network, running a
  routing daemon such as gated
• script-based tools for management
• Routing does heavy lifting of getting requests to
  content collected in convenient places in network
• Infrastructure forms basis of many new content
  services

8
How-Content Hosting
Content
Provider foo.com
166.5.20.8
166.5.20.8
foo.com
THEM
C
Core/
peer
Border
Routers
166.5.20.8
166.5.20.8
foo.com
foo.com
C
peer
C
Core/
Core/
US
ISP/
Border
Border
Head
Routers
Routers
End
C
foo.com
166.5.20.8
Core/
Border
Routers
C
foo.com
166.5.20.8
9
What-Optimum Content Distribution

• Heterogeneous, Popular Content (Web)-pulled into
  caches
• Homogeneous, Popular Content (Seinfeld)-pushed
  via MFTP or similar mechanism
• Hot Spot Content Events (cigar incident)-
  network operators already doing metaMFTP

10
Examples - Custom Content

• Advertiser wants to serve up content based on
  local markets
• Database runs behind Ad server with non-personal
  user info
• Today
• http get goes to central location, returns a
  national ad
• database crunches user info, kicks off request to
  local content engines, which return local ads
• content engines filled by push
• Future distributed database allows reverse proxy
  caching servers to receive routed requests
• allows content to be developed and maintained in
  local markets
• scales with distributed database performance to
  get ads in front of eyes as quickly as possible

11
Examples - Active Content

• Large news content provider wants to distribute
  static elements of dynamic Web pages
• requests routed to content engine .asps go to
  home server, everything else serviced locally
• home server redirects .asp static elements to
  distributed content engines
• content engines filled by caching supplemented by
  MFTP
• timeouts, delays may be dealt with by content
  engines

12
Future Technology

• Future is more or less here content engines, L4
  switches, and of course network events
• new boxes L4 switch running gated or better
• better caching server/routing daemon
  communications for failover
• appliances that the backbones will allow in their
  POPs