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

2. L -21; 11-21-02© Srinivasan Seshan, 20022 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 -21; 11-21-02© Srinivasan Seshan, 20023 Overview HTTP Basics HTTP Fixes ALF Congestion Manager

4. L -21; 11-21-02© Srinivasan Seshan, 20024 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 Stateless Server maintains no information about past client requests

5. L -21; 11-21-02© Srinivasan Seshan, 20025 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 “escape” delimiter in content Close connection Only server can do this

6. L -21; 11-21-02© Srinivasan Seshan, 20026 HTTP Request Request line Method GET – return URI HEAD – return headers only of GET response POST – send data to the server (forms, etc.) URL (relative) E.g., /index.html HTTP version

7. L -21; 11-21-02© Srinivasan Seshan, 20027 HTTP Request (cont.) Request headers Authorization – authentication info Acceptable document types/encodings From – user email If-Modified-Since Referrer – what caused this page to be requested User-Agent – client software Blank-line Body

8. L -21; 11-21-02© Srinivasan Seshan, 20028 HTTP Request

9. L -21; 11-21-02© Srinivasan Seshan, 20029 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.intel-iris.netwww.intel-iris.net Connection: Keep-Alive

10. L -21; 11-21-02© Srinivasan Seshan, 200210 HTTP Response Status-line HTTP version 3 digit response code 1XX – informational 2XX – success 200 OK 3XX – redirection 301 Moved Permanently 303 Moved Temporarily 304 Not Modified 4XX – client error 404 Not Found 5XX – server error 505 HTTP Version Not Supported Reason phrase

11. L -21; 11-21-02© Srinivasan Seshan, 200211 HTTP Response (cont.) 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

12. L -21; 11-21-02© Srinivasan Seshan, 200212 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 …..

13. L -21; 11-21-02© Srinivasan Seshan, 200213 Cookies: Keeping “state” Many major Web sites use cookies Four components: 1) Cookie header line in the HTTP response message 2) Cookie header line in HTTP request message 3) Cookie file kept on user’s host and managed by user’s browser 4) Back-end database at Web site Example: Susan access Internet always from same PC She visits a specific e- commerce site for first time When initial HTTP requests arrives at site, site creates a unique ID and creates an entry in backend database for ID

14. L -21; 11-21-02© Srinivasan Seshan, 200214 Cookies: Keeping “State” (Cont.) client Amazon server usual http request msg usual http response + Set-cookie: 1678 usual http request msg cookie: 1678 usual http response msg usual http request msg cookie: 1678 usual http response msg cookie- specific action cookie- specific action server creates ID 1678 for user entry in backend database access Cookie file amazon: 1678 ebay: 8734 Cookie file ebay: 8734 Cookie file amazon: 1678 ebay: 8734 one week later:

15. L -21; 11-21-02© Srinivasan Seshan, 200215 Typical Workload (Web Pages) Multiple (typically small) objects per page File sizes Why different than request sizes? Also heavy-tailed Pareto distribution for tail Lognormal for body of distribution Embedded references Number of embedded objects = pareto – p(x) = ak a x -(a+1)

16. L -21; 11-21-02© Srinivasan Seshan, 200216 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 -21; 11-21-02© Srinivasan Seshan, 200217 Single Transfer Example Client Server 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 -21; 11-21-02© Srinivasan Seshan, 200218 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 -21; 11-21-02© Srinivasan Seshan, 200219 Overview HTTP Basics HTTP Fixes ALF Congestion Manager

20. L -21; 11-21-02© Srinivasan Seshan, 200220 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 -21; 11-21-02© Srinivasan Seshan, 200221 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 -21; 11-21-02© Srinivasan Seshan, 200222 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 -21; 11-21-02© Srinivasan Seshan, 200223 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 -21; 11-21-02© Srinivasan Seshan, 200224 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 -21; 11-21-02© Srinivasan Seshan, 200225 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 -21; 11-21-02© Srinivasan Seshan, 200226 Overview HTTP Basics HTTP Fixes ALF Congestion Manager

27. L -21; 11-21-02© Srinivasan Seshan, 200227 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 Data manipulation more expensive than control Presentation overhead/application-specific processing >> other data manipulation processing Target for ILP optimization

28. L -21; 11-21-02© Srinivasan Seshan, 200228 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 Lower protocol layers should maintain framing

29. L -21; 11-21-02© Srinivasan Seshan, 200229 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 ADU becomes unit of loss recovery What if size is very large?

30. L -21; 11-21-02© Srinivasan Seshan, 200230 Overview HTTP Basics HTTP Fixes ALF Congestion Manager

31. L -21; 11-21-02© Srinivasan Seshan, 200231 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 -21; 11-21-02© Srinivasan Seshan, 200232 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

33. L -21; 11-21-02© Srinivasan Seshan, 200233 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

34. L -21; 11-21-02© Srinivasan Seshan, 200234 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

35. L -21; 11-21-02© Srinivasan Seshan, 200235 The CM Architecture Transmitting Application (TCP, conferencing app, etc) Prober Congestion Controller Scheduler Responder Congestion Detector SenderReceiver CM Protocol API Receiving Application Protocol

36. L -21; 11-21-02© Srinivasan Seshan, 200236 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

37. L -21; 11-21-02© Srinivasan Seshan, 200237 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

38. L -21; 11-21-02© Srinivasan Seshan, 200238 Transmission API Buffered send cm_send(data, length) Request/callback-based send cm_request( ) cmapp_send( ) App CM IP send( ) cm_notify(nsent)

39. L -21; 11-21-02© Srinivasan Seshan, 200239 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

40. L -21; 11-21-02© Srinivasan Seshan, 200240 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)

41. L -21; 11-21-02© Srinivasan Seshan, 200241 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

42. L -21; 11-21-02© Srinivasan Seshan, 200242 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

43. L -21; 11-21-02© Srinivasan Seshan, 200243 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

44. L -21; 11-21-02© Srinivasan Seshan, 200244 CM Web Performance With CM TCP Newreno Time Sequence number CM greatly improves predictability and consistency CM greatly improves predictability and consistency

45. L -21; 11-21-02© Srinivasan Seshan, 200245 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

46. L -21; 11-21-02© Srinivasan Seshan, 200246 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

47. L -21; 11-21-02© Srinivasan Seshan, 200247 Next Lecture: Caching & CDN’s Web caching hierarchies Content distribution networks Assigned reading [FCAB98] Summary Cache: A Scalable Wide- Area Cache Sharing Protocol [K+99] Web Caching with Consistent Hashing