1 / 20

Performance Interactions Between P-HTTP and TCP Implementations

Performance Interactions Between P-HTTP and TCP Implementations. J. Heidemann ACM Computer Communication Review April 1997 김호중 CA Lab., KAIST. Contents. Introduction Initial experiment The performance problems Related works Conclusion Critique. Introduction (1/2). HTTP 1.0

taniel
Download Presentation

Performance Interactions Between P-HTTP and TCP Implementations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Performance Interactions Between P-HTTP and TCP Implementations J. Heidemann ACM Computer Communication Review April 1997 김호중 CA Lab., KAIST

  2. Contents • Introduction • Initial experiment • The performance problems • Related works • Conclusion • Critique

  3. Introduction (1/2) • HTTP 1.0 • 1 HTTP request per each TCP connection • Several connections per a page • P-HTTP (Persistent-HTTP) • Multiple HTTP requests over a TCP connection • Advantages of HTTP 1.1 (RFC2068) • Saving CPU time, memory • Pipelining request without waiting each response • Reducing network congestion • Evolving HTTP

  4. Introduction (2/2) • Problem : P-HTTP is not HTTP • HTTP : similar to FTP • P-HTTP : similar to SMTP or NNTP • SMTP : batch protocol • NNTP : interactive uses are usually in LAN

  5. Initial Experiment (1/2) • Experimental framework • 10Mb/s Ethernet • Sun SPARC 20/71 • SunOS 4.1.3 with some TCP modification • 16KB default TCP window size • Slow-start enabled • Apache 1.1b4 • HTTP 1.0 with “Keep-Alive” on • No pipelining • 3 types of workload • 6651, 3883, 1866 bytes : yahoo’s title page (May 1996)

  6. Initial Experiment (2/2) • Initial performance Protocol Server Retrieval time Std. variation HTTP 1.1b4 43 ms 4.0 ms P-HTTP 1.1b4 605 ms 10 ms P-HTTP 1.1b4 (1st fix) 195 ms 1.9 ms P-HTTP 1.1b4 (both fixes) 26 ms 8.8 ms

  7. Short-Initial-Segment Problem (1/4) • Conflict between TCP’s slow-start algorithm and piggybacking • Slow-start algorithm • The connection opens its congestion window exponentially • Initial window size = 2 segments • Piggybacking • ACK on return traffic • RFC1122 : must ACK at >2 segments

  8. Short-Initial-Segment Problem (2/4) Connection setup request ACK ACK HTTP header & 1st data segment Waiting … ACK timer expired ACK SERVER CLIENT TCP MSS(max. segment size) : 1460bytes for Ethernet 512 or 536bytes for wide area TCP connection HTTP header : 200~300bytes

  9. Short-Initial-Segment Problem (3/4)

  10. Short-Initial-Segment Problem (4/4) • Solution • Send HTTP header with initial data • Problem of piggybacking • Unidirectional data traffic dominates Protocol Server Retrieval time Std. variation HTTP 1.1b4 43 ms 4.0 ms P-HTTP 1.1b4 605 ms 10 ms P-HTTP 1.1b4 (1st fix) 195 ms 1.9 ms P-HTTP 1.1b4 (both fixes) 26 ms 8.8 ms

  11. Odd/Short-Final-Segment Problem (1/4) • Conflict between SWS avoidance algorithm and BSD TCP small message transfer • BSD TCP prevent sending until … • A full-size segment can be sent • We can send half of the client’s advertised window • We can send everything and… • Not expecting ACK • Nagle algorithm is disabled

  12. Odd/Short-Final-Segment Problem (2/4) • Silly Window Syndrome (SWS) • Example • MSS : 200bytes, initial window : 1000bytes • Send 200bytes * 5 segments • Receive 1 segment and ACK • 800bytes pending, 200bytes available • Send 200bytes * 1 segment, … • Send 50bytes segment, followed by 150bytes segment • Receive 50bytes segment and ACK • 950byes pending, 50bytes available • Send 50bytes again? • Nagle’s algorithm

  13. Odd/Short-Final-Segment Problem (3/4)

  14. Odd/Short-Final-Segment Problem (4/4) • Solution • Disable Nagle’s algorithm • Nagle’s algorithm is for small, interactive packet Protocol Server Retrieval time Std. variation HTTP 1.1b4 43 ms 4.0 ms P-HTTP 1.1b4 605 ms 10 ms P-HTTP 1.1b4 (1st fix) 195 ms 1.9 ms P-HTTP 1.1b4 (both fixes) 26 ms 8.8 ms

  15. Slow-Start Re-Start Problem (1/2) • Conservative congestion control • All data sent has been acknowledged + Nothing has been sent for a retransmission time-out period Reinitialize congestion window to 1 Slow-start again • time for browsing a page > time-out period

  16. Slow-Start Re-Start Problem (2/2) • Solutions • Omitting to reset the congestion window • SunOS 4.1.3 • Bursty traffic can cause packet loss • Reinitiate the window after an idle period • Decay the window size over time • Still bursty traffic • Rate-based flow control • Hard to use for new connection : unknown network status

  17. Other Problems • Inefficient I/O package • Disk  file system cache  (input stream buffer  user buffer  output buffer)  network buffer  network device • Memory-mapping the input file • Too small socket buffer • 2~16Kbytes • Can’t utilize the high-speed network

  18. Related Works • Moldeklev and Gunningberg • Effect of MTU size to TCP transfer efficiency • Large-MTU network (ATM) • Crowcroft, Wakerman, Wang and Strovica • Relation of user- and TCP-level buffering • SunRPC traffic over TCP • Similar to HTTP request / P-HTTP response

  19. Conclusion • P-HTTP over TCP • Short-initial-segment problem • Send HTTP header with initial data • Odd/short-final-segment problem • Disable SWS-avoidance algorithm • Slow-start re-start problem • Rate-based flow control

  20. Critique • Good analysis • Evaluation • Is it realistic P-HTTP traffic? • Large images, many objects, … • Approaches • HTTP header with initial data • browser support needed • SWS-avoidance Disabled • No problem in real environments?

More Related