1. MiddleMan: A Video Caching Proxy Server NOSSDAV 2000 Brian Smith Department of Computer Science Cornell University Ithaca, NY Soam Acharya Inktomi Corporation Foster City, CA

2. VOW ( Video on the Web):1999-2000 Remote sites –eg. CNN, Mars Pathfinder, ESPN –Clinton’s testimony –“micro broadcasting” stations Local sites –corporate intranets - training videos –University-wide lecture distribution

3. Internet Problems With VOW Network unreliability Client heterogeneity Server bottlenecks Content Distribution Networks Only distribute portion of a web site Don’t improve latency as much as.. My solution: cache transmission CNN 28.8/56 Kbps T1 ISP

4. Our Goals Low end, low cost approach Scalable Utilize highly connected network of powerful commodity PCs

5. How Does It Work? P CNN P Video web caching proxy system TCP Coordinator

6. Why is this an attractive idea? Consider a University campus –50-1000 PCs –4 GB disk each –100 MB for caching –5-100 GB aggregate cache System Architecture –Proxies: cache on each end system. Acts as both client and server –Coordinator: manages cache

7. Roadmap Survey Summary Architecture: Detailed system architecture Analysis: Architecture analysis and results Comparison with other designs Conclusion and future direction

8. Characterizing Videos On The Web mid April 1997 - May 1997 about 57000 video titles 100 GB of data Web video size (~ 1 MB) Videos are WORMs

9. Characterizing User Access To Videos On The World Wide Web Traces from an ongoing Enterprise VoW trial: 2 year period 13100 requests 246 titles Video browsing pattern Partial browsing: only 61% of all movie accesses went to completion High temporal locality File size trends …

10. Roadmap Survey Summary Architecture: Detailed system architecture Analysis: Architecture analysis and results Comparison with other designs Conclusion and future direction

11. MiddleMan Design Principles Proxy cluster –proxies + one coordinator per LAN Fragmentation –videos fragmented into equal sized file fragments (1 MB “cache lines”) Partial Video Storage Policy –don’t have to keep entire video lying around –Replace on a block by block basis

12. How It Works I P WWW C P P C P Coordinator Proxy

13. How It Works II P WWW C P P C P Coordinator Proxy

14. LP SP MiddleMan: Actual Architecture C WWW LAN LP Coordinator Local Proxy Storage Proxy SP C Communication Data transfer

15. Linking Multiple Proxy Clusters CCC

16. Roadmap Survey Summary Architecture: Detailed system architecture Analysis: Architecture analysis and results Comparison with other designs Conclusion and future direction

17. Issues To Analyze Local cache size Size of file blocks Caching algorithm Controlling proxy load

18. Performance Analysis (via Simulations) Caching –analyze byte hit rates of various caching algorithms Load Balancing –load analysis on the proxies

19. The Configuration Tested 44 proxies Individual proxy cache size: –50 Mbytes (8.6% of video server size), –25 Mbytes (4.3%) –12 Mbytes (2.1%) Block size: 1 Mbyte Three sub traces: cdt, sm, campus Trace Durations: –6 months –2 years

20. Overall Cdt Cache Performance 12 MB, 2.1% 25 MB, 4.3% 50 MB, 8.6%

21. Caching Conclusion Not much difference in caching algorithm performance –cannot evaluate architecture solely based on byte hit rate –Should consider load balancing behavior

22. Load Balancing How define/measure “load”? –Dynamic: traffic in the past hour, peak # of connections, peak BW –Cumulative: byte traffic through a proxy? tested the following algorithms: –LRU –histLRUpick run LRU-2, LRU-3, LRU-4 in parallel to obtain multiple candidates for block replacement pick the least loaded block

23. Measuring Dynamic Load Balancing Performance P1 P2 P3 # of connections Total # of connections Time connections at (max) proxy # of connections Time Example Proxy Connection Plot # of connections

24. LRU histLRUpick Proxy Conns: 44 proxies, 50MB each

25. Cumulative Load balancing: Max/Min

26. Load balancing: Conclusions histLRUpick performs the best as number of proxies decrease, individual load increases Room for improvement: –RWFQ –replication

27. Roadmap Survey Summary Architecture: Detailed system architecture Analysis: Architecture analysis and results Comparison with other designs Conclusion and future direction

28. Comparison to Other Proxy Caches Internet www P P Document Characteristics –fragment, distribute video –keep initial portions of video Caching Approach –other approaches optimized for small documents high reference locality Proxy architecture –Distributed vs. centralized

29. Conclusion Caching in general is a good idea: –High hit rates for relatively small cache size HistLRUk –high hit rates –effective dynamic and cumulative load balancing Used Jigsaw, HTTP/1.1, GET/PUTs to build prototype storage proxy server

30. Future Work Other load balancing schemes Fault Tolerance FF/REW support Security/Authentication Proxy Cluster Cooperation

31. histLRUpick Dynamic Load Balancing Performance: 22 * 100 LRU reduce the number of proxies raise the cache size of each proxy to keep the same global cache size