draft-georgescu-bmwg-ipv6-tran-tech-benchmarking-00

iplab

Benchmarking Methodology for IPv6 TransitionTechnologies

draft-georgescu-bmwg-ipv6-tran-tech-benchmarking-00

Marius Georgescu

Nara Institute of Science and TechnologyInternet Engineering Laboratory

24 Mar. 2015

http://tools.ietf.org/html/draft-georgescu-bmwg-ipv6-tran-tech-benchmarking-00

IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS

IPV6 TRANSITION

I IPv6 is not backwardscompatible

I The Internet will undergoa period through whichboth protocols will coexist

I Currently only 2 % ofworldwide Internet usershave IPv6 connectivity 1

2

1APNIC. IPv6 measurements for The World. Asia-Pacific Network Information Centre, Oct. 2014. URL:http://labs.apnic.net/ipv6-measurement/Regions/.

2Original drawing by Andrew Bell @ www.creaturesinmyhead.com .

Marius Georgescu (NAIST) IETF92 24.03.2015 2 / 25

http://labs.apnic.net/ipv6-measurement/Regions/


IPV6 TRANSITION TECHNOLOGIES EVOLUTION

SAM 4rdMAP- E

4rd- (H,U)

IVI dIVI dIVI- pd MAP- T

DS- lite

Publicg4over6

Lightweightg4over6

StatelessgDS- lite

A+ P

6to4 6rdg

6over4 ISATAP

Teredo

Configured5Tunnel

Tunnel5BrokerRFC52893

NAT6455

NAT-PT55

NAT4645

5

464XLAT55

20102000 2015

Automatic5

tunnels

3

3inspired by the APNIC35 presentation ”The evolution of IPv6 transition technologies” by Jouni Korhonen.



DRAFT OVERVIEW

I RFC25444and RFC51805address both IPv4 and IPv6 performancebenchmarking, but IPv6 transition technologies are outside their scope

I This draft provides complementary guidelines for evaluating theperformance of IPv6 transition technologies

I generic classification on IPv6 transition technologies→ associated test setupsI calculation formula for the maximum frame rate according to the frame size overhead

I Includes a tentative metric for benchmarking scalabilityI scalability as performance degradation under the stress of multiple network flows

I Proposes supplementary benchmarking tests for stateful IPv6 transitiontechnologies in accordance with RFC35116

1S. Bradner and J. McQuaid. Benchmarking Methodology for Network Interconnect Devices. United States, 1999.2A. Hamza C. Popoviciu, G. Van de Velde, and D. Dugatkin. IPv6 Benchmarking Methodology for Network Interconnect

Devices. RFC 5180. Internet Engineering Task Force, 2008.3B. 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.


http://www.ietf.org/rfc/rfc3511.txt


BASIC TRANSITION TECHNOLOGIES

I Dual Stack 4

I Host side and edge nodesI A base for other transition

technologiesI Translation

I Achieves directcommunication

I Breaks the end-to-end modelI Tunneling

I heterogeneousenvironments traversal

IPv4 Header Payload

Payload

Dual stack

IPv6 Header Payload

IPv4 Header Payload

IPv6 Translated

Header Payload

Translation

IPv4 Header Payload

IPv4 Header Payload IPv6 Header

Encapsulation

4E. Nordmark and R. Gilligan. Basic Transition Mechanisms for IPv6 Hosts and Routers. RFC 4213 (Proposed Standard).Internet Engineering Task Force, Oct. 2005. URL: http://www.ietf.org/rfc/rfc4213.txt.


http://www.ietf.org/rfc/rfc4213.txt


MAP

Mapping of Address and Port withEncapsulation 5building blocks:I MAP domainI Customer Edge (CE) routerI Boarder Relay (BR) routerI MAP rule

I IPv4 prefixI IPv6 prefixI Embedded Address (EA)

bits

IPv4 Header Payload

Payload

Dual stack

IPv6 Header Payload

Payload

Stateful

Translation

IPv4 Translated

Header

Customer

Edge

Payload IPv4 Translated

Header

Stateful

Translation

IPv4 Header Payload

Provider

Edge

Payload IPv6 Header

Encapsulation

IPv4 Translated

Header

Payload IPv6 Header

Decapsulation

IPv4 Translated

Header

5O. Troan et al. Mapping of Address and Port with Encapsulation (MAP). . draft-ietf-softwire-map-10. Internet EngineeringTask Force, Jan. 2014. URL: http://tools.ietf.org/html/draft-ietf-softwire-map-10.


http://tools.ietf.org/html/draft-ietf-softwire-map-10


PRODUCTION NETWORKS GENERIC DESIGN

I Customer Edge (CE)segment

I Core network segmentI Provider Edge (PE)

segment

Services

over IP

Customer Edge

Segment

CE

router

PE

router

Core network

Segment

Provider edge

Segment



IPV6 TRANSITION TECHNOLOGIES GENERIC

CATEGORIES

1. Single-stack: either IPv4 or IPv6 is used to traverse the corenetwork and translation is used at one of the edges

2. Dual-stack: the core network devices implement both IP protocols3. Encapsulation-based: an encapsulation mechanism is used to

traverse the core network; CE nodes encapsulate the IPvX packetsin IPvY packets, while PE nodes are responsible for thedecapsulation process.

4. Translation-based: a translation mechanism is employed for thetraversal of the network core; CE nodes translate IPvX packets toIPvY packets and PE nodes translate the packets back to IPvX.



TEST ENVIRONMENT SETUP

Single-stack transition technologies

+--------------------+| |

+------------|IPvX tester IPvY|<-------------+| | | || +--------------------+ || || +--------------------+ || | | |+----------->|IPvX DUT IPvY|--------------+

| (translator) |+--------------------+



TEST ENVIRONMENT SETUP (CONTD.)

Encapsulation/Translation-based transition technologies

+--------------------+| |

+---------------------|IPvX tester IPvX|<------------------+| | | || +--------------------+ || || +--------------------+ +--------------------+ || | | | | |+----->|IPvX DUT CE IPvY|----->|IPvY DUT PE IPvX|------+

| trans/encaps | | trans/decaps |+--------------------+ +--------------------+



EMPIRICAL RESULTS

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

64 128 256 512 1024 1280 1518 1522 2048 4096 8192 9216Thro

ughputz

TC

PzX

kbpsL

FramezsizezXbytesL

DCzIPv4

DCzIPv6

ASAMAPzIPv6

MAPtzIPv4

464XLATzIPv4

MAPezIPv4

DSLitezIPv4

6

6M. Georgescu et al. “Empirical analysis of IPv6 transition technologies using the IPv6 Network Evaluation Testbed”.In: 9th International Conference on Testbeds and Research Infrastructures for the Development of Networks & Communities.Guangzhou, China, 2014.



FRAME SIZE OVERHEAD - ETHERNET

I X - frame sizeI O - the frame size overhead created by the encapsulation or the

translation processThe maximum theoretical frame rate for Ethernet

FRmax =LineRate(bps)

(8bits/byte)∗(X+O+20)bytes/frame (1)

Example for 6in47and 10Mb/s Ethernet in the case of 64byte frames

10,000,000(bps)(8bits/byte)∗(64+20+20)bytes/frame = 12, 019 fps (2)

6Nordmark and Gilligan, see n. 4.



SCALABILITY BENCHMARKING

Benchmarking Scalability through performance degradationObjective: To quantify the performance degradationintroduced by n parallel network flows.Procedure: First the benchmarking tests have to beperformed for one network flow. The same tests have tobe repeated for n-network flows. The performancedegradation of the X benchmarking dimension SHOULDbe calculated as relative performance change between the1-flow results and the n-flow results, using the followingformula:Reporting format: relative performance change betweenthe 1-flow results x1 and the n-flow results xn

Xpd = xn−x1x1× 100 (3)



SCALABILITY TEST SETUP

Single-stack transition technologies

+-------------------------++-----------|NF1 NF1|<----------+| +--------|NF2 tester NF2|<-------+ || | ...| | | || | +----|NFn NFn|<---+ | || | | +-------------------------+ | | || | | | | || | | +-------------------------+ | | || | +--->|NFn NFn|----+ | || | ...| DUT | | || +------->|NF2 (translator) NF2|--------+ |+---------->|NF1 NF1|-----------+

+-------------------------+



SCALABILITY TEST SETUP (CONTD.)Encapsulation/Translation-based transition technologies

+-------------------------++-----------------|NF1 NF1|<---------------+| +--------------|NF2 tester NF2|<-----------+ || | ...| | | || | +----------|NFn NFn|<--------+ | || | | +-------------------------+ | | || | | | | || | | +-----------------+ +--------------+ | | || | +--->|NFn DUT CEn NFn|--->|NFn NFn|---+ | || | +-----------------+ | | | || | ... | | | || | +-----------------+ | DUT PE | | || +------->|NF2 DUT CE2 NF2|--->|NF2 NF2|------+ || +-----------------+ | | || +-----------------+ | | |+---------->|NF1 DUT CE1 NF1|--->|NF1 NF1|----------+

+-----------------+ +--------------+



SCALABILITY EMPIRICAL RESULTS

0

10,000

20,000

30,000

40,000

50,000

60,000

70,000

80,000

90,000

100,000

64 128 256 512 1024 1280 1518 1522 2048 4096 8192 9216

Thro

ughputi

TC

Pi(

kbps)

i

Frameisizei(bytes)

asamape

asamape10



UPDATE OVERVIEW

I Added supplementary benchmarking tests for stateful IPv6 transitiontechnologies in accordance with RFC3511

I additional tests to distinguish 6→ 4 vs. 4→ 6 translation performance

I recommended UDP traffic for Section 6 benchmarks (Throughput,Latency, Frame loss rate, Back-to-back Frames, System recovery) andTCP traffic for Section 7 benchmarks (Concurrent TCP ConnectionCapacity, Maximum TCP Connection Establishment Rate)

I recommended a m:n test setup to evaluate the scalability ofencapsulation-based transition tech

I added MTU and routing recommendations

I specified multicast performance is outside the scope of the document



UPDATE: STATEFUL VS STATELESS

I generic definition of stateful IPv6 transition technologies in Section1.1: technologies which create dynamic correlations between IPaddreesses or {IP address, transport protocol, transport portnumber} tuples, which are stored in a state table.

I Added Section 7. Additional Benchmarking Tests for Stateful IPv6Transition Technologies (in accordance with RFC3511)

I Concurrent TCP Connection CapacityObjective: To determine the maximum number of concurrent TCPconnections supported through or with the DUT

I Maximum TCP Connection Establishment RateObjective: To determine the maximum TCP connectionestablishment rate through or with the DUT

4following the comments from Kaname Nishizuka.



UPDATE: 6→ 4 VS. 4→ 6 TRANSLATION

Text added to Section 3.2:In the case of translation based transition technology, the DUT CE andDUT PE machines MAY be tested separately as well. These tests canrepresent a fine grain performance analysis of the IPvX to IPvYtranslation direction versus the IPvY to IPvX translation direction. Thetests SHOULD follow the test setup presented in Figure 1.

5following the comments from Scott Bradner.



UPDATE: TRAFFIC RECOMMENDATIONS

Text added to Section 4.3:Because of the simplicity of UDP, UDP measurements offer a morereliable basis for comparison than other transport layer protocols.Consequently, for the benchmarking tests described in Section 6 of thisdocument UDP traffic SHOULD be employed.Considering that the stateful transition technologies need to managethe state table for each connection, a connection-oriented transportlayer protocol needs to be used with the test traffic. Consequently, TCPtraffic SHOULD be employed for the tests described in Section 7 of thisdocument.

6following the comments from Al Morton; Scott Bradner and Andrew McGregor.



UPDATE: CE SCALABILITY

Text added to Section 8.1:This test setup can help to quantify the scalability of the PE device.However, for testing the scalability of the DUT CEs additional setupsare needed. For encapsulation based transition technologies a m:nsetup can be created, where m is the number of flows applied to thesame CE device and n the number of CE devices connected to thesame PE device. For the translation based transition technologies theCE devices can be separately tested with n network flows using thetest setup presented in Figure 3.

7following the comments from Andrew McGregor.



UPDATE: MTU AND ROUTING RECOMMENDATIONS

Text added to Section 4.1:In the context of frame size overhead MTU recommendations are needed in order to avoid frameloss due to MTU mismatch between the virtual encapsulation/translation interfaces and thephysical network interface controllers (NICs). To avoid this situation, the larger MTU betweenthe physical NICs and virtual encapsulation/translation interfaces SHOULD be set for allinterfaces of the DUT and tester.

Text added to Section 3:For the simple test setups described in the next two subsections, static routing MAY beemployed. However, for more complex test setups (e.g. scalability testing setup) dynamicrouting is a more reasonable choice. However, the presence of routing and management framescan represent unwanted background data that can affect the benchmarking result. To that end,the procedures defined in [RFC2544] (Sections 11.2 and 11.3) related to routing and managementframes SHOULD be used here as well.

8following the comments from Bhuvan Vengainathan.



COMMENTS NOT COVERED YET

I The comment from Nalini Elkins related to DNS resolutionI Considering a DNS Resolution Performance metric: Number of

processed DNS requests/secI The comments about Jitter (Delay variation) from Bhuvan

Vengainathan and Al MortonI Considering adding a Delay variation metric to Section 6

I Suggestions are welcome



NEXT STEPS

I Propose solutions for DNS Resolution Performance and DelayVariation metrics

I Continue the revisions

? Questions for BMWG:I Were the comments covered well enough?I Is the draft ready for adoption ?



CONTACT

Marius [email protected]

www.ipv6net.ro


draft-georgescu-bmwg-ipv6-tran-tech-benchmarking-00

Technology

ipv6 performancebenchmarking

ipv6 hosts

ipv6 measurements

ipv6 benchmarking methodology

stepsipv6 transitioni

basic transition mechanisms

marius georgescu naist

internet engineeringtask