[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 <lencse@hit.bme.hu> Sun, 14 June 2020 18:09 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 822233A0366 for <bmwg@ietfa.amsl.com>; Sun, 14 Jun 2020 11:09:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 CVR0l4isn5KL for <bmwg@ietfa.amsl.com>; Sun, 14 Jun 2020 11:09:01 -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 EBB8E3A0365 for <bmwg@ietf.org>; Sun, 14 Jun 2020 11:09:00 -0700 (PDT)
Received: from [192.168.1.101] (host-79-121-43-73.kabelnet.hu [79.121.43.73]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id 05EI8n6T005244 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <bmwg@ietf.org>; Sun, 14 Jun 2020 20:08:56 +0200 (CEST) (envelope-from lencse@hit.bme.hu)
X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-43-73.kabelnet.hu [79.121.43.73] claimed to be [192.168.1.101]
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>
From: =?UTF-8?Q?G=c3=a1bor_LENCSE?= <lencse@hit.bme.hu>
Message-ID: <8e02d83a-91f1-a31f-313c-f8910b7ae99a@hit.bme.hu>
Date: Sun, 14 Jun 2020 20:08:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF0108A5BC52@njmtexg5.research.att.com>
Content-Type: multipart/alternative; boundary="------------8EE570433FFA03C06BD077CC"
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.43.73; helo=[192.168.1.101]; 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/Y3XIteCBVMScSolsagPH_FNoi_E>
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
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: Sun, 14 Jun 2020 18:09:03 -0000

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