[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

[Gábor LENCSE <[e-mail]>]

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

I want to implement this feature into siitperf, my RFC 8129 compliant 
SIIT tester: https://github.com/lencsegabor/siitperf

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*?

Thank you very much for your advice in advance!

Best regards,

Gábor Lencse