iplab Benchmarking Methodology for IPv6 Transition Technologies draft-ietf-bmwg-ipv6-tran-tech-benchmarking-01 Marius Georgescu Nara Institute of Science and Technology Internet Engineering Laboratory 7 Apr. 2016
D RAFT M OTIVATION D RAFT OVERVIEW D RAFT U PDATE N EXT STEPS D RAFT M OTIVATION : IP V 6 TRANSITION ◮ IPv6 is not backwards compatible ◮ The Internet will undergo a period through which both protocols will coexist ◮ Currently only 5% of worldwide Internet users have IPv6 connectivity 1 2 1 APNIC. IPv6 measurements for The World . Asia-Pacific Network Information Centre, Apr. 2016. URL : http://labs.apnic.net/ipv6-measurement/Regions/ . 2 Original drawing by Andrew Bell @ www.creaturesinmyhead.com . Marius Georgescu (NAIST) IETF95 Buenos Aires 07.04.2016 2 / 13
D RAFT M OTIVATION D RAFT OVERVIEW D RAFT U PDATE N EXT STEPS IP V 6 TRANSITION TECHNOLOGIES EVOLUTION ◮ What benchmarks to use? ◮ For Dual Stack RFC2544 or RFC5180 are enough ◮ How about translation/encapsulation technologies? 2000 2005 2010 2015 IVI dIVI dIVI-pd MAP-T NAT64 464XLAT 4over6 NAT-PT NAT464 DS-Lite Leightweight 4over6 Stateless DS-Lite MAP-E SAM 4rd 4rd- U 6to4 6rd Configured Tunnel 6over4 ISATAP RFC 2893 Tunnel Teredo Broker 3 3 inspired by the APNIC35 presentation ”The evolution of IPv6 transition technologies” by Jouni Korhonen . Marius Georgescu (NAIST) IETF95 Buenos Aires 07.04.2016 3 / 13
D RAFT M OTIVATION D RAFT OVERVIEW D RAFT U PDATE N EXT STEPS D RAFT OVERVIEW ◮ This draft provides complementary guidelines to RFC2544 4 and RFC5180 5 for evaluating the performance of IPv6 transition technologies ◮ generic classification on IPv6 transition technologies → associated test setups ◮ calculation formula for the maximum frame rate according to the frame size overhead ◮ Includes a tentative metric for benchmarking scalability ◮ scalability as performance degradation under the stress of multiple network flows ◮ Proposes supplementary benchmarking tests for stateful IPv6 transition technologies in accordance with RFC3511 6 ◮ Proposes supplementary benchmarking tests for DNS resolution performance ◮ contributed by Prof. G´ abor Lencse [RG profile link] 4 S. Bradner and J. McQuaid. Benchmarking Methodology for Network Interconnect Devices . United States, 1999. 5 A. Hamza C. Popoviciu, G. Van de Velde, and D. Dugatkin. IPv6 Benchmarking Methodology for Network Interconnect Devices . RFC 5180. Internet Engineering Task Force, 2008. 6 B. Hickman et al. Benchmarking Methodology for Firewall Performance . RFC 3511 (Informational). Internet Engineering Task Force, Apr. 2003. URL : http://www.ietf.org/rfc/rfc3511.txt . Marius Georgescu (NAIST) IETF95 Buenos Aires 07.04.2016 4 / 13
D RAFT M OTIVATION D RAFT OVERVIEW D RAFT U PDATE N EXT STEPS U PDATE OVERVIEW ◮ New procedure for latency to report Typical Latency and Worst Latency ◮ Summarizing and variation functions ◮ Mean + MoE → Median + 1st-99th Percentiles ◮ Simultaneous and Incremental benchmarks for network performance degradation ◮ Generic transition technologies association table ◮ DNS Resolution Performance ◮ Tester configuration ◮ Test duration ◮ Requirements for the Tester and dns64perf++ [link] 7 ◮ Various smaller editorial changes (detailed changelog [link]) 7 D. Bakai. A C++11 DNS64 performance tester . 2016. URL : https://github.com/bakaid/dns64perfpp . Marius Georgescu (NAIST) IETF95 Buenos Aires 07.04.2016 5 / 13
D RAFT M OTIVATION D RAFT OVERVIEW D RAFT U PDATE N EXT STEPS U PDATE : T YPICAL & W ORST C ASE L ATENCY Text added to Section 7.2: Identifying tags SHOULD be included in at least 500 frames after 60 seconds. Typical Latency (TL) calculation formula: TL = Median ( L i ) (1) where L i - the latency of frame i Worst Case Latency (WCS) calculation formula: WCS = 99 . 9 thPercentile ( L i ) (2) 7 following the ML discussion: http://www.ietf.org/mail-archive/web/bmwg/current/msg03371.html . Marius Georgescu (NAIST) IETF95 Buenos Aires 07.04.2016 6 / 13
D RAFT M OTIVATION D RAFT OVERVIEW D RAFT U PDATE N EXT STEPS U PDATE : S UMMARIZING & V ARIATION Latency amapt − 1024 6 median mean MoE 1st − 3rd Quartiles Median Abs Dev 5 1st − 99th Percentile 4 Density 3 2 1 0 0.4 0.6 0.8 1.0 1.2 N = 600 Bandwidth = 0.01682 Marius Georgescu (NAIST) IETF95 Buenos Aires 07.04.2016 7 / 13
D RAFT M OTIVATION D RAFT OVERVIEW D RAFT U PDATE N EXT STEPS U PDATE : S UMMARIZING & V ARIATION CONT ’ D Rate totd − dns64 − 30 − halfsec 0.010 median mean MoE Median Absolute Deviation 1st-99th Percentiles 0.008 0.006 Density 0.004 0.002 0.000 2300 2350 2400 2450 2500 2550 N = 20 Bandwidth = 17.8 Marius Georgescu (NAIST) IETF95 Buenos Aires 07.04.2016 8 / 13
D RAFT M OTIVATION D RAFT OVERVIEW D RAFT U PDATE N EXT STEPS N ETWORK PERFORMANCE DEGRADATION WITH INCREMENTAL LOAD Text added to Section 10.2.2: The same tests have to be repeated for n network flows, where the network flows are started incrementally in succession, each after time T. In other words, if flow I is started at time x, flow i+1 will be started at time x+T. Considering the time T, the time duration of each iteration must be extended with the time necessary to start all the flows, namely (n-1)xT. 7 following the suggestion from Fred Baker . Marius Georgescu (NAIST) IETF95 Buenos Aires 07.04.2016 9 / 13
D RAFT M OTIVATION D RAFT OVERVIEW D RAFT U PDATE N EXT STEPS G ENERIC TRANSITION TECHNOLOGIES ASSOCIATION TABLE Generic Category IPv6Transition Technology 1 Dual-stack Dual IP Layer Operations [RFC4213] 2 Single translation NAT64 [RFC6146], IVI [RFC6219] 3 Double translation 464XLAT [RFC6877], MAP-T [RFC7599] DSLite[RFC6333], MAP-E [RFC7597] 4 Encapsulation Lightweight 4over6 [RFC7596] 6RD [RFC 5569] Marius Georgescu (NAIST) IETF95 Buenos Aires 07.04.2016 10 / 13
D RAFT M OTIVATION D RAFT OVERVIEW D RAFT U PDATE N EXT STEPS U PDATE : DNS R ESOLUTION P ERFORMANCE ◮ Tester configuration ◮ Tester may be a single device or two physical devices ◮ Test duration ◮ The duration should be at least 60 seconds and timeout should be no more than 1 second, otherwise ”gaming” is possible ◮ Requirements for the Tester ◮ For passing the self-test, the Tester SHOULD be able to answer AAAA record queries at 2 ∗ ( r + delta ) rate within 0 . 25 ∗ t timeout, where the value of delta is at least 0.1. ◮ dns64perf++ [link] ◮ Developed by D´ aniel Bakai in compliance with the specifications of this draft Marius Georgescu (NAIST) IETF95 Buenos Aires 07.04.2016 11 / 13
D RAFT M OTIVATION D RAFT OVERVIEW D RAFT U PDATE N EXT STEPS N EXT STEPS ◮ Comments not covered yet ◮ Fred Baker’s suggestion to use this methodology to benchmark NAT XX as well ◮ DNS Resolution Performance for DNS46 ? ⋆ Questions for BMWG: ◮ Were the comments covered well enough? ◮ Is the 1st WGLC in IETF96 a realistic milestone? Marius Georgescu (NAIST) IETF95 Buenos Aires 07.04.2016 12 / 13
D RAFT M OTIVATION D RAFT OVERVIEW D RAFT U PDATE N EXT STEPS C ONTACT Marius Georgescu liviumarius-g@is.naist.jp www.ipv6net.ro Marius Georgescu (NAIST) IETF95 Buenos Aires 07.04.2016 13 / 13
Recommend
More recommend
