Experimental Networking Research and Performance Evaluation

Transcription

1 Generating Realistic TCP Workloads Felix Hernandez-Campos Ph. D. Candidate Dept. of Computer Science Univ. of North Carolina at Chapel Hill Recipient of the 2001 CMG Fellowship Joint work with F. Donelson Smith and Kevin Jeffay Experimental Networking Research and Performance Evaluation Evaluating network protocols and mechanisms requires careful experimentation Network simulation (NS, Opnet, etc.) Network testbeds A critical element of these experiments is the traffic workload Are current workloads realistic? Let s s look at some measurements Sprint s s tier-1 backbone network Sprint ATL 2004 Sprint ATL TCP is the dominant transport protocol OC-48 Link in San Jose, CA February 3 rd, 2004 Internet traffic is driven by a large number of applications 3 4

2 Internet Generation Testbed example Internet Generation Testbed example Evaluate queuing mechanisms in the routers Evaluate transport protocols Evaluate intrusion/anomaly detection mechanisms Evaluate traffic monitoring techniques / / 5 6 Generation State-of-the-Art Application-Specific Modeling Model Example Open-loop Large number of sophisticated models» Packet-level modeling But TCP is a closed-loop protocol» Open-loop traffic generation breaks reliability, flow control, and congestion control Closed-loop The idea is to simulate the behavior of users/applications» Source-level modeling of specific application Time Active OFF times Inactive OFF times (user think time) sizes, File sizes Web Page s to same server 7 8

3 SURGE Model [Barford and Crovella,, 1998] Application-Specific Models Shortcomings Time Active OFF times Inactive OFF times (user think time) OFF Time Durations: Pareto(k = 10K, = 1.0) Sizes: Lognormal(µ = 7.63, = 1.001) Body Pareto(k = 10K, = 1.0) Tail Web Page No. of Objects: : Pareto(k = 2, = 1.245) sizes, File sizes Object Sizes: Lognormal(µ = 8.215, = 1.46) s to same server Creating application models is a challenging, time- consuming task mixes are driven by a large number of applications Set of dominant applications evolves quickly Applications themselves also evolve We cannot even identify a significant fraction of the traffic Modeling closed application protocols requires reverse-engineering Privacy considerations complicate data acquisition TCP header traces are ok, application data is not 9 10 Our Approach Different Views of Internet Abstract Source-level Modeling Abstract source-level modeling Application-neutral technique to describe the source-level behavior of any TCP connection Efficient analysis applicable any arbitrary trace of TCP headers (no analysis of payloads) We can also measure network-level parameters, such as round-trip times, receiver window sizes, etc. Source-level trace replay Replaying abstract source-level behavior Validation in network testbed We wrote a distributed, scalable traffic generator (tmix( tmix) Comparison of original and synthetic traces UNC from UNC Per-Flow Filtering from Internet UNC Internet from Inet 2,500 bytes 4,800 bytes 800 b 1,800 b URL HTML Source Req. Image time Aggregate Packet Arrival Level Single-Flow Packet Arrivals Abstract Source Level Application Level (e.g., web traffic) Our Approach 11 12

4 BROWSER SERVER Client-Server Applications Persistent Example Epoch b 803 b Response secs b Epoch 2 Epoch 3 25,821 b Response secs b 1,198 b Response 3 We call a pair of application data units (ADUs( ADUs) ) that carry a request/response exchange an epoch Quiet times are also part of the workload of TCP Sequential A-b-t Model Abstract source-level model for describing the workload of TCP connections Each connection is summarized using a connection vector of the form C i = (e( 1, e 2,, e n ) with n 1 epochs Each epoch has the form e j = (a( j, ta j, b j, tb j ) Connection vectors can be extracted from trace of TCP segment headers Sequence number directionality, timing analysis, write size and packet size interactions O(n n log n) + O(n*W) Client-Server Applications SMTP and Examples Beyond the Client-Server Model Icecast Internet Radio SMTP SENDER SMTP RECEIVER 93 b 220 Host Info MODE READER 13 b READER 53 b SERVER 200 News Srv 5.7b1 HELO 32 b 42 b 200 News Service 191 b 250 Domain Info MAIL 77 b GROUP GROUP unc.help unc.test 19 b 42 b 15 b unc.support status 32 b unccs.test status RCPT 75b 6b 59b 38b 50b 250 Ok 250 Ok 250 Ok XOVER 15 b 32 b 224 data [header n] ARTICLE n 5.02 secs 12 b Message 22,568 b 44b 250 Ok 1056 bytes 220 n <id1> article retrieved [article] msecs. msecs. ms. ms. msecs. ms. msecs. 392b PLAYER SERVER 217b 1253b 1686b 432b 863b 2442b 436b 1671b Audio Frames Server PUSH applications do not follow the traditional client-server model The sequential a-b-t model is still applicable Make a i and tb i zero 16

5 Beyond the Client-Server Model in Stream-Mode MODE STREAM PEER 13 b 52 b PEER 201 Server Ready 43 b 203 StreamOK CHECK CHECK <id2> <id4> CHECK CHECK <id1> 41 b 41 b <id3> 43 b 41 b 49 b 438 don t <id1> BitTorrent Unchoke Protocol Bitfield Interested 42 b 238 <id2> i PEER A 68 b 657 b 5b 5b b PEER B 68 b 657 b 5b 17b 17b BitTorrent Interested Protocol j Bitfield i j b 51 b 438 don t <id3> TAKETHIS <id2> [article] 15,678 bytes m 17b 49 b 438 don t <id4> k b 17b k 17b b m l l b Concurrent A-b-t Model Some connections are said to exhibit data exchange concurrency Two reasons: Increasing performance Enabling natural concurrency Concurrent a-b-t model describes each side of the connection separately ((a 1, ta 1 ), (a( 2, ta 2 ),,, (a( n, ta n )) ((b 1, tb 1 ), (b( 2, tb 2 ),,, (b( m, tb m )) Concurrency can be detected with high probability p.seqno > q.ackno and q.seqno > p.ackno O(n*W) Source-Level Trace Replay Generation in Lab Testbed Sample Comparison Anonymized Packet Header Trace Processing Source-level Trace: Set of Connection Vectors Workload Partitioning Source-level Performance Metrics TESTBED Synthetic Packet Header Trace 19 20

6 Conclusion New method for modeling traffic mixes Empirically-derived connection vectors Studied sequential vs. concurrent dichotomy Fully automated, efficient analysis New traffic generation approach Enables comparison of real and synthetic traffic Implemented a distributed traffic generator Techniques for scaling traffic load 21 22