1. 15-744: Computer Networking L-20 Applications

2. L -20; 4-2-01© Srinivasan Seshan, 20012 Next Lecture: Application Networking HTTP Adaptive applications Assigned reading [BSR99] An Integrated Congestion Management Architecture for Internet Hosts [CT90] Architectural Consideration for a New Generation of Protocols

3. L -20; 4-2-01© Srinivasan Seshan, 20013 Overview HTTP Basics HTTP Fixes ALF Congestion Manager

4. L -20; 4-2-01© Srinivasan Seshan, 20014 HTTP Basics HTTP layered over bidirectional byte stream Almost always TCP Interaction Client sends request to server, followed by response from server to client Requests/responses are encoded in text How to mark end of message? Size of message  Content-Length Must know size of transfer in advance Delimiter  MIME style Content-Type Server must “byte-stuff” Close connection Only server can do this

5. L -20; 4-2-01© Srinivasan Seshan, 20015 HTTP Request Request line Method GET – return URI HEAD – return headers only of GET response POST – send data to the server (forms, etc.) URI E.g. http://www.seshan.org/index.html with a proxyhttp://www.seshan.org/index.html E.g. /index.html if no proxy HTTP version

6. L -20; 4-2-01© Srinivasan Seshan, 20016 HTTP Request Request headers Authorization – authentication info Acceptable document types/encodings From – user email If-Modified-Since Referer – what caused this page to be requested User-Agent – client software Blank-line Body

7. L -20; 4-2-01© Srinivasan Seshan, 20017 HTTP Request Example GET / HTTP/1.1 Accept: */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Host: www.seshan.orgwww.seshan.org Connection: Keep-Alive

8. L -20; 4-2-01© Srinivasan Seshan, 20018 HTTP Response Status-line HTTP version 3 digit response code 1XX – informational 2XX – success 3XX – redirection 4XX – client error 5XX – server error Reason phrase

9. L -20; 4-2-01© Srinivasan Seshan, 20019 HTTP Response Headers Location – for redirection Server – server software WWW-Authenticate – request for authentication Allow – list of methods supported (get, head, etc) Content-Encoding – E.g x-gzip Content-Length Content-Type Expires Last-Modified Blank-line Body

10. L -20; 4-2-01© Srinivasan Seshan, 200110 HTTP Response Example HTTP/1.1 200 OK Date: Tue, 27 Mar 2001 03:49:38 GMT Server: Apache/1.3.14 (Unix) (Red-Hat/Linux) mod_ssl/2.7.1 OpenSSL/0.9.5a DAV/1.0.2 PHP/4.0.1pl2 mod_perl/1.24 Last-Modified: Mon, 29 Jan 2001 17:54:18 GMT ETag: "7a11f-10ed-3a75ae4a" Accept-Ranges: bytes Content-Length: 4333 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html …..

11. L -20; 4-2-01© Srinivasan Seshan, 200111 Typical Workload Multiple (typically small) objects per page Request sizes In this paper  Median 1946 bytes, mean 13767 bytes Why such a difference? Heavy-tailed distribution Pareto – p(x) = ak a x -(a+1) File sizes Why different than request sizes? Also heavy-tailed Pareto distribution for tail Lognormal for body of distribution

12. L -20; 4-2-01© Srinivasan Seshan, 200112 Typical Workload Popularity Zipf distribution (P = kr -1 ) Surprisingly common Embedded references Number of embedded objects = pareto Temporal locality Modeled as distance into push-down stack Lognormal distribution of stack distances Request interarrival Bursty request patterns

13. L -20; 4-2-01© Srinivasan Seshan, 200113 HTTP Caching Clients often cache documents Challenge: update of documents If-Modified-Since requests to check HTTP 0.9/1.0 used just date HTTP 1.1 has file signature as well When/how often should the original be checked for changes? Check every time? Check each session? Day? Etc? Use Expires header If no Expires, often use Last-Modified as estimate

14. L -20; 4-2-01© Srinivasan Seshan, 200114 Example Cache Check Request GET / HTTP/1.1 Accept: */* Accept-Language: en-us Accept-Encoding: gzip, deflate If-Modified-Since: Mon, 29 Jan 2001 17:54:18 GMT If-None-Match: "7a11f-10ed-3a75ae4a" User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Host: www.seshan.org Connection: Keep-Alive

15. L -20; 4-2-01© Srinivasan Seshan, 200115 Example Cache Check Response HTTP/1.1 304 Not Modified Date: Tue, 27 Mar 2001 03:50:51 GMT Server: Apache/1.3.14 (Unix) (Red- Hat/Linux) mod_ssl/2.7.1 OpenSSL/0.9.5a DAV/1.0.2 PHP/4.0.1pl2 mod_perl/1.24 Connection: Keep-Alive Keep-Alive: timeout=15, max=100 ETag: "7a11f-10ed-3a75ae4a"

16. L -20; 4-2-01© Srinivasan Seshan, 200116 HTTP 0.9/1.0 One request/response per TCP connection Simple to implement Disadvantages Multiple connection setups  three-way handshake each time Several extra round trips added to transfer Multiple slow starts

17. L -20; 4-2-01© Srinivasan Seshan, 200117 Single Transfer Example ClientServer SYN ACK DAT FIN ACK 0 RTT 1 RTT 2 RTT 3 RTT 4 RTT Server reads from disk FIN Server reads from disk Client opens TCP connection Client sends HTTP request for HTML Client parses HTML Client opens TCP connection Client sends HTTP request for image Image begins to arrive

18. L -20; 4-2-01© Srinivasan Seshan, 200118 More Problems Short transfers are hard on TCP Stuck in slow start Loss recovery is poor when windows are small Lots of extra connections Increases server state/processing Server also forced to keep TIME_WAIT connection state Why must server keep these? Tends to be an order of magnitude greater than #of active connections, why?

19. L -20; 4-2-01© Srinivasan Seshan, 200119 Overview HTTP Basics HTTP Fixes ALF Congestion Manager

20. L -20; 4-2-01© Srinivasan Seshan, 200120 Netscape Solution Use multiple concurrent connections to improve response time Different parts of Web page arrive independently Can grab more of the network bandwidth than other users Doesn’t necessarily improve response time TCP loss recovery ends up being timeout dominated because windows are small

21. L -20; 4-2-01© Srinivasan Seshan, 200121 Persistent Connection Solution Multiplex multiple transfers onto one TCP connection Serialize transfers  client makes next request only after previous response How to demultiplex requests/responses Content-length and delimiter  same problems as before Block-based transmission – send in multiple length delimited blocks Store-and-forward – wait for entire response and then use content-length PM95 solution – use existing methods and close connection otherwise

22. L -20; 4-2-01© Srinivasan Seshan, 200122 Persistent Connection Example ClientServer 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

23. L -20; 4-2-01© Srinivasan Seshan, 200123 Persistent Connection Solution Serialized requests do not improve response time 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 Prefetching Must carefully balance impact of unused data transfers Not widely used due to poor hit rates

24. L -20; 4-2-01© Srinivasan Seshan, 200124 Persistent Connection Performance Benefits greatest for small objects Up to 2x improvement in response time Server resource utilization reduce 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

25. L -20; 4-2-01© Srinivasan Seshan, 200125 Remaining Problems Application specific solution to transport protocol problems Stall in transfer of one object prevents delivery of others Serialized transmission Much of the useful information in first few bytes Can “packetize” transfer over TCP HTTP 1.1 recommends using range requests MUX protocol provides similar generic solution Solve the problem at the transport layer Tcp-Int/CM/TCP control block interdependence

26. L -20; 4-2-01© Srinivasan Seshan, 200126 Overview HTTP Basics HTTP Fixes ALF Congestion Manager

27. L -20; 4-2-01© Srinivasan Seshan, 200127 Integrated Layer Processing (ILP) Layering is convenient for architecture but not for implementations Combining data manipulation operations across layers provides gains E.g. copy and checksum combined provides 90Mbps vs. 60Mbps separated Protocol design must be done carefully to enable ILP Presentation overhead, application-specific processing >> other processing Target for ILP optimization

28. L -20; 4-2-01© Srinivasan Seshan, 200128 Application Lever Framing (ALF) Objective: enable application to process data ASAP Application response to loss Retransmit (TCP applications) Ignore (UDP applications) Recompute/send new data (clever application) Expose unit of application processing (ADU) to protocol stack

29. L -20; 4-2-01© Srinivasan Seshan, 200129 Application Data Units Requirements ADUs can be processed in any order Naming of ADUs should help identify position in stream Size Enough to process independently Impact on loss recovery What if size is too large?

30. L -20; 4-2-01© Srinivasan Seshan, 200130 Overview HTTP Basics HTTP Fixes ALF Congestion Manager

31. L -20; 4-2-01© Srinivasan Seshan, 200131 Socket API Connection establishment Connect – active connect Bind, listen, accept – passive connect Transmission/reception Send & sendto Recv & recvfrom Pass large buffer to protocol stack Protocol transmits at either congestion controlled or line rate Configuration/status E.g advertised window, nagle, multicast membership, etc. Setsockopt, getsockopt Very little information really passed to/controlled by application

32. L -20; 4-2-01© Srinivasan Seshan, 200132 CM Requirements Determining correct rate of transmission = congestion control What is wrong with congestion control today? “Multimedia Transmissions Drive Net Toward Gridlock” New York Times 8/23/99 Tightly integrated with TCP Congestion control is vital to network stability

33. L -20; 4-2-01© Srinivasan Seshan, 200133 Problems with Concurrent Flows Compete for resources N “slow starts” = aggressive No shared learning = inefficient f(n) f2 f1 Server Client Abstract all congestion-related information into one location Internet

34. L -20; 4-2-01© Srinivasan Seshan, 200134 Problems Adapting to Network State TCP hides network state New applications may not use TCP Often do not adapt to congestion Need system that helps applications learn and adapt to congestion f1 Server Client ? Internet

35. L -20; 4-2-01© Srinivasan Seshan, 200135 API High Level View IP HTTPVideo1 TCP2UDP AudioVideo2 All congestion management tasks performed in CM Applications learn and adapt using API All congestion management tasks performed in CM Applications learn and adapt using API Congestion Manager Per-macroflow statistics (cwnd, rtt, etc.) TCP1

36. L -20; 4-2-01© Srinivasan Seshan, 200136 Design Requirements How does CM control when and whose transmissions occur? Keep application in control of what to send How does CM discover network state? What information is shared? What is the granularity of sharing? Key issues: API and information sharing

37. L -20; 4-2-01© Srinivasan Seshan, 200137 The CM Architecture Transmitting Application (TCP, conferencing app, etc) Prober Congestion Controller Scheduler Responder Congestion Detector SenderReceiver CM Protocol API Receiving Application Protocol

38. L -20; 4-2-01© Srinivasan Seshan, 200138 Congestion Controller Responsible for deciding when to send a packet Window-based AIMD with traffic shaping Exponential aging when feedback low Halve window every RTT (minimum) Plug in other algorithms Selected on a “macro-flow” granularity

39. L -20; 4-2-01© Srinivasan Seshan, 200139 Scheduler Responsible for deciding who should send a packet Hierarchical round robin Hints from application or receiver Used to prioritize flows Plug in other algorithms Selected on a “macro-flow” granularity Prioritization interface may be different

40. L -20; 4-2-01© Srinivasan Seshan, 200140 Transmission API Buffered send cm_send(data, length) Request/callback-based send cm_request( ) cmapp_send( ) App CM IP send( ) cm_notify(nsent)

41. L -20; 4-2-01© Srinivasan Seshan, 200141 Transmission API (cont.) Request API: asynchronous sources wait for (some_events) { get_data( ); send( ); } Synchronous sources do_every_t_ms { get_data( ); send( ); } Solution: cmapp_update(rate, srtt) callback

42. L -20; 4-2-01© Srinivasan Seshan, 200142 Feedback about Network State Monitoring successes and losses Application hints Probing system Notification API (application hints) Application calls cm_update(nsent, nrecd, congestion indicator, rtt)

43. L -20; 4-2-01© Srinivasan Seshan, 200143 Probing System Receiver modifications necessary Support for separate CM header Uses sequence number to detect losses Sender can request count of packets received Receiver modifications detected/negotiated via handshake Enables incremental deployment IP payload CM Header IP Header IP Payload

44. L -20; 4-2-01© Srinivasan Seshan, 200144 How will applications use CM? TCP Asynchronous API Congestion controlled UDP Buffered API Conferencing applications Synchronous API for real-time streams Combination of others for other streams

45. L -20; 4-2-01© Srinivasan Seshan, 200145 TCP/CM CM Application IP 2. cm_open 1. connect3. write 4. cm_request 6. transmit 5. cmapp_send 8. recv ACK 7. cm_notify 7. cm_request 9. cm_update 11. cm_close 10. close

46. L -20; 4-2-01© Srinivasan Seshan, 200146 CM Web Performance With CM TCP Newreno Time Sequence number CM greatly improves predictability and consistency CM greatly improves predictability and consistency

47. L -20; 4-2-01© Srinivasan Seshan, 200147 Layered Streaming Audio TimeSequence number Competing TCP TCP/CM Audio/CM Audio adapts to available bandwidth Combination of flows compete equally with normal TCP Audio adapts to available bandwidth Combination of flows compete equally with normal TCP

48. L -20; 4-2-01© Srinivasan Seshan, 200148 CM Summary Enables proper and stable congestion behavior Provides simple API that enables application to learn and adapt to network state Improves consistency and predictability of network transfers Provides benefit even when deployed at senders alone

49. L -20; 4-2-01© Srinivasan Seshan, 200149 Next Lecture: Caching & CDN’s Web caching hierarchies Content distribution networks Peer-to-peer networks Assigned reading [FCAB98] Summary Cache: A Scalable Wide- Area Cache Sharing Protocol [K+99] Web Caching with Consistent Hashing