Subject: [v6ops] draft-lmhp-v6ops-transition-comparison **Call for Adoption**

From: Ron Bonica <[email-masked]>
Date: Tue, 21 Jan 2020 14:47:15 +0000

Folks,

Each week between now and IETF 107, we will review and discuss one draft with an eye towards progressing it.

This week, please review and comment on draft-lmhp-v6ops-transition-comparison .

When reviewing this draft, please indicate whether you think that V6OPS should adopt it a s a work item.

                                                      Fred and Ron

Juniper Business Use Only

---

From: Lencse Gábor <[email-masked]>
Date: Wed, 22 Jan 2020 16:03:19 +0100

Dear V6OPS Members,

The latest version of our draft contains a short section about 
Performance Comparison: 
https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-04#section-5

I consider the performance comparison of the different IPv6-as-a-Service 
solutions (and that of their different implementations) quite important 
from network operator point of view, because their performance 
requirement has a direct influence on the price of the required hardware 
and also on the electricity bill.

Let me give you a short summary, what we have for a reasonable 
performance comparison and what we are lacking of.

Theoretically, we have the methodology in RFC 8219 ("Benchmarking 
Methodology for IPv6 Transition Technologies").
However, only a small part of the methodology (DNS64) has been actually 
validated by real experiments. So far, the problem was the lack of 
compliant Testers.
I have recently implemented siitperf, a DPDK-based software Tester for 
SIIT (also called stateless NAT64) implementations: 
https://github.com/lencsegabor/siitperf
An MSc student of mine is working on a DS-Lite Tester, which I expect to 
be usable by the end of the Spring semester. (MAP-T/E and Lw4o6 Testers 
are planned to be implemented from the Autumn semester.)
For executing the benchmarking measurements, I can use some Dell servers 
with 10Gbps interfaces at the NICT StarBED, Japan: 
http://starbed.nict.go.jp/en/equipment/

I plan to start benchmarking with 464XLAT, as its CLAT and PLAT parts do 
stateless NAT46 and stateful NAT64, respectively, for which I have a 
tester. (Siitperf implements Througput, Frame Loss Rate, Latency, and 
Packet Delay Variation tests of RFC 8219.)

However, *there are some points in the methodology, where I will surely 
need some input from you* as I am a university researcher, and not a 
network operator.
I try to list the most important ones below.

1. Stateful operation

According to my understanding of RFC 8219, stateful technologies should 
be benchmarked with the corresponding stateless tests PLUS a few others 
defined in Section 8: https://tools.ietf.org/html/rfc8219#page-15

For the ease of use, I copy the relevant text here:

      8.1 <https://tools.ietf.org/html/rfc8219#section-8.1>. Concurrent
      TCP Connection Capacity

    UseSection 5.2 of [RFC3511]  <https://tools.ietf.org/html/rfc3511#section-5.2>  unmodified.

      8.2 <https://tools.ietf.org/html/rfc8219#section-8.2>. Maximum TCP
      Connection Establishment Rate

    UseSection 5.3 of [RFC3511]  <https://tools.ietf.org/html/rfc3511#section-5.3>  unmodified.

However, I do NOT believe that it is enough. Even if a PLAT can work 
with 10,000,000 TCP connections, and even if it can establish them fast 
enough, its performance very likely degrades as the size of the state 
table increases.

What method should be used for assessing this degradation?
Is the one below appropriate?

2. Scalability

Roughly speaking, I mean under scalability that if the number of the 
subscribers are doubled, than it will do if we also double the number of 
CPU cores assigned to the PLAT.

(Scalability can be a concern in the case of stateless operation, too. 
For example, when Explicit Address Mapping is used, the increasing size 
of the mapping table may also result in decreased performance. Of 
course, the connection tracking table of a stateful NAT64 gateway may 
have significantly more entries.)

Section 10 of RFC 8219 defines a methodology: 
https://tools.ietf.org/html/rfc8219#section-10

However, I have a few questions:
- What is the right number of network flows to use?
- How should I create a high number of network flows?

Currently, siitperf follows the requirement of RFC 8219, which uses the 
Throughput test of RFC 2544. It requires testing first, with a single 
source and destination address pair, and then using 256 different 
destination networks.

Details: For single flow, siitperf always sends out the same 
pre-generated test frames. For multi flow, siitperf pre-generates 256 
different test frames, where bits 16-23 of the IPv4 addresses and bits 
56-63 of the IPv6 addresses are used to express the different networks. 
The last byte was used to address the DUT (.1) and the Tester (.2). (For 
the ease of use, I used Explicit Address Mapping, when I performed an 
initial testing of siitperf: 
http://www.hit.bme.hu/~lencse/publications/IEICE-2019-siitperf-for-review.pdf 
.)
Which bits of the addresses should be used to create a high number of 
network flows?
Is it enough to use source port numbers to create a high number of 
network flows?
What source port range is to be used? (e.g. from 32768-65535)

Or perhaps, when using IPv4-embedded IPv6 addresses and Stateful NAT64, 
it is not a problem, as there are a high number of IPv6 addresses, which 
are then mapped for the same public IPv4 address.
However, still there are a lot of questions.
What number of IPv6 addresses are to be used?
What number of different source ports per IPv6 address are to be used?
What number of public IPv4 addresses are to be assigned to the NAT64 
gateway?

Current stateful NAT64 implementations usually use full 5-tuple, that is 
the same public IP addresses can be reused, when the destination 
addresses are different.
Fortunately, the most popular web sites are usually IPv6 capable, but 
there may be a few more popular sites among the IPv4-only ones.
Is it OK, to assume a uniform distribution of the destination addresses?

In many cases, I could just guess some numbers. However, I want to do 
the tests with *realistic parameters*, so the that results may be useful 
for the network operators.

Please give me suggestions, how to choose good enough parameters!

Thank you very much for your help in advance!

Best regards,

Gábor

2020.01.21. 15:47 keltezéssel, Ron Bonica írta:
>
> Folks,
>
> Each week between now and IETF 107, we will review and discuss one 
> draft with an eye towards progressing it.
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops