Internet draft presentation: Benchmarking Methodology for IPv6 Transition Technologies (draft-georgescu-bmwg-ipv6-tran-tech-benchmarking-00). IETF 92, Dallas, Texas, USA

1. iplab
Benchmarking Methodology for IPv6 Transition
Technologies
draft-georgescu-bmwg-ipv6-tran-tech-benchmarking-00
Marius Georgescu
Nara Institute of Science and Technology
Internet Engineering Laboratory
24 Mar. 2015

2. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
IPV6 TRANSITION
IPv6 is not backwards
compatible
The Internet will undergo
a period through which
both protocols will coexist
Currently only 2 % of
worldwide Internet users
have IPv6 connectivity 1
2
1
APNIC. IPv6 measurements for The World. Asia-Pacific Network Information Centre, Oct. 2014. URL:
http://labs.apnic.net/ipv6-measurement/Regions/.
2
Original drawing by Andrew Bell @ www.creaturesinmyhead.com .
Marius Georgescu (NAIST) IETF92 24.03.2015 2 / 25

3. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
IPV6 TRANSITION TECHNOLOGIES EVOLUTION
SAM 4rd
MAP- E
4rd- (H,U)
IVI dIVI dIVI- pd MAP- T
DS- lite
Publicg4over6
Lightweightg4over6
StatelessgDS- lite
A+ P
6to4 6rdg
6over4 ISATAP
Teredo
Configured5Tunnel
Tunnel5Broker
RFC52893
NAT6455
NAT-PT55
NAT4645
5
464XLAT55
20102000 2015
Automatic5
tunnels
3
3
inspired by the APNIC35 presentation ”The evolution of IPv6 transition technologies” by Jouni Korhonen.
Marius Georgescu (NAIST) IETF92 24.03.2015 3 / 25

4. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
DRAFT OVERVIEW
RFC25444
and RFC51805
address both IPv4 and IPv6 performance
benchmarking, but IPv6 transition technologies are outside their scope
This draft provides complementary guidelines 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 RFC35116
1
S. Bradner and J. McQuaid. Benchmarking Methodology for Network Interconnect Devices. United States, 1999.
2
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.
3
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) IETF92 24.03.2015 4 / 25

5. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
BASIC TRANSITION TECHNOLOGIES
Dual Stack 4
Host side and edge nodes
A base for other transition
technologies
Translation
Achieves direct
communication
Breaks the end-to-end model
Tunneling
heterogeneous
environments traversal
IPv4 Header Payload
Payload
Dual stack
IPv6 Header Payload
IPv4 Header Payload
IPv6 Translated
Header
Payload
Translation
IPv4 Header Payload
IPv4 Header PayloadIPv6 Header
Encapsulation
4
E. 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.
Marius Georgescu (NAIST) IETF92 24.03.2015 5 / 25

6. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
MAP
Mapping of Address and Port with
Encapsulation 5building blocks:
MAP domain
Customer Edge (CE) router
Boarder Relay (BR) router
MAP rule
IPv4 prefix
IPv6 prefix
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
PayloadIPv6 Header
Encapsulation
IPv4 Translated
Header
PayloadIPv6 Header
Decapsulation
IPv4 Translated
Header
5
O. Troan et al. Mapping of Address and Port with Encapsulation (MAP). . draft-ietf-softwire-map-10. Internet Engineering
Task Force, Jan. 2014. URL: http://tools.ietf.org/html/draft-ietf-softwire-map-10.
Marius Georgescu (NAIST) IETF92 24.03.2015 6 / 25

7. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
PRODUCTION NETWORKS GENERIC DESIGN
Customer Edge (CE)
segment
Core network segment
Provider Edge (PE)
segment
Services
over IP
Customer Edge
Segment
CE
router
PE
router
Core network
Segment
Provider edge
Segment
Marius Georgescu (NAIST) IETF92 24.03.2015 7 / 25

8. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
IPV6 TRANSITION TECHNOLOGIES GENERIC
CATEGORIES
1. Single-stack: either IPv4 or IPv6 is used to traverse the core
network and translation is used at one of the edges
2. Dual-stack: the core network devices implement both IP protocols
3. Encapsulation-based: an encapsulation mechanism is used to
traverse the core network; CE nodes encapsulate the IPvX packets
in IPvY packets, while PE nodes are responsible for the
decapsulation process.
4. Translation-based: a translation mechanism is employed for the
traversal of the network core; CE nodes translate IPvX packets to
IPvY packets and PE nodes translate the packets back to IPvX.
Marius Georgescu (NAIST) IETF92 24.03.2015 8 / 25

9. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
TEST ENVIRONMENT SETUP
Single-stack transition technologies
+--------------------+
| |
+------------|IPvX tester IPvY|<-------------+
| | | |
| +--------------------+ |
| |
| +--------------------+ |
| | | |
+----------->|IPvX DUT IPvY|--------------+
| (translator) |
+--------------------+
Marius Georgescu (NAIST) IETF92 24.03.2015 9 / 25

10. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
TEST ENVIRONMENT SETUP (CONTD.)
Encapsulation/Translation-based transition technologies
+--------------------+
| |
+---------------------|IPvX tester IPvX|<------------------+
| | | |
| +--------------------+ |
| |
| +--------------------+ +--------------------+ |
| | | | | |
+----->|IPvX DUT CE IPvY|----->|IPvY DUT PE IPvX|------+
| trans/encaps | | trans/decaps |
+--------------------+ +--------------------+
Marius Georgescu (NAIST) IETF92 24.03.2015 10 / 25

11. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
EMPIRICAL RESULTS
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
64 128 256 512 1024 1280 1518 1522 2048 4096 8192 9216
ThroughputzTCPzXkbpsL
FramezsizezXbytesL
DCzIPv4
DCzIPv6
ASAMAPzIPv6
MAPtzIPv4
464XLATzIPv4
MAPezIPv4
DSLitezIPv4
6
6
M. 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.
Marius Georgescu (NAIST) IETF92 24.03.2015 11 / 25

12. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
FRAME SIZE OVERHEAD - ETHERNET
X - frame size
O - the frame size overhead created by the encapsulation or the
translation process
The 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)
6
Nordmark and Gilligan, see n. 4.
Marius Georgescu (NAIST) IETF92 24.03.2015 12 / 25

13. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
SCALABILITY BENCHMARKING
Benchmarking Scalability through performance degradation
Objective: To quantify the performance degradation
introduced by n parallel network flows.
Procedure: First the benchmarking tests have to be
performed for one network flow. The same tests have to
be repeated for n-network flows. The performance
degradation of the X benchmarking dimension SHOULD
be calculated as relative performance change between the
1-flow results and the n-flow results, using the following
formula:
Reporting format: relative performance change between
the 1-flow results x1 and the n-flow results xn
Xpd = xn−x1
x1
× 100 (3)
Marius Georgescu (NAIST) IETF92 24.03.2015 13 / 25

14. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
SCALABILITY TEST SETUP
Single-stack transition technologies
+-------------------------+
+-----------|NF1 NF1|<----------+
| +--------|NF2 tester NF2|<-------+ |
| | ...| | | |
| | +----|NFn NFn|<---+ | |
| | | +-------------------------+ | | |
| | | | | |
| | | +-------------------------+ | | |
| | +--->|NFn NFn|----+ | |
| | ...| DUT | | |
| +------->|NF2 (translator) NF2|--------+ |
+---------->|NF1 NF1|-----------+
+-------------------------+
Marius Georgescu (NAIST) IETF92 24.03.2015 14 / 25

15. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
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|----------+
+-----------------+ +--------------+
Marius Georgescu (NAIST) IETF92 24.03.2015 15 / 25

16. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
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
ThroughputiTCPi(kbps)i
Frameisizei(bytes)
asamape
asamape10
Marius Georgescu (NAIST) IETF92 24.03.2015 16 / 25

17. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
UPDATE OVERVIEW
Added supplementary benchmarking tests for stateful IPv6 transition
technologies in accordance with RFC3511
additional tests to distinguish 6 → 4 vs. 4 → 6 translation performance
recommended UDP traffic for Section 6 benchmarks (Throughput,
Latency, Frame loss rate, Back-to-back Frames, System recovery) and
TCP traffic for Section 7 benchmarks (Concurrent TCP Connection
Capacity, Maximum TCP Connection Establishment Rate)
recommended a m:n test setup to evaluate the scalability of
encapsulation-based transition tech
added MTU and routing recommendations
specified multicast performance is outside the scope of the document
Marius Georgescu (NAIST) IETF92 24.03.2015 17 / 25

18. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
UPDATE: STATEFUL VS STATELESS
generic definition of stateful IPv6 transition technologies in Section
1.1: technologies which create dynamic correlations between IP
addreesses or {IP address, transport protocol, transport port
number} tuples, which are stored in a state table.
Added Section 7. Additional Benchmarking Tests for Stateful IPv6
Transition Technologies (in accordance with RFC3511)
Concurrent TCP Connection Capacity
Objective: To determine the maximum number of concurrent TCP
connections supported through or with the DUT
Maximum TCP Connection Establishment Rate
Objective: To determine the maximum TCP connection
establishment rate through or with the DUT
4
following the comments from Kaname Nishizuka.
Marius Georgescu (NAIST) IETF92 24.03.2015 18 / 25

19. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
UPDATE: 6 → 4 VS. 4 → 6 TRANSLATION
Text added to Section 3.2:
In the case of translation based transition technology, the DUT CE and
DUT PE machines MAY be tested separately as well. These tests can
represent a fine grain performance analysis of the IPvX to IPvY
translation direction versus the IPvY to IPvX translation direction. The
tests SHOULD follow the test setup presented in Figure 1.
5
following the comments from Scott Bradner.
Marius Georgescu (NAIST) IETF92 24.03.2015 19 / 25

20. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
UPDATE: TRAFFIC RECOMMENDATIONS
Text added to Section 4.3:
Because of the simplicity of UDP, UDP measurements offer a more
reliable basis for comparison than other transport layer protocols.
Consequently, for the benchmarking tests described in Section 6 of this
document UDP traffic SHOULD be employed.
Considering that the stateful transition technologies need to manage
the state table for each connection, a connection-oriented transport
layer protocol needs to be used with the test traffic. Consequently, TCP
traffic SHOULD be employed for the tests described in Section 7 of this
document.
6
following the comments from Al Morton; Scott Bradner and Andrew McGregor.
Marius Georgescu (NAIST) IETF92 24.03.2015 20 / 25

21. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
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 setups
are needed. For encapsulation based transition technologies a m:n
setup can be created, where m is the number of flows applied to the
same CE device and n the number of CE devices connected to the
same PE device. For the translation based transition technologies the
CE devices can be separately tested with n network flows using the
test setup presented in Figure 3.
7
following the comments from Andrew McGregor.
Marius Georgescu (NAIST) IETF92 24.03.2015 21 / 25

22. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
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 frame
loss due to MTU mismatch between the virtual encapsulation/translation interfaces and the
physical network interface controllers (NICs). To avoid this situation, the larger MTU between
the physical NICs and virtual encapsulation/translation interfaces SHOULD be set for all
interfaces of the DUT and tester.
Text added to Section 3:
For the simple test setups described in the next two subsections, static routing MAY be
employed. However, for more complex test setups (e.g. scalability testing setup) dynamic
routing is a more reasonable choice. However, the presence of routing and management frames
can 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 management
frames SHOULD be used here as well.
8
following the comments from Bhuvan Vengainathan.
Marius Georgescu (NAIST) IETF92 24.03.2015 22 / 25

23. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
COMMENTS NOT COVERED YET
The comment from Nalini Elkins related to DNS resolution
Considering a DNS Resolution Performance metric: Number of
processed DNS requests/sec
The comments about Jitter (Delay variation) from Bhuvan
Vengainathan and Al Morton
Considering adding a Delay variation metric to Section 6
Suggestions are welcome
Marius Georgescu (NAIST) IETF92 24.03.2015 23 / 25

24. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
NEXT STEPS
Propose solutions for DNS Resolution Performance and Delay
Variation metrics
Continue the revisions
Questions for BMWG:
Were the comments covered well enough?
Is the draft ready for adoption ?
Marius Georgescu (NAIST) IETF92 24.03.2015 24 / 25

25. IPv6 transition DRAFT OVERVIEW DRAFT UPDATE NEXT STEPS
CONTACT
Marius Georgescu
liviumarius-g@is.naist.jp
www.ipv6net.ro
Marius Georgescu (NAIST) IETF92 24.03.2015 25 / 25