1. The Case for Persistent-Connection HTTP Telecommunication System LAB 최 명길 Western Research Laboratory Research Report 95/4 (Proceedings of the SIGCOMM ’95 Conference on Communication Architectures and Protocols)

2. 2 Contents 1. Introduction 2. Overviews of the HTTP Protocol 3. Analysis of HTTP’s inefficiencies 4. Proposed HTTP modifications 5. Design issues 6. Competing and complementary approaches 7. Simulation experiment design 8. Simulation results 9. Related work 10. Future work 11. Summary and conclusion

3. 3 Critique  Strong Points As the way of decreasing web latency, protocol level method proposed Analysis of existing HTTP protocol, alternative protocol is suggested To prove the usefulness of the P-HTTP protocol suggested, the simulation is experimented in term of variable respects  Weak Points The paper does not clearly present the way of using P-HTTP protocol with existing HTTP protocol together The P-HTTP protocol proposed In this paper does not clearly prove the usefulness in real web client-server environment in terms of functionality The paper does not experimental data concerning P-HTTP protocol compared with the existing approach adopted in Netscape  Suggestions Make a brower program to support HTTP and P-HTTP protocol simultaneously and distribute it through Internet Before spreading it, the brower supporting HTTP, P-HTTP in private network

4. 4 Introduction and HTTP Overview  Web Latency Network Communication Propagation Delay  The Solution of Web Latency Minimize the number of network round-trip Modifying HTTP protocol Network Communication  HTPP Request GET, PUT, POST, URL, HERQ header, Optimal Data field  Server Response Status Code Object Header Data Field

5. 5 Analysis of HTTP’s inefficiencies  The Present HTTP Round trips

6. 6 Other inefficiencies  Other inefficiencies Connection setup requires additional costs to network latencies (new port, resource, data structure) Processing overhead at server and clients TCP Spec per connection require for certain time

7. 7 Proposed HTTP Modifications  One TCP connection for multiple request  Persistent-connection time HTTP  Method : Server mark the end of a response

8. 8 Protocol Negotiation  Protocol negotiation Current HTTP client, server -> P-HTTP protocol (infeasible) PHTTP client, server : HTTP client, server (unpractical) P-HTTP server, HTTP client (proposed)

9. 9 Design Issue  Effects on Reliability Server close connection arbitrarily impair reliability Race between client request and server termination Non-idempotent operation such as form to order products  Interactions with current proxy servers Client (P-HTTP) – Proxy(HTTP) – Server (P-HTTP) Server expects TCP open Proxy does not know P-HTTP, so server close connection Proxy waits forever Solution : Adaptive time scheme Server lists IP address Client use P-HTTP Server give a second for first request, and increase time for subsequent request P-HTTP client realize that a HTTP only proxy is in use Client do not attempt to use P-HTTP

10. 10 Design Issue  Connection lifetime The server has too many open connections in P-HTTP Server close an idle connection at any rate  Server consumes resource CPU time, active connection, protocol control block(PCB) table space : the influence of persistent connection model to resource utilization The maximum number of open connection as parameter P-HTTP serve close idle connection as needed The number of PCB table entries has two components Open connections number (ESTABLISHED, CLOSING) Closed connections number (TIME_WAIT connection)

11. 11 Design Issue  Server congestion control HTTP client never know the status of server P-HTTP protocol control the request arrival time  Network Resource P-HTTP reduce the number of overheads packets and reduce the bandwidth load Improve the congestion behavior of the network by giving the state of network In P-HTTP, requests and replies could be streamed at full network bandwidth  User’s Perceived Performance The time required to retrieve and display web page User prefer response times below two to four seconds User likes to know a high mean retrieved time and low variance

12. 12 Competing and complementary approaches Simulation Design  Netscape open multiple connections in parallel Eliminate unnecessary latency without requiring a new protocol  Drawbacks of Network Resource Increase the chances for network congestion Do not know the state of the network  Simulation Experiment Design The behavior of P-HTTP server using log of actual HTTP  The specific question to address by simulation The sufficient locality of reference in clients Reduction of server resource utilization The adaptive timeout mechanism destroy the ability of the proposal

13. 13 Trace Data Set  Data set 1994, CAL. election servers (1.6M HTTP requests in a 10 day) Large Corp. Public web site (3.4M, HTTP requests in a 82 day) Election Service has three servers, load sharing (intensive, very few days, 24,000 clients) Corp. server has low peak load (low peak load, 134,000 clients)  Different Access Pattern [fig 4] : the cumulative distribution of retrieval size [fig 5] : the retrieval time

14. 14

15. 15 Simulator Overview  P- HTTP Server behavior Open Connection, Server’s PCB table TIME_WAIT entries, Adaptive timeout database  The connection(session layer) behavior  The simulator process order Parse the log file, connection open, connection close Sorts the event records in time-sequence order Go through the event record in time stamp order 1) Already connection open event – update statistic counters 2) Connection create or connection close (above max) 3) Connection close Longer Idle connection remove Adaptive timeout mechanism

16. 16 Summary of Simulation Parameter  P-HTTP mode  Maximum number of open connections  Idle-timeout  2*MSL timeout  Adaptive-timeout table size  Initial idle-timeout

17. 17 Validation  Election Server HTTP Protocol simulation PCB Table 15 minute 2*MSL timeout : 60 sec TIME_WAIT overestimate Underestimate the number of ESTABLISHED connection Many connections longer than log record The logged connection fail to round trip Network

18. 18

19. 19 Simulation Results  Connection Refusal Rates The number of connections refused in terms of idle-time out and max connection limit Support at least 32 simultaneous connections

20. 20 Connection Re-use Rate  The frequency P-HHTP protocol pay off in term of reduced latency The number of times a request arrives for an already-open connection P-HTTP optimal hit rate for election service

21. 21

22. 22 Connection Re-use Rate  Complement of the number of open connection hit  The success rate of the persistent connection approach by number of HTTP request per TCP connection  Not hard to satisfy ten or more HTTP request with one TCP connection

23. 23 Connection Re-use Rate  Cmax, Standard Deviation different according to Cmax

24. 24 The Effect of a Web Indexer  One client responsible for most HTTP retrieval in Corp. Serve  Filter out Indexer

25. 25

26. 26 Success Rate views by clients  What fraction of the Clients hosts saw a high rate TCP connection limited to a small subset of the client hosts clients distributed among a wide set of clients Individual client send 20 HTTP request over a single TCP connection

27. 27 Success Rate views by clients The distribution of the P-HTTP depend on the server parameter

28. 28 Frequency of forced closes  P-HTTP server close an idle TCP connection Make a room for a request from a different client The connection longer idle than idle timeout parameter The Election service run Cmax and close idle connection

29. 29 Frequency of forced closes Many connection persist for many seconds

30. 30 PCB table use  The simulator counts ESTABLISED and TIME_WAIT entries Few PCM table entries (good open connection hit rate) TIME-WAIT entries does not depend on idle timeout parameter Most of TIME_WAIT entries by forced closes

31. 31 PCB table use

32. 32 Adaptive timeout  The result for P-HTTP server without adaptive timeout

33. 33 Adaptive timeout  Overlap with the curve for the adaptive timeout case

34. 34 Network Loading, Related Work, Future Work  Network Loading Difficult to predict P-HTTP affect the network load P-HTTP improve the dynamics of the Internet Possible to estimate congestion avoided by P-HHTP  Related Work Locality of reference in the context of intermediary caching Feasibility or performance of intermediary caching server  Future Work By assumption, the simulator could generator a modified event trace reflecting these short times Using some semantic information, simulate the actual response times seen by users The simulator could be modified to provide periodic statistics

35. 35 Summary and Conclusion  Summary and Conclusion P-HTTP reduce the response time, server overheads and network overheads of HTTP Maximum number of active connections increase user’s perceived performance The feasibility of P-HTTP depends on the availability of robust client and server implementation and the conversions of proxies