Re: [bmwg] Question regarding source and destination port numbers -- Re: An Upgrade to Benchmarking Methodology for Network Interconnect Devices -- Fwd: New Version Notification for draft-lencse-bmwg-rfc2544-bis-00.txt
Lencse Gábor <lencse@hit.bme.hu> Sat, 15 August 2020 13:49 UTC
Return-Path: <lencse@hit.bme.hu>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 4AD1A3A0E6B
for <bmwg@ietfa.amsl.com>; Sat, 15 Aug 2020 06:49:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.748
X-Spam-Level:
X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1,
NICE_REPLY_A=-0.949, SPF_PASS=-0.001, URIBL_BLOCKED=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 HXJE2i5DR45F for <bmwg@ietfa.amsl.com>;
Sat, 15 Aug 2020 06:49:17 -0700 (PDT)
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 D2C923A0E68
for <bmwg@ietf.org>; Sat, 15 Aug 2020 06:49:16 -0700 (PDT)
Received: from [192.168.1.104] (host-79-121-42-233.kabelnet.hu [79.121.42.233])
(authenticated bits=0)
by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id 07FDn2MW013857
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO)
for <bmwg@ietf.org>; Sat, 15 Aug 2020 15:49:08 +0200 (CEST)
(envelope-from lencse@hit.bme.hu)
X-Authentication-Warning: frogstar.hit.bme.hu: Host
host-79-121-42-233.kabelnet.hu [79.121.42.233] claimed to be [192.168.1.104]
To: "bmwg@ietf.org" <bmwg@ietf.org>
References: <158995996438.13925.2934780472900149847@ietfa.amsl.com>
<14002442-9713-d474-8012-bca5dcd6976c@hit.bme.hu>
<4D7F4AD313D3FC43A053B309F97543CF0108A5BA22@njmtexg5.research.att.com>
<598e85fd-cf9b-1cdd-61c0-3a76623145f9@hit.bme.hu>
<4D7F4AD313D3FC43A053B309F97543CF0108A5BC52@njmtexg5.research.att.com>
<8e02d83a-91f1-a31f-313c-f8910b7ae99a@hit.bme.hu>
<4D7F4AD313D3FC43A053B309F97543CF0108A66E93@njmtexg5.research.att.com>
From: =?UTF-8?Q?Lencse_G=c3=a1bor?= <lencse@hit.bme.hu>
Message-ID: <34c41e1e-f036-879f-d07a-498cb689ecf3@hit.bme.hu>
Date: Sat, 15 Aug 2020 15:48:58 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101
Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF0108A66E93@njmtexg5.research.att.com>
Content-Type: multipart/alternative;
boundary="------------60C9C35A3F7BFF5A47B2E9DC"
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.102.4 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.233; helo=[192.168.1.104];
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/bmwg/t3TKnwaPCqSAbox2Zdq61zrmZNA>
Subject: Re: [bmwg] Question regarding source and destination port numbers
-- Re: An Upgrade to Benchmarking Methodology for Network Interconnect
Devices -- Fwd: New Version Notification for
draft-lencse-bmwg-rfc2544-bis-00.txt
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bmwg>,
<mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bmwg/>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>,
<mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Aug 2020 13:49:21 -0000
Dear Al, Thank you very much for your advise! I have implemented random ports according to your guidance. I think it became really flexible. It can be set for each direction, and also for source and destination port numbers, whether to keep the old fix port numbers of the RFC 2544 Test Frame, or to use varying port numbers from a given range. In addition to random port numbers, the user can also set increasing or decreasing port numbers in the specified range. I quote the settings from the siitperf.conf file: |# Parameters for RFC 4814 random port feature |||#| Forward (left to right) direction: Fwd-var-sport 3 # Does source port vary? 0: fix, 1: increase, 2: decrease, 3: random Fwd-var-dport 3 # Does destination port vary? 0: fix, 1: increase, 2: decrease, 3: random Fwd-sport-min 1024 Fwd-sport-max 65535 Fwd-dport-min 1 Fwd-dport-max 49151 ||||#| Reverse (||||||right|||||||||| to ||||||left||) direction:| Rev-var-sport 3 # Does source port vary? 0: fix, 1: increase, 2: decrease, 3: random Rev-var-dport 3 # Does destination port vary? 0: fix, 1: increase, 2: decrease, 3: random Rev-sport-min 1024 Rev-sport-max 65535 Rev-dport-min 1 Rev-dport-max 49151| In the settings above, I have "blindly" followed RFC 4814 for the ranges, however I do not completely agree with them. Whereas it seems to be logical to use source port range [1024, 65535] and destination port range [1, 49151] it is so only for the _first UDP datagram_ (or the SYN segment of TCP). Source and destination ports change their roles in the reply, therefore forwarding devices (e.g. routers, SIIT gateways, etc.) SHOULD be able to handle source and destination ports in the full [1, 65535] (or even [0, 65535]) range. Am I not right? I have implemented the variable port feature in siitperf only for the Throughput measurements, Latency and PDV are still left. The modified source code is available in the "varport" branch of siitperf: https://github.com/lencsegabor/siitperf/tree/varport I would be happy to receive feedback! Please note that siitperf can also be used for benchmarking IPv4 or IPv6 routers, thus it is not necessary to configure a SIIT gateway, if someone would like to experiment with siitperf. :-) And a more difficult question: What about benchmarking Stateful NAT64? I designed siitperf for bechmarking SIIT (also called stateless NAT64) gateways. I would like to extend it for benchmarking stateful NAT64 gateways, too. When I was not aware of RFC 4814, I had the following idea: Before the bechmarking measurements, the Tester should send a Test Frame in the IPv6 --> IPv4 direction, then extract the IPv4 addresses and port numbers from it, and use them in the Test Frames in the IPv6 --> IPv4 direction Test Frames (after swapping). Theoretically, this approach can be followed for a high number of source and destination port number combinations, too. How would it look like? - source port range is [1024, 65535], that is 65535-1024+1=64512 different port numbers - destination port range is [1, 49151], that is 49151 different port numbers To use all possible combinations, 64512 * 49151 = 3170893824 connections would be necessary. It would very likely exhaust the connection tracking table of the stateful NAT64 gateway. Thus, should I randomly select a smaller number of combinations? Exactly what number? A few thousand? A few million? Of course, using some different sample sizes like 1000, 10000, 10000, 100000, could show, how the performance of the stateless NAT64 implementation scales as the function of the number of connections. However, what is a typical range to be used for testing? Perhaps RFC 8219 should be amended with some guidance regarding this issue... Does anyone has experience in benchmarking stateful NAT44 gateways? That experience could help a lot... Best regards, Gábor 2020.06.20. 20:47 keltezéssel, MORTON, ALFRED C (AL) írta: > > Hi Gábor, > > Please see my reply below, and sorry for the latency! > > BMWG, > > even though some messages to the list might be addressed to me, feel > free to chime-in with your opinions and experiences too! > > Al > > bmwg co-chair > > *From:*bmwg [mailto:bmwg-bounces@ietf.org] *On Behalf Of *Gábor LENCSE > *Sent:* Sunday, June 14, 2020 2:09 PM > *To:* bmwg@ietf.org > *Subject:* [bmwg] Question regarding source and destination port > numbers -- Re: An Upgrade to Benchmarking Methodology for Network > Interconnect Devices -- Fwd: New Version Notification for > draft-lencse-bmwg-rfc2544-bis-00.txt > > Dear Al Morton, > > I would like to ask your advice regarding the usage of different > source and destination port numbers. > > On 5/23/2020 19:40, MORTON, ALFRED C (AL) wrote: > > > > Thank you very much for your reply and for all the references! I was not > > aware of them and now I see that they have already solved several of the > > issues we wanted to handle. (Even some issues, which we did not mention > > in the draft, but I had in my mind, like using a high number of > > different source port numbers for the tests.) > > [acm] > > Yes, starting out with 1 flow will probably reap the best performance, > > but this can be a distinguishing factor, as seen with virtual switches > > (OVS, OVS+DPDK and VPP). > > RFC 4814 requires that (emphasis by bold font is from me): > > Test instruments have the capability of generating packets with > random TCP and UDP source and destination port numbers. Known > destination port numbers are often required for testing application- > layer devices. However, unless known port numbers are specifically > required for a test, it is RECOMMENDED to use*pseudorandom and* > * uniformly distributed values for both source and destination port* > * numbers*. > In addition, it may be desirable to pick pseudorandom values from a > selected pool of numbers. Many services identify themselves through > use of reserved destination port numbers between*1 and 49151* > inclusive. Unless specific port numbers are required, it is > RECOMMENDED to pick randomly distributed destination port numbers > between these lower and upper boundaries. > Similarly, clients typically choose source port numbers in the space > between*1024 and 65535* inclusive. Unless specific port numbers are > required, it is RECOMMENDED to pick randomly distributed source port > numbers between these lower and upper boundaries. > > > Source: https://tools.ietf.org/html/rfc4814#section-4.5 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4814-23section-2D4.5&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=d2qGiVfbiAiPe3jfEeeeSe99GibSyq-T5I8dk2A8y6U&s=M88c6YG_1os47Hvh6hSUxp67F3fd1QDVPcidQLqFTzA&e=> > > > I want to implement this feature into siitperf, my RFC 8129 compliant > SIIT tester: https://github.com/lencsegabor/siitperf > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_lencsegabor_siitperf&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=d2qGiVfbiAiPe3jfEeeeSe99GibSyq-T5I8dk2A8y6U&s=6qeskk8jE5s4LsOS7G66yJIM64xxdZR40ujPT4jRHhU&e=> > > My question is, what parameters and parameter combinations can be > meaningful? > > For example: > > random_src_port yes|no > if yes, then: first_src_port, last_src_port > > random_dst_port yes|no > if yes, then: first_dst_port, last_dst_port > > RFC 2544 requires bidirectional traffic. It also requires testing with > a single source and destination address pair first, and the using 256 > destination networks. In siitperf, I implemented it in a way that the > number or destination networks can be set from 1 to 255 *per direction*. > > My question is if it is worth giving an opportunity to set the above > parameters *per direction*? > > */[acm] /**I think so, you would then have full control over the > 4-tuple of traffic in each direction.* > > *I would like to hear form the Next-Gen Firewall authors and advocates > on this topic, too.* > > *Al (as a participant)* > > Thank you very much for your advice in advance! > > Best regards, > > Gábor Lencse > > >
- [bmwg] An Upgrade to Benchmarking Methodology for… Lencse Gábor
- Re: [bmwg] An Upgrade to Benchmarking Methodology… MORTON, ALFRED C (AL)
- Re: [bmwg] An Upgrade to Benchmarking Methodology… Lencse Gábor
- Re: [bmwg] An Upgrade to Benchmarking Methodology… MORTON, ALFRED C (AL)
- Re: [bmwg] An Upgrade to Benchmarking Methodology… tom petch
- Re: [bmwg] An Upgrade to Benchmarking Methodology… Lencse Gábor
- [bmwg] Question regarding source and destination … Gábor LENCSE
- Re: [bmwg] Question regarding source and destinat… MORTON, ALFRED C (AL)
- Re: [bmwg] An Upgrade to Benchmarking Methodology… MORTON, ALFRED C (AL)
- Re: [bmwg] Question regarding source and destinat… Lencse Gábor