120 likes | 146 Views
This talk by William Maggs explores the importance of distributed content in the network, its benefits, and future technologies. The talk discusses how content providers, hosting centers, ISPs, and backbones can benefit from distributed content.
E N D
Distributed Content in the Network: A Backbone View William Maggs Internet Architecture and Engineering MCI Worldcom billm@mci.net This talk: http://www.vbns.net/billm/nanog14.html
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 It’s something to sell New services, new services, new services No Future for Static Content (40-55% dynamic) “Content Providers don’t care about cacheability” Against Internet “model” No application servers in my POPs! f Always easier to add BW Technology in search of solution Why Not Cache Because
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
Hosting Center Wireless Network (content translation) Where C Content Provider C Core/ Border Routers C C Core/ Core/ ISP/ Border Border Head Routers Routers End C Core/ Border Routers C
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
Hosting Center 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
Distributed Content Hosting • A service for content providers, built on a content infrastructure • for any of the network’s 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
Hosting Center 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
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
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
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
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