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

Lencse Gábor <lencse@hit.bme.hu> Wed, 22 January 2020 15:03 UTC

Return-Path: <lencse@hit.bme.hu>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84631200F6 for <v6ops@ietfa.amsl.com>; Wed, 22 Jan 2020 07:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qd8GafEyukYm for <v6ops@ietfa.amsl.com>; Wed, 22 Jan 2020 07:03:36 -0800 (PST)
Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A73C1200EF for <v6ops@ietf.org>; Wed, 22 Jan 2020 07:03:35 -0800 (PST)
Received: from [192.168.1.135] (host-79-121-42-199.kabelnet.hu [79.121.42.199]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id 00MF3NiU038671 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <v6ops@ietf.org>; Wed, 22 Jan 2020 16:03:29 +0100 (CET) (envelope-from lencse@hit.bme.hu)
X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-42-199.kabelnet.hu [79.121.42.199] claimed to be [192.168.1.135]
To: v6ops@ietf.org
References: <BN7PR05MB3938E445275493A6BFC9B3F1AE0D0@BN7PR05MB3938.namprd05.prod.outlook.com>
From: Lencse Gábor <lencse@hit.bme.hu>
Message-ID: <0cc2383b-4be4-4958-f5a5-6c21830b3e10@hit.bme.hu>
Date: Wed, 22 Jan 2020 16:03:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <BN7PR05MB3938E445275493A6BFC9B3F1AE0D0@BN7PR05MB3938.namprd05.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------6FBCC5B80E3E89CD5C2B6520"
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.101.2 at frogstar.hit.bme.hu
X-Virus-Status: Clean
Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.42.199; helo=[192.168.1.135]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10;
X-DCC--Metrics: frogstar.hit.bme.hu; whitelist
X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/6xq3MzrDmuFx-MiidKUdbgJ3k6E>
Subject: Re: [v6ops] draft-lmhp-v6ops-transition-comparison **Call for Adoption**
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2020 15:03:42 -0000

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.
>
> 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
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops