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 <[e-mail]>]

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:[e-mail]] *On Behalf Of *Gábor LENCSE
> *Sent:* Sunday, June 14, 2020 2:09 PM
> *To:* [e-mail]
> *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
>
>
>