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)" <acm@research.att.com> Sat, 20 June 2020 18:48 UTC

Return-Path: <acm@research.att.com>
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 5FF683A08F3 for <bmwg@ietfa.amsl.com>; Sat, 20 Jun 2020 11:48:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level:
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 lXLChDF_lVin for <bmwg@ietfa.amsl.com>; Sat, 20 Jun 2020 11:48:28 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 75A983A08EE for <bmwg@ietf.org>; Sat, 20 Jun 2020 11:48:28 -0700 (PDT)
Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 05KIg5Wv047637; Sat, 20 Jun 2020 14:48:14 -0400
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by mx0a-00191d01.pphosted.com with ESMTP id 31sch17pny-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 20 Jun 2020 14:48:14 -0400
Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 05KImCqH002977; Sat, 20 Jun 2020 13:48:13 -0500
Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [135.46.181.159]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 05KIm7j5002874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 20 Jun 2020 13:48:08 -0500
Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [127.0.0.1]) by zlp30494.vci.att.com (Service) with ESMTP id C0E374005C32; Sat, 20 Jun 2020 18:48:07 +0000 (GMT)
Received: from clph811.sldc.sbc.com (unknown [135.41.107.12]) by zlp30494.vci.att.com (Service) with ESMTP id 9F9F74005C19; Sat, 20 Jun 2020 18:48:07 +0000 (GMT)
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clph811.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 05KIm7Dg007531; Sat, 20 Jun 2020 13:48:07 -0500
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clph811.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 05KIlxCB006907; Sat, 20 Jun 2020 13:48:00 -0500
Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-blue.research.att.com (Postfix) with ESMTPS id F2BC210A198E; Sat, 20 Jun 2020 14:47:57 -0400 (EDT)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0468.000; Sat, 20 Jun 2020 14:47:57 -0400
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: =?utf-8?B?R8OhYm9yIExFTkNTRQ==?= <lencse@hit.bme.hu>, "bmwg@ietf.org" <bmwg@ietf.org>
Thread-Topic: [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
Thread-Index: AQHWQnbr29RP9Kj0MEeO3YS7Csoq2qjh3kOw
Date: Sat, 20 Jun 2020 18:47:56 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CF0108A66E93@njmtexg5.research.att.com>
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>
In-Reply-To: <8e02d83a-91f1-a31f-313c-f8910b7ae99a@hit.bme.hu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [69.141.203.172]
Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CF0108A66E93njmtexg5resea_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-20_09:2020-06-19, 2020-06-20 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 bulkscore=0 cotscore=-2147483648 suspectscore=0 lowpriorityscore=0 priorityscore=1501 mlxscore=0 phishscore=0 spamscore=0 impostorscore=0 adultscore=0 mlxlogscore=999 clxscore=1015 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006200136
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/94qY9myHJNuUEmnZ_iBamPcHC6Q>
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, 20 Jun 2020 18:48:30 -0000

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