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
- [v6ops] draft-lmhp-v6ops-transition-comparison **… Ron Bonica
- Re: [v6ops] draft-lmhp-v6ops-transition-compariso… Lencse Gábor