290 likes | 502 Views
Critical Path Analysis of TCP Transactions. Authors:Paul Barford (University of Wisconsin-Madison) Mark Crovella (University of Boston) Member, IEEE Source:IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 9,NO. 3, JUNE 2001 Presented by Chin-Yi Tsai. Outline. Introduction
E N D
Critical Path Analysis of TCP Transactions Authors:Paul Barford (University of Wisconsin-Madison) Mark Crovella (University of Boston) Member, IEEE Source:IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 9,NO. 3, JUNE 2001 Presented by Chin-Yi Tsai
Outline • Introduction • Mechanics of Critical Path Analysis • Experiment • Conclusions and Future Work
Introduction • Motivation • Identifying root causes of response time • Critical Path Definition
Introduction(cont.) • Motivation • What are the root causes of delay in TCP transactions? • Server • Network • Server/Network interaction
Introduction(cont.) • Identify root causes of response time • Delays can occur in many points along end-to-end path simultaneously • Pinpointing where delays occur and whichdelays matter is difficult • Identify precisely the determiners of response time in TCP transaction router1 Client Server router2 router3
Introduction(cont.) • Critical Path Definition • The longest path in the tree starting from the root • A weighted chain of dependence relations running from the connection’s first data packet to its last data packet sent • reducing the execution times of activities on the critical path will certainly reduce overall response time, while this is not necessarily true for activities off the critical path • Events on the critical path are the “right” ones for examining the sources of delay (rather than all events during the entire transfer)
Mechanics of Critical Path Analysis • Critical Path for a Unidirectional TCP Flow • Discovering the Critical Path for an HTTP Transaction • Critical Path Discovery and profile Algorithm • Limitations
Critical Path for Unidirectional TCP Flow • Packet Dependence Graph (PDG) • Possible Nodes • Possible Arcs
Packet Dependence Graph (PDG) System Time line Graph Client Server D D 1 or more data packets A A D Client D D Server D A A A A ACK packet D D D D D D D D D A A A A D D D D D D D D D D D D D D D
Possible Nodes a • Server side • a. arrival of an ACK packet • b. departure of a data packet • Client side • c. arrival of an data packet • d. departure of an ACK packet Client Server c D A D d D b A A D D D D D D D D D D D D
Possible Node(cont.) a Client Server D c D A A D D D d D b A A A A D D D D D D D D A A A A D D D D D D D D D D D D D D D D PDG Time line
Possible Arcs • Type1 • from the arrival of that data packet to the departure of that ACK packet (at client side) • Type2 • its departure at one endpoint to its arrival at the other endpoint (server-to-client, client-to-server) • Type3 • from the arrival of the ACK to the departure of each liberated data packets (at server side) • Type4 • from the departure of the dropped packet to the departure of the earliest subsequent retransmission (at server side)
Possible Arcs (cont.) Network delay Server Client D Server delay type2 type1 A D A Client delay type3 drop D A type4 Packet loss delay D
Discovering the Critical Path for an HTTP Transaction • Four stages for HTTP/1.0 • connection establishments (SYN, SYN-ACK, ACK) • packets sequence delivering HTTP GET • data transfer in response to GET (file size dependent) • connection tear-down (FIN, ACK, FIN, ACK)
Discovering the Critical Path for an HTTP Transaction Client Server Profile SYN j Network delay Connection Establishment Server delay SYN k,Ack j+1 Network delay Ack k+1 Client delay Application Protocol Network delay HTTP GET Bulk Transfer FIN x Network delay Connection Tear Down Ack x+1 Client delay FIN y Network delay Server delay Network delay Ack y+1
Critical Path Discovery and profile Algorithm • Capture of packet traces • Analysis of rounds • Construction of critical path • Profiling of the critical path
Original Data Flow Rounds Critical Path Profile Client Server Number Bytes Liberated Client Server 1 1:2920 Network Delay 1461:2921 1461:2921 2 2921:7300 Network Delay ack 2921 ack 2921 Server Delay Network Delay 5841:7301 5841:7301 3 7301:13140 Client Delay ack 7301 Network Delay ack 7301 Server Delay Network Delay 13141:17520 11681:13141 4 11681:13141 ack 10221 Network Delay ack 10221 Server Delay drop 17521 drop 17521 5 17520:24820 ack 16061 17521:20441 Drop Delay ack 16061 20441:24821 ack 16061 Network Delay 16061:17521 16061:17521 6 24821:27740 Client Delay ack 24821 Network Delay ack 24821 Network Delay 24821:27741 24821:27741 7 27741:30660 ack 27741 Network Delay ack 27741 27741:29201 Network Delay 27741:29201
Limitations • Details of the web transactions • Example: DNS • Delay in the browser • Browser parse time
Experiment • Experimental Setup • Experimental Results
Experimental Setup • Apache server on Linux or FreeBSD • Server load controlled by SURGE Web load generator: high or low load • One PC collect TCP packet traces • One PC measures network conditions (Server) Boston University (client1) (client2) Harvard University Denver University
Experimental Results • Effect of File Size • Effect of Network Load
CPA results for 1KB(small) file 1 0.8 Net Variance Propagation 0.6 Seconds Server 0.4 Time Out Client 0.2 Fast Retrans 0 LN, LS LN, HS HN, LS HN, HS Latency is dominated by server load
CP time line diagrams for 1KB file Server delay High Server Load Low Server Load
CPA results for 20KB(medium) file 0.9 0.8 0.7 Net Variance 0.6 Propagation 0.5 Seconds Server 0.4 Time Out 0.3 Client 0.2 Fast Retrans 0.1 0 LN, LS LN, HS HN, LS HN, HS Both server load and network effects are significant
CPA results for 500KB(large) file 4.5 4.5 4 4 3.5 3.5 Net Variance Net Variance 3 3 Propagation Propagation 2.5 2.5 Server Server Seconds Seconds 2 2 Time Out Time Out 1.5 1.5 Client Client 1 1 Fast Retrans Fast Retrans 0.5 0.5 0 0 LN, LS LN, HS HN, LS HN, HS LN, LS LN, HS HN, LS HN, HS Latency is dominated by network effects
Effect of File Size • Small files: • high server load: server delays can dominate • low server load: network delay can dominate • Medium files: • high server load: propagation delay and server delay are comparable • low server load: network delay can dominate • Large files: • network delay dominates overall transaction delay regardless of server load
Effect of Network • For small and medium files, propagation delay is independent of network load or server load • For large files, propagation delay are higher under high network load. There are more round-trips in the critical path due to more coarse-grained timeouts. • Network queueing delay is less important than propagation delay.
Conclusions and Future Work • Complex interactions between clients, the network and servers • Complex packet transactions can be effectively understood using CPA • CP profiling allowed precise assignment of delays • Latency for small files is dominated by server load • Latency for large files is dominated by network effects
Conclusions and Future Work(cont.) • Future work • Collect and analyze data from more client systems • To consider the delay due to DNS • Server/network integrated effects