IETF Logo Mail Archive

Re: [bmwg] Rx Window question - Benchmarking Methodology for Network Security Device Performance

"MORTON, ALFRED C (AL)" <acm@research.att.com> Wed, 13 February 2019 13: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 8D215131054 for <bmwg@ietfa.amsl.com>; Wed, 13 Feb 2019 05:48:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.611
X-Spam-Level:
X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 b5RXASfQ1EjZ for <bmwg@ietfa.amsl.com>; Wed, 13 Feb 2019 05:48:24 -0800 (PST)
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 7416913104B for <bmwg@ietf.org>; Wed, 13 Feb 2019 05:48:24 -0800 (PST)
Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1DDjL4U040458; Wed, 13 Feb 2019 08:48:23 -0500
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by mx0a-00191d01.pphosted.com with ESMTP id 2qmjyca420-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Feb 2019 08:48:23 -0500
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 x1DDmKNk058209; Wed, 13 Feb 2019 07:48:22 -0600
Received: from zlp30496.vci.att.com (zlp30496.vci.att.com [135.46.181.157]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id x1DDmH0X058077; Wed, 13 Feb 2019 07:48:18 -0600
Received: from zlp30496.vci.att.com (zlp30496.vci.att.com [127.0.0.1]) by zlp30496.vci.att.com (Service) with ESMTP id 5674540CF589; Wed, 13 Feb 2019 13:48:17 +0000 (GMT)
Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30496.vci.att.com (Service) with ESMTP id 2F04040CF582; Wed, 13 Feb 2019 13:48:17 +0000 (GMT)
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id x1DDmHkN000453; Wed, 13 Feb 2019 07:48:17 -0600
Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id x1DDmAF9032451; Wed, 13 Feb 2019 07:48:12 -0600
Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-azure.research.att.com (Postfix) with ESMTP id 28F79E01A2; Wed, 13 Feb 2019 08:48:09 -0500 (EST)
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.0435.000; Wed, 13 Feb 2019 08:47:47 -0500
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: Brian Monkman <bmonkman@netsecopen.org>, "bmwg@ietf.org" <bmwg@ietf.org>
CC: 'Bala Balarajah' <bala@netsecopen.org>
Thread-Topic: [bmwg] Rx Window question - Benchmarking Methodology for Network Security Device Performance
Thread-Index: AdTDf38UOflNzvrRTMiXqndXPnlNnwAIcf5g
Date: Wed, 13 Feb 2019 13:47:46 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CF6BFD72DD@njmtexg5.research.att.com>
References: <00ce01d4c380$a2684680$e738d380$@netsecopen.org>
In-Reply-To: <00ce01d4c380$a2684680$e738d380$@netsecopen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [69.141.203.172]
Content-Type: multipart/related; boundary="_004_4D7F4AD313D3FC43A053B309F97543CF6BFD72DDnjmtexg5researc_"; type="multipart/alternative"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-13_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902130102
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/NT4kcIl-Oq-AZGtmvnCIwQho7YU>
Subject: Re: [bmwg] Rx Window question - Benchmarking Methodology for Network Security Device Performance
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: Wed, 13 Feb 2019 13:48:36 -0000

Hi Brian,
Thanks for following up on this point.
64k is likely to be a "safer" answer than 32k.

It's important to consider that you are setting the
Max Receive Window size limit in octets.

I think we simply want to ensure that none of the
TCP connections are operating in a Rcv Window-limited
state.

The (max)buffering in the Firewall and the link speeds
are critical factors you need to determine if a
Max Rcv Window size is sufficient to avoid limiting the connections.
Then calculate the Bandwidth-Delay Product:
https://www.slashroot.in/linux-network-tcp-performance-tuning-sysctl
(scroll down a bit).

The Bottom Line: you don't want the TCP streams to
operate in a "receive window-limited"  mode.
It's probably best to give connections more window than they need,
and also not try to tune to a specific window size exactly.

The congestion control algorithm, etc., also matters.
All the relevant TCP options need to be specified in the
report.

hope this helps,
Al


From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Brian Monkman
Sent: Wednesday, February 13, 2019 4:44 AM
To: bmwg@ietf.org
Cc: 'Bala Balarajah' <bala@netsecopen.org>
Subject: [bmwg] Rx Window question - Benchmarking Methodology for Network Security Device Performance

Folks,

We are making some changes to the draft before we submit it for review. These changes have resulted from our proof of concept testing.

One question is the Receive Window size. Currently in the draft it is 32k. This appears to be too small for the real world. While researching what we should use, we determined that there does not appear to be anything approaching a defacto standard or even a good solid reference.

We have determined that the default receive window size for Windows operating system is 64k. While many Linux variants use 128k.

So, my question to use is this.... What do you think should be used? The way I see it our choices are:


  1.  64k
  2.  128k
  3.  64k or 128k (choice made by the tester and documented if the results are made public)

Thoughts or alternate suggestions anyone?

Thank you in advance.

Brian

---------
Brian Monkman
Executive Director, NetSecOPEN
Office: +1-717-610-0808
Fax: +1-717-506-0460
Mobile: +1-717-462-5422

[cid:image001.png@01D2EC14.5F737970]
https://www.netsecopen.org<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.netsecopen.org&d=DwQFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=MUT1uFtEFACP5dPictqITC0x73ATrx-6JiMM27LUEec&s=psg1BM6BBwPGSBmCvxknTKCUncFWebs8hJVUHuc42mA&e=>

v2.23.0 | Report a Bug | By Email