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

["MORTON, ALFRED C (AL)" <[e-mail]>]

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