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

Hi,

For our end-to-end performance work, we commonly cite the ESnet guidance on tuning:
https://fasterdata.es.net/host-tuning/

It's interesting that firewall buffering is mentioned below; in general the higher volume research data transfers over R&E networks recommend routing around the campus "business" firewall and applying security policy more appropriately to the science/research traffic.  Generally following the "Science DMZ" approach, as per https://fasterdata.es.net/science-dmz/.

I'm not sure what the benchmarking document in this WG considers in scope, but it would be interesting to be able to test a commercial firewall's ability to pass a small number of high throughput, high pps flows while also performing more detailed inspection on tens of thousands of "business" traffic flows (web, email, ...).  The inability for many commercial firewalls to do that well is exactly why ESnet published their Science DMZ model.

Tim

On 13 Feb 2019, at 13:47, MORTON, ALFRED C (AL) <acm@research.att.com<mailto:acm@research.att.com>> wrote:

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<mailto: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=>

_______________________________________________
bmwg mailing list
bmwg@ietf.org<mailto:bmwg@ietf.org>
https://www.ietf.org/mailman/listinfo/bmwg

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

Attachment: image001.png