' $ Prelimina ry Empirical Study of BTC T o ols Ma rk Allman, NASA GRC/BBN IPPM W G Meeting August 2000 & % 1
' $ Background Background W e have a draft BTC framew o rk a round which di�erent � BTC metho dologies can b e built: - TReno draft (Mathis) - { no draft y et cap The basic idea of a BTC to ol is to measure the throughput � a �o w utilizing standa rd congestion control could obtain if �o wing over the given net w o rk path. - A to ol that do es not rely on the underlying TCP is very attractive b ecause quirks in TCP stacks do not impact the results. August 2000 IPPM & % 2
' $ But, A Question... But, A Question... A question remains as to whether o r not a to ol p ro ducing � pack ets acco rding to TCP's congestion control algo rithms can p redict TCP p erfo rmance. - Intuitively { y es! - Empirically { not sure y et August 2000 IPPM & % 3
' $ cap Overview cap Overview Consists of sender ( cap ) and receiver ( cap ) p ro cesses. d � Use UDP fo r b oth \data" and \A CK" pack ets � Advantages: � - Allo ws go o d control over all b ehavio r (sender loss recovery strategy , dela y ed A CK b ehavio r, etc.) - The \A CKs" a re cumulative, just as in TCP Data loss/reo rdering can b e disambiguated from A CK � loss Disadvantages: � - Must have access to the receiver to run cap d August 2000 IPPM & % 4
' $ TReno Overview TReno Overview Consists of only a sending p ro cess � Can use UDP o r ICMP pack ets to induce the receiver into � \A CKing" (ala ping o r traceroute) Advantages: � - Do es not require access to the receiver host Disadvantages: � - A CK loss is the same as data loss since only sp eci�c data segments a re A CKed (i.e., no cumulative A CK) - No control over the receiver's b ehavio r W e can emulate things lik e dela y ed A CKs, SA CKs, etc. � The receiver cannot do things lik e tak e bandwidth � estimates (although this is not currently a p roblem) August 2000 IPPM & % 5
' $ Metho dology Metho dology Used a subset of the NIMI sites � - Used 31 sites (mostly F reeBSD, a couple NetBSD) - Hosts excluded due to con�guration issues, not net w o rk issues. One measurement consists of t w o back-to-back transfers � - Each transfer is 30 seconds - W e randomly pick TCP , o r TReno fo r each transfer cap W e have XXX measurements over the course of roughly � 3 da ys August 2000 IPPM & % 6
' $ Metho dology (cont.) Metho dology (cont.) The TCP used w as the sto ck version used b y the pa rticula r � op erating system - W e increased the so ck et bu�er sizes to roughly 200 KB I.e., w e used windo w scaling and timestamps (also � used in and TReno) cap - W e disrega rded measurements made with smaller so ck et bu�er sizes. August 2000 IPPM & % 7
' $ Results Results Throughput distribution of TCP transfers: � 1 0.9 0.8 0.7 0.6 CDF 0.5 0.4 0.3 0.2 0.1 0 0 500000 1e+06 1.5e+06 2e+06 2.5e+06 3e+06 Throughput (bytes/sec) August 2000 IPPM & % 8
' $ Results (cont.) Results (cont.) Di�erence in throughput, tak e 1: � 1 0.9 0.8 0.7 0.6 CDF 0.5 0.4 0.3 0.2 TCP vs. TCP TCP vs. cap 0.1 TCP vs. TReno 0 0 0.2 0.4 0.6 0.8 1 Percentage Difference in Throughput August 2000 IPPM & % 9
' $ Results (cont.) Results (cont.) Di�erence in throughput, tak e 2: � 1 0.9 0.8 0.7 0.6 CDF 0.5 0.4 0.3 0.2 TCP vs. TCP TCP vs. cap 0.1 TCP vs. TReno 0 -1 -0.5 0 0.5 1 Percentage Difference in Throughput August 2000 IPPM & % 10
' $ Results (cont.) Results (cont.) Why the di�erence? � - 's initial RTO is di�erent from TCP's (3 secs as cap opp osed to 6 secs) - 's RTO ends up b eing a bit longer than TCP's in cap some cases Lik ely indicating a bug in 's hea rtb eat timer cap � emulation co de - BSD TCP bugs August 2000 IPPM & % 11
' $ Results (cont.) Results (cont.) BSD TCP bug: � sequence offset 133.138.1.148:3226_==>_204.42.254.25:4753 (time sequence graph) 800000 750000 . . . . . . . . . R 700000 . . . . . . . . . . 650000 600000 . R R R R R R R R R 550000 5.000 s 10.000 s 15.000 s 20.000 s relative time August 2000 IPPM & % 12
' $ Conclusions Conclusions Not de�nite conclusions... just leanings... � - BTC is lik ely p ossible with a sender/receiver measurement metho dology . - Whether o r not w e can mak e a sender-only metho dology w o rk is an op en question. August 2000 IPPM & % 13
' $ F uture W o rk F uture W o rk Continue to crunch the data to determine to what degree � and/o r TReno need to b e �xed to b etter emulate TCP cap b ehavio r - Keeping in mind that some of the di�erences might not b e bugs, but rather legal diversit y , as allo w ed b y RF C 2581. Run some measurements using di�erent TCP stacks to � �gure out what so rt of va riation exists b et w een currently existing implementations. - I.e., and/o r TReno might b e di�erent from BSD cap TCP , but no mo re so than another implementation of TCP . August 2000 IPPM & % 14
' $ F uture W o rk (cont.) F uture W o rk (cont.) Give the abilit y to w o rk as a sender-side only to ol. cap � - Allo w a mo re direct compa rison b et w een the sender-only app roach and the sender/receiver app roach currently emplo y ed. August 2000 IPPM & % 15
' $ IPPM Implications IPPM Implications What do w e do with BTC in IPPM? � - b elieve the framew o rk is essentially sound at this p oint I and should b e fo rw a rded to the IESG after a light editing pass. - I think a do cument based a round the BTC framew o rk and the current to ol is app rop riate in the nea r-term. cap August 2000 IPPM & % 16
Recommend
More recommend
