1. Network Protocols: Design and Analysis Polly Huang EE NTU http://cc.ee.ntu.edu.tw/~phuang phuang@cc.ee.ntu.edu.tw

2. Web Performance [Padmanabhan95a] [Wolman99a]

3. Persistent HTTP [Padmanabhan95a]

4. Polly Huang, NTU EE4 Key ideas original HTTP had more latency than necessary –overhead from doing multiple connenction proposes some fix –use one connection for multiple requests

5. Polly Huang, NTU EE5 FTP Review FTP uses two TCP connections –control: send commands –data: retrieve data (directory listings, files, etc.) HTTP motivation: just use one connection –goal: avoid server-side state –use a simpler protocol clientserver pub lib etc connect, user johnh password? xyz OK directory? OK, port 1234 cd pub OK … (application-level exchanges)

6. Polly Huang, NTU EE6 HTTP Basics clientserver GET / Hello world! the idea, at the HTTP level clientserver SYN SYN-ACK ACK GET / Hello world! ACK FIN-ACK ACK FIN and at TCP

7. Polly Huang, NTU EE7 Web Page Content But web pages consist of multiple objects –HTML –images –(also maybe Java, or CSS, or other things) HTTP/1.0: each object is a separate HTTP request, and so is a separate TCP connection

8. Polly Huang, NTU EE8 HTTP/1.0 in Practice clientserver GET / Hello world! GET /h.png [h.png data] [Padmanabhan95a,figure 3-1]

9. Polly Huang, NTU EE9 What are the problems here? TCP/HTTP costs –connection setup/tear-down –also slow-start keeps TCP at less than full speed for first few packets –TCP requires TIME-WAIT info to be kept around –if you have state (ex. authentication) then it is very expensive to have to rebuild this state for every connection

10. Polly Huang, NTU EE10 Proposed Solutions Peristent connections (P-HTTP): –use one TCP connection for multiple HTTP request/responses –in HTTP/1.1 Pipelining: –don’t wait for complete response before sending next request –try to send multiple requests at same time (in same packet) –suggestions: GETALL, GETLIST not standardized

11. Polly Huang, NTU EE11 Persistent Connection Example Client Server ACK DAT ACK 0 RTT 1 RTT 2 RTT Server reads from disk Client sends HTTP request for HTML Client parses HTML Client sends HTTP request for image Image begins to arrive DAT Server reads from disk DAT

12. Polly Huang, NTU EE12 P-HTTP Questions How to multiplex requests? –how to distinguish multiple requests and multiple responses from each other in the TCP bytestream –server can specify length but this requires server to know length ahead of time –blocking/chunking –(control connection) –pro: allow persistent connection, con: either add overhead or complexity

13. Polly Huang, NTU EE13 Complement: Parallel Connections Open multiple TCP connections (4) –first done in Netscape pros: –could be much faster (at least in terms of time to render with incremental rendering) –by doing setup & slow-start in parallel, pay the cost once at the same time for all connections cons: –overhead (setup, slow-start) is still there –much harder on the network; connections may conflict with each other –doesn’t reduce number of packets or time-wait problems

14. Polly Huang, NTU EE14 Pipelining Serialized requests still have extra RTTs Pipelining requests –GETALL – request HTML document and all embeds Requires server to parse HTML files Doesn’t consider client cached documents –GETLIST – request a set of documents Implemented as a simple set of GETs (but which ones to list?) Also could prefetching –but risk getting data you may not need

15. Polly Huang, NTU EE15 Persistent Connection Performance Benefits greatest for small objects –Up to 2x improvement in response time Server resource utilization reduced due to fewer connection establishments and fewer active connections TCP behavior improved –Longer connections help adaptation to available bandwidth –Larger congestion window improves loss recovery

16. Polly Huang, NTU EE16 Performance Results up to 2x w/10 images and pipelining RTT ~70ms, bottleneck bandwidth: 1.5Mb/s

17. Cooperative Web Caching [Wolman99a]

18. Polly Huang, NTU EE18 Key ideas improving web performance by caching look at cooperative caching –having multiple caches collaborate, share info take moderate scale measurements (traces), extrapolate that to millions clients

19. Polly Huang, NTU EE19 Simple Web Caching server-side caching client-side caching disk server cache proxy caching proxy cache

20. Polly Huang, NTU EE20 Distributed Web Caching proxy hierarchy hierarchical proxy caching cooperative proxy caching cooperative protocol

21. Polly Huang, NTU EE21 Caching Questions Does {server, client, proxy, hierarchical, cooperative} help? –relative benefits? latency bandwidth –relative costs? latency and bandwidth overheads –do they vary as a function of population? size homogenity

22. Polly Huang, NTU EE22 Cooperative Caching: Internet Cache Protocol Upon cache miss –… proxy sends request to all other peer proxies using UDP –peers respond if they have a hit Key result –Number of UDP messages with ICP increases by 2 orders of magnitude –… but ICP can increase hit rate Question: what are the trade-offs?

23. Polly Huang, NTU EE23 Web Page Popularity Access to Web pages follows Zipf’s law –The number of times the ith most popular document –… is accessed is proportional to i -a

24. Polly Huang, NTU EE24 Caching Performance? Access to Web pages follows Zipf’s law The hit ratio of large caches –Grows logarithmically with the client population –or with the number of requests seen by the cache Should nearby caches exchange their contents to improve performance? –What are the limits to this performance improvement?

25. Polly Huang, NTU EE25 Methodology Collect Web traces simultaneously from two large organizations simultaneously –University site (U-Washington) –Large corporation (Microsoft) Can study the benefits of cache cooperation at two levels of granularity –Between departments at the university –Between the large organizations Traces collected in the absence of caching –But can use these to infer the impact of caching Methodological issues –Infinite cache size assumptions –Practical (conforms to HTTP control directives) vs. ideal (assuming all documents are cacheable) caching

26. Polly Huang, NTU EE26 Impact of Client Population Higher ideal hit rate –Due to a more homogeneous accesses from MS compared to UW But, comparable hit rates with only cacheable documents –Current cacheability constraints limit performance –Many images marked uncacheable (why?) Knee of performance curve –2500 users, so cooperative caching can help if merging smaller groups [Wolman Figure 1]

27. Polly Huang, NTU EE27 Latency and Bandwidth Latency –Caching can reduce latency –Difference between practical and ideal Bandwidth –Caching reduces bandwidth –But the bandwidth reduction is insensitive to client population

28. Polly Huang, NTU EE28 Cooperative Caching Can provide some benefits –About 10% higher hit-rates than if the proxies at the organization level did not cooperate There exists little affinity of access within an organization For large populations, not much increased benefit to cooperative caching

29. Polly Huang, NTU EE29 Analytic Model to complement the trace analysis, they develop an analytic model –approximate hit rate, latency, bandwidth savings –set parameters from traces, then explore alternatives results similar to trace results –big win (hit rate, latency) to caching up to 10 5 - 10 6 users; little benefit beyond that

30. Polly Huang, NTU EE30 Summary Most benefit from small populations –But this can be served by a single proxy, so why bother with cooperative caching Some benefit for collections of small, diverse populations Greater benefits obtainable from increasing the cacheability of documents

31. Question?